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

[Alan DeKok <[e-mail]>]

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.

  That's why my suggested text said "resumption uses same identity as the original authentication" .... whatever that is.  That initial identity doesn't need to be an NAI.

  However, the identities still need to be acceptable to EAP / AAA systems.  Which means that any binary identity should likely be converted to a "printable" form, via something like base64.

> My presumption is further that federation doesn’t really occur beyond the TLS endpoint, of it it does that is entirely an internal matter for the server.

  Yes.

  Federation works because nothing examines the contents of EAP.  Instead, the packets are routed solely based on the NAI.

>  We have a working example of callouts based on the identity of a client for purposes of authorization, but for authentication, I would think that would be largely a bad idea, due to secret sharing issues (when I say “federation” I mean that there should be no trust TLS secret sharing).
> 
> Is my understanding correct?

  Yes.

  There may be federations which share a common CA cert.  But each authentication system is unique, and does not share its secrets / identity with any other system.

  Aln DeKok.