Hi! > 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 here. I’ll be updating our draft accordingly. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
