Document: draft-barany-eap-gee-04 Reviewer: Spencer Dawkins Review Date: 2007-01-17 IETF LC End Date: 2007-01-19 Summary: This draft is on the right track, but has open issues, identified in the review below. Comments: Please remember I'm not a security geek, or an EAP geek, so please push back on anything that seems bogus ("welcome to the IETF")... My biggest concerns are (1) the document is really inconsistent about how Type 1 and Type 2 work together (is Type 1 always access authentication?) and this seems to allow a level of flexibility that (I read in the security considerations section) increases vulnerabilities when you use that flexibility, (2) I don't get the N/As in the access control matrix at all, (3) I'm not sure how much 2119 language you need in this document, but it seems like you'd need more than you've got, at least in Section 5.3, (4) Section 7 has some speculation about future versions of GEE, but they aren't tagged quite clearly enough as "this COULD happen", (5) the security considerations section seems to make recommendations that I wasn't comfortable with. Further details follow. Please note that "Spencer: Nit:" isn't technically part of the Gen-ART review, these are just things I noticed while writing the review, for your convenience. Abstract The Extensible Authentication Protocol (EAP) is a general authentication protocol that supports multiple authentication methods and typically runs directly over data link layers without requiring IP. EAP can be used for different types of authentication, where Spencer: Nit: the abstract text here doesn't seem as clear as the Section 1.1 text. Perhaps "EAP could be used to authenticate with multiple Authentication Servers, when multiple providers provide access to different types of services, but EAP itself does not have the ability to differentiate between multiple EAP conversations between a peer and an authenticator"? And I'm not sure whether GEE is required for multiple EAP conversations, or if it's only required for multiple EAP conversations done in parallel. multiple providers provide access to different services. However, Spencer: the specification seems to oscillate between "access to multiple services" and "access and service", and I'm not sure why. Is access a service? Is access to a service a service? I am confused. Could you pick one? :-) EAP itself does not have the ability to differentiate between multiple EAP conversations between a peer and an authenticator. This document specifies the 3GPP2 Generic EAP Encapsulation (GEE) protocol for differentiating between multiple EAP conversations between a peer and an authenticator. 1.1. Motivation A good example of the case where access and service authentications Spencer: Nit: s/of the case// are performed separately is the case of Mobile Virtual Network Operators (MVNO). In this case, the network provider providing Layer1 and Layer2 access is typically different from that providing Layer 3 service (i.e., IP level service). Hence, separate access and service authentications are usually required to gain access to the respective networks and services. In cases where access and service authentications are performed separately, it may be desirable to do these in parallel, to avoid Spencer: re-reading... this seems to conflict with the "do Type 1 and use the result to secure Type 2" recommendation in the Security Considerations section 7.2.2, or at least there could be text explaining why the two recommendations really are consistent... added latency resulting from a sequential execution of the two authentications. When a peer is performing multiple EAP authentications, it is not possible to clearly differentiate between the two types of authentications using available means. Also, the authenticator will need to distinguish the multiple EAP exchanges in order to route the packets to the correct EAP server. Typically, the Identifier value in an EAP Response packet will be the same as that in the matching Request - however, the authenticator, while operating in pass-through mode, does not keep track of the value of the Identifier field. Even if the authenticator could match up the values of the Identifier field, the two EAP servers performing the access and service authentication may generate the same Identifier (since the Identifier is a randomly chosen 8-bit field in the EAP Request/Response packets). Hence, there is no available means to Spencer: Nit: s/packets)/packets), and a collision would prevent correct routing/? allow multiple EAP authentications for a given peer to occur in parallel. 2. Terminology Type 1 Authentication This refers to one authentications that is performed by the peer. For instance, it may be the Layer 1 and Layer 2 authentication that allows the peer to gain link layer access to the attached network. Type 2 Authentication This refers to a second authentication that is performed by the peer. For instance, it may be the Layer 3 authentication that allows the peer to gain access to Layer 3 services. Spencer: "Type 1" and "Type 2" sound like two different kinds of services, but if I am reading correctly, Type 1 is always for access, and Type 2 is always for a layer 3 service. So it's not "for instance", it's "in every case", or am I confused? 3. Architecture and Overview The proposed protocol operation remains mostly the same in the EAP multiplexing model as well as the EAP pass-through model. At a high level, this protocol allows the peer and authenticator to perform multiple EAP authentications independently and potentially with different authentication servers in different provider networks. The multiple EAP conversations may happen sequentially or in parallel. However, in accordance with RFC 3748, an EAP peer and authenticator Spencer: Nit: since RFC 3748 is about 68 pages long, a section number for this reference would be really nice! Section 5, perhaps? MUST utilize only one authentication method (Type 4 or greater) Spencer: Nit: I know the same terminology appears in 3748, but I'm not happy with "Type 4 or greater", especially since this document also has Type 1 and Type 2, which have nothing to do with the EAP request Type 1 and Type 2. Since 3748 says "1-3 aren't real", maybe you could drop the "Type 4 or greater" parenthetical remark? within an EAP conversation, unless the providers are the same and the peer is using the same credentials and EAP method for both types of authentication. Figure 2: GEE Protocol stack and Peer to Authenticator interaction in Spencer: Nit: is this a busted Figure label? It seems incomplete, and the next text doesn't quite seem to complete a thought. Figure 2 shows the protocol stack for GEE in the EAP multiplexing model. 3.1. Multiple Authenticator Model Depending on the architecture, the authenticator that is responsible for each authentication may be different. This could be true irrespective of whether the EAP server is the same or different for each authentication. However, in most practical cases, the need for multiple authentications arises only when the EAP servers performing the different types of authentications are different. Figure 4 shows the architecture with each provider having a different authenticator that is engaged in different EAP exchanges that the peer performs. In 3GPP2 networks, single authenticator and multiple authenticator architectures are both possible. Spencer: it's not quite clear to me from the document whether GEEv0 also supports multiple SNPs AND an ANP - I was thinking the answer is "yes", but I'm guessing, and the discussion of TIDs below made me wonder if I'm guessing correctly for GEEv0. If multiple SNPs are supported, a strategically placed "two or more" would be helpful. If multiple SNPs are not supported in GEEv0, this document advertises more flexibility than it delivers... Since GEE runs between the peer and the authenticator, it brings a slight variance when the authenticator for each EAP exchange is Spencer: Nit: not quite sure what "variance" means here - "requirement for different handling"? I'm guessing. Mumble. different. Since the multiple EAP authentications are over the same link, the EAP exchange between the peer and one of the authenticators may have to pass through another authenticator or enforcement point. Hence, the lower layers at each hop in this case must be able to indicate the presence of the GEE header. 4.1. GEE Header Format Result flags/code (RFL) The last 2 bits in the GEE header are used to indicate the result of the EAP authentication in progress. The leftmost bit in this field is the 'K' bit and indicates whether the MSK resulting from Spencer: Nit: MSK is not expanded on first use. the EAP conversation being encapsulated by the particular GEE session must be bound with an MSK resulting from the second EAP conversation carried in a second GEE session. If set, this implies that the peer MUST bind the MSKs to derive TSKs. The process of MSK binding is described in Section 5.3. In GEEv0, the last bit is the R bit and is reserved and MUST be set to zero at the sender and MUST be ignored by the receiver. 5. Packet Processing Details 5.1. Packet Handling at the Peer While Type 1 and Type 2 authentications are not explicitly defined in this document, these must be defined at the peer and authenticator for a given usage of this protocol. Spencer: Good. I'm supposed to be confused here... :-) When the peer sends a GEEv0 packet in response to a GEEv0 packet received from the authenticator, the TID value MUST be copied from the corresponding packet received from the authenticator. As in the Spencer: Nit: s/As in the/As with the/ packet from the authenticator, a value of 01 indicates that the EAP packet is for Type 1 authentication and a value of 00 indicates that the encapsulated EAP packet is for Type 2 authentication. The RFL value MUST be set to 00. 5.3. Multiple authentications and access control enforcement When both Type 1 and Type 2 authentications are carried out, access control MUST conform to the following cases. Type1 Type2 Combined result Case 1 Success Success Success Case 2 Success Failure Type1 related access only Cases 3&4 Failure S/F Failure Cases 5&6 N/A S/F S/F Access Control Matrix Spencer: deeply confused here. There is no explanation of what "N/A" means in this table, and in the absence of that explanation it feels like you're talking about six cases when you should either be talking about four cases or eight. I didn't see draft-terrell-math-quant-ternary-logic-of-binary-sys listed as a reference, so I'm assuming that the explanation would help a lot :-) GEE requires that at least one of the authentications to be key generating and both authentications to be mutually authenticating. Spencer: I am confused by the lack of 2119 language in this sentence. MUST? SHOULD? WOULD-BE-NICE? If one of the authentications is not key generating, then there MUST be a way for the authenticator to identify the two authentication conversations (Type 1 and Type 2) corresponding to a peer. Specifically, there MUST be a mechanism for the authenticator to correlate the Type 1 and Type 2 credentials; typically this is facilitated by backend network protocol support. An example of such backend support is to be able to send an identifier that is unique to the peer across the authentications in an authenticated manner. For instance, when both authenticators reside in the same node, the AAA transactions may return Chargeable-User-Identity (CUI) attributes [12] and the node can compare them for equality. If there is a mismatch, or the node has not received such an identity from both transactions, the peer MUST be disconnected. If both Type 1 and Type 2 authentications are key generating and occur in parallel, one of the following techniques are used: MSK Binding In this case,even when there are multiple authenticators, we assume that there is only one access control enforcement point. Here, the combined MSK MUST be used to derive session keys (Transient session keys, TSKs). Both authenticators deliver the MSK to the enforcement point and it computes the combined MSK as follows: Combined-MSK = f(MSK-Type 1, "GEE Combined Key" || MSK- Type 2), where f represents prf+ as defined in [3]. The length of the Combined-MSK MUST be 512 bits. With GEEv0, the PRF is HMAC- SHA-256. Single Access Control Enforcement with Protected Result Indication In the event that there can be a protected result indication between authenticators and/or enforcement points with a way to correlate the peer IDs used in the EAP conversations, it is feasible to have the TSK generated from only one MSK. A MiTM Spencer: s/feasible/possible/ attack may be plausible in this case, and hence it is NOT RECOMMENDED. 6. GEE Extensibility GEE could be extended to support dynamic TID assignment, where an authenticator may pick an unused TID value. The peer could participate in as many as 4 EAP conversations in parallel. In order for the peer to be able to understand the meaning of each TID, a new mechanism would be needed to send information about authentication type and other policy hints. Such a mechanism could either operate on the layer that carries GEE, or in an extended version of GEE itself. Note that RFC 4284 defines a mechanism for the authenticator to advertise a set of roaming realms. With this information alone, the peer needs to readily understand the nature of authentication based on the realm information. However, in some cases, a peer may have multiple credentials (e.g., for device and user authentication) for a give realm and for that or other reasons, providing a list of realms alone may not be sufficient. In those cases, the realm information itself is insufficient. Similarly, due to EAP MTU and other considerations, RFC 4284 can carry only a very limited amount of information, and it is not intended for carrying other policy information. As a result, its applicability for this purpose is limited, and other mechanisms are likely to be needed. This document does not propose any such mechanisms at this time. Spencer: wasn't entirely clear on what this is saying - something like "EAP with GEE is more likely to trip over limited EAP MTU than EAP without GEE, so don't plan on using EAP to carry large amounts of data"? The current text seems to be more about EAP limitations than about GEE limitations. Specifically due to the introduction of additional capability to use the identity hints and indicating the type of authentication via extensible options (TLVs), the restriction imposed in GEEv0 for the semantics of the TID field can be removed for future versions. Spencer: can you provide a pointer to where this introduction will happen? Furthermore, in the result code and flags field the last bit may be set to indicate the presence of TLVs in the GEE header. Spencer: not sure how to reconcile this with "In GEEv0, the last bit is the R bit and is reserved and MUST be set to zero at the sender and MUST be ignored by the receiver." This is speculating about how a later version of GEE might work, perhaps? Something like "Furthermore, future versions of GEE may use the last bit of the result code and flags field to indicate the presence of TLVs in the GEE header"? 7.1. Recap of use cases and interactions between network entities GEE encapsulates EAP so an authenticator can signal to the peer about the type of authentication the EAP request is meant for. GEE also facilitates parallel execution of such authentications. For instance, Type 1 and Type 2 authentication may take place in tandem Spencer: Nit: s/in tandem/sequentially/ (in any order) or in parallel. 7.2. Threats and mitigation strategies The GEE header is not cryptographically protected. Thus it is plausible for an eavesdropper to use Layer 2, GEE and EAP headers and collate information on how certain devices are authenticating themselves to their network providers: the order and combination of the different types of authentication are easily available in those headers. Note that if Type 1 (say, access) authentication occurs first and Spencer: again, some of the text seems to assume that Type 1 IS access authentication, while other text does not seem to require this. subsequent authentication processes take place via a Layer 2 encrypted channel, information about the rest of the authentications will not be available to passive observers on the path from the peer to the authenticator. Spencer: this text could be recommending that Type 1 authentication happens before Type 2 authentication, but it's not recommending this, and the specification seems to go out of its way to NOT require this. I'm not sure why this text isn't SHOULD ("except in tightly-controlled environments"), if the alternative opens you to eavesdropping attacks. 7.2.2 seems to be a stronger statement than this one. 7.2.1. Threats that might cause denial of service An adversary may change any of the contents of the GEE payload, the version field and/or the TID field, to cause either the peer or the authenticator to drop GEE encapsulated EAP packets. Suppose an attacker consistently changes the value of the TID field, the AAA server may conclude that the peer's credentials may have been compromised and may revoke access so as to trigger an offline process for updating that peer's credentials. As a result the peer may lose connectivity temporarily. Note however that DoS attacks identical or similar to this are also possible on EAP conversations without GEE encapsulation. Spencer: This might be clearer if you said "EAP conversations without GEE encapsulation are vulnerable to denial-of-service attacks, and GEEv0 does not change this vulnerability" someplace. 7.2.2. Threats that might cause theft of service To mitigate this threat, i.e., when the EAP method used for one authentication (e.g., Type 2) is more vulnerable to attacks than the EAP method used for another authentication (e.g., Type 1), the authenticator needs to strictly enforce a policy of Type 1 authentication first, and require that the Type 2 authentication occur within the secure channel established as a result of Type 1 authentication. Another possible solution is for the authenticator to maintain an association between the Layer 2 security association and Layer 3 address(es), to prevent rogue peers from stealing other peers' IP services. Spencer: I'm not a security geek, but if the rogue peer goes first, wouldn't this proposed band-aid prevent the legitimate peer from "stealing BACK" its own IP services? 7.3. Implications of multiple EAP authentications There are several possible mitigation strategies including the use of identifier binding between authentications (e.g., Layer 2 and Layer 3 identifier correlation), or in case of sequential authentications, the use of key material from the first authentication to encrypt future authentications. Other solutions require all authentications to be key generating and binding all the keys to generate the master key used to bootstrap the traffic key generation process or using multiple encapsulations using the generated keys. Spencer: Nit: s/using/with/ When the multiple authentications are key generating and occur in parallel, GEEv0 requires that the MSKs resulting from each authentication be all used for access control in order to Spencer: Nit: s/the MSKs resulting from each authentication be all used/all of the MSKs resulting from each authentication be used/ successfully prevent any MiTM attacks. When only one of the authentications is key generating or when the authentications occur sequentially, other administrative policies must be used to ensure that the threat is mitigated.