Thanks, Alan. Please see below. > On 1 Nov 2019, at 12:08, Alan DeKok <al...@deployingradius.com> wrote: > > On Nov 1, 2019, at 6:15 AM, John Mattsson <john.matts...@ericsson.com> wrote: >> I strongly support working group adoption of draft-dekok-emu-tls-eap-types. >> Can we make sure to get this document going, I agree that this is a very >> needed draft. I think it should include updates for everything people wants >> to use. I do not think draft-ietf-emu-eap-tls13 strictly have to wait for >> draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should be >> published shortly after. > > I will do an update to my document shortly. > > I also added an issue with the EAP-TLS document on GitHub. The suggestion > is to add text which explains how (and why) the EAP Identity is chosen during > resumption: > > --- > 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? > > 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. 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. 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. 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? Eliot > --- > > Alan DeKok. >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
