[Emu] WG Review: EAP Method Update (emu)
The EAP Method Update (emu) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2019-11-11. EAP Method Update (emu) --- Current status: Active WG Chairs: Joseph Salowey Mohit Sethi Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: emu@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/emu Archive: https://mailarchive.ietf.org/arch/search/?email_list=emu Group page: https://datatracker.ietf.org/group/emu/ Charter: https://datatracker.ietf.org/doc/charter-ietf-emu/ The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access authentication framework used, for instance, in VPN and mobile networks. EAP itself is a simple protocol and actual authentication happens in EAP methods. Several EAP methods have been developed at the IETF and support for EAP exists in a broad set of devices. Previous larger EAP-related efforts at the IETF included rewriting the base EAP protocol specification and the development of several standards track EAP methods. EAP methods are generally based on existing security technologies such as Transport Layer Security (TLS) and mobile network Authentication and Key Agreement (AKA). Our understanding of security threats is continuously evolving. This has driven the evolution of several of these underlying technologies. As an example, IETF has standardized a new and improved version of TLS (v1.3) in RFC 8446. The group will therefore provide guidance and update EAP method specifications where necessary to enable the use of new versions of these underlying technologies. At the same time, some new use cases for EAP have been identified. EAP is now more broadly used in mobile network authentication. The group will update existing EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. Perfect Forward Secrecy (PFS) is an important security property for modern protocols to thwart pervasive monitoring. The group will work on an extension to EAP-AKA' for providing PFS. Out-of-band (OOB) refers to a separate communication channel independent of the primary in-band channel over which the actual network communication takes place. OOB channels are now used for authentication in a variety of protocols and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users are accustomed to tapping NFC or scanning QR codes. However, EAP currently does not have any standard methods that support authentication based on OOB channels. The group will therefore work on an EAP method where authentication is based on an out-of-band channel between the peer and the server. EAP authentication is based on credentials available on the peer and the server. However, some EAP methods use credentials that are time or domain limited (such as EAP-POTP), and there may be a need for creating long term credentials for re-authenticating the peer in a more general context. The group will investigate minimal mechanisms with which limited-use EAP authentication credentials can be used for creating general-use long-term credentials. In summary, the working group shall produce the following documents: * An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). This document will update the security considerations relating to EAP-TLS, document the implications of using new vs. old TLS versions. It will add any recently gained new knowledge on vulnerabilities and discuss the possible implications of pervasive surveillance. * Several EAP methods such EAP-TTLS and EAP-FAST use an outer TLS tunnel. Provide guidance or update the relevant specifications explaining how those EAP methods (PEAP/TTLS/TEAP) will work with TLS 1.3. This will also involve maintenance work based on errata found in published specifications (such as EAP-TEAP). * Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, EAP-PEAP and EAP-AKA’. The lack of this definition is a recently discovered bug in the original RFCs. * Update the EAP-AKA' specification (RFC 5448) to ensure that its capability to provide a cryptographic binding to network context stays in sync with updates to the referenced 3GPP specifications. The document will also contain any recently gained new knowledge on vulnerabilities or the possible implications of pervasive surveillance. * Develop an extension to EAP-AKA' such that Perfect Forward Secrecy can be provided. There may also be privacy improvements that have become feasible with the introduction of recent identity privacy improvements in 3GPP networks.
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Hi! > On 1 Nov 2019, at 13:05, Alan DeKok wrote: > > On Nov 1, 2019, at 7:53 AM, Eliot Lear 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
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
On Nov 1, 2019, at 7:53 AM, Eliot Lear 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
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Thanks, Alan. Please see below. > On 1 Nov 2019, at 12:08, Alan DeKok wrote: > > On Nov 1, 2019, at 6:15 AM, John Mattsson 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
Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
On Nov 1, 2019, at 6:15 AM, John Mattsson 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. 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. --- Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
