On Sat, 2 Mar 2024, at 18:20, David Mandelberg wrote:
>> Maybe a TEAPv2 could use ALPN for the TLS jacket to avoid this..erk, I think I may have suggested something that could be retro fitted here without impacting existing implementations; assuming they would just ignore the ALPN.
>
> ALPN would solve the problem of speaking different versions, but the
> version downgrade problem would still stick around until the first
> Crypto-Binding, right? (Not saying that's a problem, just want to make
> sure we all understand what it would and wouldn't provide.)
I do not think so as the ALPN, which is a {Client,Server}Hello extension, is protected and checked during TLS Finished.
Should mean that if someone is tampering with the handshake, it should fail at that point, more importantly before we get to any inner methods.
I have added a 'version downgrade' note to the security considerations.
https://github.com/emu-wg/rfc7170bis/pull/32
> If it's not feasible to require server authentication before sending
> Identity-Hint, then maybe at least document what information can be
> leaked by it and in what circumstances? Or maybe recommend that
> implementations don't send it by default to unauthenticated servers, but
> offer a way for the user to override that default?
My PR also includes a 'SHOULD NOT' for unauthenticated provisioning. I added to the TLV section the recommendation to anonymise any identities sent during unauthenticated provisioning. Also slipped in a snippet or two in the security considerations section too.
Maybe here instead we could just remove the first "shall not send" and instead just keep the second "recommended send as anon" part?
We still have an opportunity to change this as no one has implemented or deployed this TLV in the wild yet.
Back to thinking of the consequence of messing with the opportunistic Identity-Hint TLVs being sent, I do not know if this is actually a problem.
The authentication flows here are:
1. unauthenticated provisioning Phase 1 completes
2. [optionally] peer includes one or more Identity-Hint TLVs
3. server sends EAP-Payload[EAP-Identity]
4. peer *always* responds with the full identity via EAP-Payload[EAP-Identity(bob@xxxxxxxxxxx)]
An attacker could just run this N times to jiggle out the information that would have been leaked opportunistically by the client...or just wait for the EAP-Identity in the next frame.
Back to thinking of the consequence of messing with the outer-TLVs, I have added a suggestion that implementations may wish to add a Vendor-Specific TLV as dummy to neuter this. Not sure if we want to actually firm this up to "do this and use *this* particular Vendor-Specific TLV"?
Thanks
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
