> On 1 Nov 2019, at 13:05, Alan DeKok <al...@deployingradius.com> wrote:
> On Nov 1, 2019, at 7:53 AM, Eliot Lear <l...@cisco.com> 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 

I’ll be updating our draft accordingly.


Attachment: signature.asc
Description: Message signed with OpenPGP

Emu mailing list

Reply via email to