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(b...@example.com)]
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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
