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. 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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
