Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Eliot Lear <[e-mail]>]

Hi!

> On 1 Nov 2019, at 13:05, Alan DeKok <[e-mail]> wrote:
> 
> On Nov 1, 2019, at 7:53 AM, Eliot Lear <[e-mail]> wrote:
>> 
>>> The EAP Identity used in resumption SHOULD be the same EAP Identity as was used during the original authentication. This requirement allows EAP packets to be routable through an AAA infrastructure to the same destination as the original authentication.
>> 
>> Just a question: why SHOULD and not MUST?
> 
>  I'm happy to have it a MUST.
> 
>  I'm prepared for some people to say it can be different, i.e a different AAA server can be used for resumed sessions.  But I don't see that as important.
> 
>>> The alternative is to derive the EAP Identity from the identity used inside of TLS. This derivation is common practice when using certificates, and works because the "common name" field in the certificate is typically compatible with EAP, and it contains a routable identifier such as an email address. This practice cannot be used for resumption, as the PSK identity may be a binary blob, and it might not contain a routable realm as suggested by RFC 7542.
>>> 
>>> In some cases, the PSK identity is derived by the underlying TLS implementation, and cannot be controlled by the EAP authenticator. These limitations make the PSK identity unsuitable for use as the EAP Identity.
>> 
>> Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for federated realms (we may both have this wrong).  My presumption here is that an anonymous NAI is always used, but that the realm is what people would key off of, and this would always be present.
> 
>  As the EAP Identity, yes.
> 
>> But that presumption doesn’t hold true with the current TEAP update that we’re working on and that may be problematic.  In any case, this means that that at least the externalized identity can be used to route, and that normal TLS semantics can be used for authenticating.  It does require that tickets be managed on both ends.
> 
>  If the authentications are performed within a constrained system, it's fine to skip using NAIs.  I would suggest that for device bootstrapping you want to ensure that the authentications *aren't* routed outside of the current network.  So they *shouldn't* use a realm.


Ok.  Got it.  I think we have to be quite careful about use of the realm, then, and mechanism selection must be done exclusively with EAP-Request/Type.  I think it’s okay for federations to bootstrap; although we needn’t define that here.

I’ll be updating our draft accordingly.

Eliot