IETF HOKEY adhoc Meeting January 23, 2007 at Cisco, San Jose Attendees: Charles Clancy (co-chair, DoD) Glen Zorn (co-chair, Cisco) Dan Harkins (Tropos) Vidya Narayanan (Qualcomm) Lakshminath Dondeti (Qualcomm) Yoshihiro Ohba (Toshiba) Subir Das (Telcordia) Madjid Nakhjiri (Huawei) Russ Housley (Sec Area Director) Kapil Sood (Intel) Meiyuan Zhao (Intel) Rajneesh Kumar (Cisco) Gabor Bajko (Nokia) Ran-Fun Chiu (HP) David Perkins Michaela Vanderveen (Qualcomm) Morning Session (9:00am – 12:30pm) a. Agenda bashing b. Draft-clancy-hokey-reauth-ps -> draft-ietf-hokey-reauth-ps i. It is a fusion of draft-vidya-eap-reauth-ps and draft-nikhjiri-aaa-req ii. Use no new terminology other than RFC 3748/EAP Keying draft terminology iii. Authenticator is a logical entity, but can be multiple physical devices. iv. Use of NAS has been removed from the problem statement. v. Lower layers have differentiated the different functions within the Authenticator. Multiple physical entities create a problem of channel binding, as the identity of the WTP and AC can be different. EAP Peer talks with WTP and EAP Server talks with AC. EAPOL terminates at the AC, so AC is the Authenticator. Dan: Won’t channel binding fail if not all entities are bound. Madjid: Channel bind to all intermediate entities. Vidya: Reauth server should bind the keys to the new local (EAP) server. Madjid: All entities need to be tied in and gets rid of lying NAS problem. vi. Vidya: Suggestion to keep authenticator as one entity. vii. Yoshi: OK with the single authenticator viii.Vidya: Reauth needs to run with the MSK which is at the first EAP Authenticator. With which entity does reauth happen? Will be discussed in PM session. ix. Roaming idea – a Client goes to the new authenticator. Not a new EAP Server. Will be discussed more in PM session. x. Vidya: Focus on key hierarchy, and not on different EAP servers. Baggage with the term “Roaming” within the same Administrative domain. EAP Peer can do reauth with a local (EAP) server. This is new entity which will be defined. xi. Latency: Defined as fewer roundtrips than original full EAP auth. No time or minimum roundtrip requirements. xii. EAP Method Independence: Kapil: There are some dependencies on the original method. Glen: So, it is not completely independent. xiii.Backward compatibility – must be maintained with existing EAP deployments. There are non-standard implementations, so how to deal with that. Mention that “implementations compliant with RFC 3748”. xiv. Compatibility: Vidya: What 11r did could have been done in IETF, if IETF had beat the market timing. For Access technologies which have not defined fast reauth, then no reason why these cannot use HOKEY. xv. What does term “interference” means in the compatibility statement. Subir: No need to mention 11r and CAPWAP. Charles: Bifurcate the HOKEY charter to be on outside of Authenticator, and CAPWAP/11r on inside. HOKEY should not interfere with 11r/CAPWAP. xvi. Difference between Key Scope and Key Context – Kapil: Key scope is tied to authorization; context defines the components that are input into the key derivation. xvii.Intermediate entities: Kapil: I do not see local (EAP) servers in the ps draft. Vidya’s model has those components. Dan: Diagram explain of the different entities. 11r is punting a problem that HOKEY is going to solve. Kapil: HOKEY will not replace 11r, but complement it. Add Dan’s diagram into the ps draft. Charles: Do not want to add a new diagram as that is problem statement. Dan: Where is the Authenticator in the diagram that EAP Peer does reauth to? Subir: Where is local server? Charles: It is not in diagram and should be between EAP Server and Passthrough Authenticator. xviii.Glen: EAP is 2-party, but Passthrough Auth is a 3rd entity, which is an essential entity that must exist. Vidya: We are not solving EAP multiplexing model. Glen: Yes, we are not. xix. Section 7.1 Discussion: Yoshi: Why are we criticizing 11r in the section 7.1. Madjit: Yeah! Especially, since Kapil is here! Charles: Change this section. Charles: Compromising R0KH can lead to entire key hierarchies to be compromised. Kapil: R0KH has security assumptions around the R0KH and if compromised, then compromise argument can apply to any other entity also. Rajneesh: HOKEY can support 11r making R0KH within the network. Madjid: R0KH can manage a larger domain. Charles: If people recommend different text, then feel free to post on the reflector. Rajneesh: Remove physical security statement. Dan/Russ: 11r does not believe that R0KH and R1KH distribution is within their scope. It is outside scope of HOKEY also. Subir: Not specified in 11r, but should be specified here. Dan/Vidya: R0KH and R1KH can be HOKEY entities for purpose of key distribution. c. EMSK Key Hierarchy i. Draft-saloway-eap-emsk-deriv -> draft-ietf-hokey-emsk-hierarchy ii. Glen: Simplify the key hierarchy. How do we simplify the key hierarchy? Laxminath: Make key hierarchy similar between home and visited networks. For each purpose, the key derivation must happen at the home EAP. Madjid: EMSK is not transported per EAP drafts, and we need USRK for specific applications, and USRK will be handled with different servers. Madjid draws diagram where EMSK is at EAP Server and EAP Peer, and how are specific parameters for each application is bound in? Laxminath: Draws an EMSK key hierarchy on board with each key for different usages, and further keys below for each servers; and, another key hierarchy for each domain/service. Based on Joe’s draft, different servers are application specific and can be handled specific application keys. Madjid: This proposal gives an asymmetric key hierarchy. Laxminath: Not asymmetric. Vidya: draft says we need IANA defined labels for each derivation key name. iii. There is a divergence between the current document draft and the proposal from Laxminath/Vidya. Goal is that the reauth root key comes from same source. Madjid: Setup different USRKs for different applications. Vidya: EAP Server does not know if the Local Servers may derive multiple sub-keys for different applications. Subir: Does home need to know the application? Vidya: Bind the usage into the key derivation. Madjid: Not every usecase that needs a key should be conveyed to the home Server. EAP is done for a purpose, and keys should be bound to that. It may be visited domain services. iv. Madjid: Discussion on what the ability of the Local server should be w.r.t to the key that it gets from the home Server. You get the key at bootup. Michaela: The key derivation should be bound. But, not clear if EAP server needs to know this. v. Proposal is to deliver a key to the Local Server and let the local server decide on deriving multiple keys, as it sees fit. Vidya: Operators need the flexibility to use the key for the services that they may provide. Kapil: This approach violates the HOKEY requirement for key context binding, as the delivered root key can be used for which-ever way the Local server likes. Russ: The key context is broad and can be “Local Services”. Vidya: Moves between multiple visited domains. Yoshi: Don’t need separation. Kapil: Isn’t the discussion/scope of HOKEY within the same administrative domain? Glen: Use HOKEY to solve the multi-domain problem, if we can. Russ: Wiling to change the charter of HOKEY if they solve the multi-domain problem. vi. The draft does not dramatically change. Additions can be made into same document. vii. Russ: What names the next level of key hierarchy? It is the Local Server (local scope EMSK) serving that portion of the network. viii.Madjid: One auth gets the EMSK and Peer goes to another Auth. Is there a problem with signaling? ix. Russ: MSK and EMSK differences of scope. Pick the one depending on whether the Authenticator needs to know that key. Peer needs to know both keys. Local Server must not know both keys. Madjid: AAA Server sends key to Auth and Auth does not send to any other entity. x. Vidya: Authenticator distributing keys is outside scope of HOKEY charter. Russ: Yes. xi. Russ and Charles re-affirmed that the key distribution problem from the “Local Server” to “Authenticators” is within scope of HOKEY. Change “Local Server” to “MDC” and we have the key distribution for 11r. xii. AAA Server is root of all roaming keys, and that should be EMSK. Charles asks for rough consensus on using EMSK as root of HOKEY. xiii.Michala: Today, does EAP server know how the MSK is being used? Usage of key is currently not sent to the EAP Server. xiv. Vidya: Do we need to have L2 signaling? Charles: Need a L2 signaling to indicate HOKEY. Madjid: Should not necessarily be L2 signaling. Michaela: Need 2 phases. xv. Board design: 4 parties are: EAP Peer, Authenticator, “HOKEY” Server, EAP Server. Discussion on how to do the capability exchange. Afternoon Session (1:00pm – 5:00pm) d. EAP-ER draft – presented by Vidya. i. Kapil: how does the Peer know how many hops away the AS/EAP Server is? ii. Vidya: Peer only knows the server name with whom it shares a key with. Potentially a choice can be made as to whether to go back to the EAP server or ask for a re-auth key. iii. For EAP-AKA, an EAP authenticator can construct an EAP Response/Identity message and send it to the EAP Server to trigger EAP-AKA, either based on EAP/Req/Rsp Identity with the Peer or based on other link layer signaling. iv. Clarification: for 1.5 roundtrips, the 0.5 comes from the EAP-Success. v. Server-initiated Re-auth with legacy authenticators sounds like a new EAP method. Server initiated must be kicked off from the Authenticator. The Server can know from the identity what kind of EAP method to start (re-auth or original). Server-initiated, we all seem to agree, is going to cost 1 (extra) roundtrip (one msg. is the EAP Response/Identity, the other is the EAP Success). vi. Peer-initiated re-auth with upgraded authenticators. Authenticators must understand new EAP codes. Key usage is the same. For legacy authenticators, we are introducing some empty messages – as discussed on the list; though the core re-auth protocol remains the same. vii. Key hierarchy: as depicted is within a single server. Root key is the local MSK or the EMSK. viii.Protocol transport: what changes to 3748 would a code-based re-auth introduce? V: none, as the new doc would not be a 3748bis but another doc that updates 3748 and has 3748 as a normative reference. State machine has to be updated as well. This re-auth proto is going to impact port control at the lower layer. The interactions between port control and protocol would be the same for EAP and another (non-EAP) re-auth proto. Lakshminath asserts that a non-EAP protocol doesn’t buy us anything. ix. Subir makes the case of UMTS-AKA: this protocol allows for both authentication and mobility. If a method like AKA does support the mobility too, then why would we need to add new messaging? – so why shoot for “better than AKA”, since it is fine as is and so would not be replaced even if there is a new protocol out there that has less latency. x. Vidya continues with EAP based transport benefits. xi. EAP-ER exchange message flow: Kapil asks about liveness and replay. xii. Liveness done by sequence numbers. These messages even if they get replayed, the Authenticator still gets the same rMSK, so it doesn’t impact it. No replay attacks – asserts Lakshminath. Kapil still states that liveness is missing and that there are potential replay attacks. xiii.Because of the fact that the AAA-H sends a key and all its corresponding state to a AAA-L, re-auth works with AAA-L in one roundtrip, even though the key that re-auth is based on was derived between the Peer and AAA-H, not between the Peer and the AAA-L – no disagreement, only clarification. xiv. Bootstrap exchange. Peer needs a full domain name before completion of EAP-reauth. If you do bootstrap with the home domain, you can get away with the next roundtrip only to the AAA-L. The bootstrap gives the Peer the local server address. e. EAP method extending: presented by Yoshi. i. How to deal with lack of EMSK implementation/derivation. A new EAP method can be used for extending EAP. This way we ensure backward compatibility with existing implementations via NAK. ii. Question on how to produce an EMSK for a method that doesn’t produce one by itself: from previous tunneled method’s MSK. Madjid points out that there is no provision for EAP failures. Charles suggests taking all previous MSKs and hashing them to achieve channel binding. There must be way to combine the keys produced by these methods, such that not much entropy is lost. Vidya concerned about the loss of entropy. iii. Russ: what happens when you want to re-auth? Yoshi: Re-auth should happen separately. So this draft helps get you an EMSK when you don’t have one (and don’t want to update your method), and does some nice channel binding stuff. f. Handover Key Mgmt Architecture: A High level view : presented by Yoshi. i. Re-key is not the same as re-auth: Re-auth follows re-key but re-key does not require re-auth. For 802.11r, re-key is enough as scope of authorization is R0KH, so no re-auth needed for transitions within the same R0KH. Not the same case in 802.11i, where the scope of authorization is one single AP. ii. A heated discussion about scope of authorization as raised by Glen: Peer authorized to use the entire network *through* the control port opened to that R1 KH. As you move around, you have to open a new port. 802.11r should authorized peers within the mobility domain (which can include more than one R0 KH). Charles: we accept that there is some ambiguity surrounding the issue of scope of authorization. iii. Yoshi concludes not all existing architecture clearly separate re-key from re-auth. We should examine proposed architectures in this light. iv. Vidya mentions that Steve Kent says that unless you are checking credentials (long term key or cert.), it is not authentication. Just showing proof of possession is not authentication. Vidya disagrees. g. Draft-nakhjiri-hokey-hierarchy-03 – Madjid Nakhjiri i. The backend messaging is not EAP – It can be carried over RADIUS attributes or in DIAMETER. ii. There would be new signaling between the EAP Peer and Authenticator. iii. Presented multiple Signaling alternatives – no change to EAP, using new EAP, using new EAP method, and EAP method encapsulation. iv. New lower layer messaging encapsulation (EAP Peer ? Authenticator) will have to be defined, as this proposal does not use EAP. v. Will need Authenticator and supplicant upgrades. h. Impact Analysis – Charles Clancy i. Transport | Peer | Auth | Server | L2 | Latency Non-EAP Major Major Major Major Low EAP-Code Minor+ Minor Minor+ Minor Low EAP-Type Minor- None Minor- None High ii. EAP-code (defining new EAP payload) and EAP-Type (new Types within existing payloads) are new EAP extensions. iii. Discussion on whether 802.11 community will live with the HOKEY solution, especially when they are biggest users of EAP. iv. Vidya mentioned that .16 and 3G has still not deployed EAP? So, such changes proposed by HOKEY are acceptable. v. Humming: Code Alone: Loud; Type alone: Not so loud; Code + Type: Not so loud. vi. Take the EAP Code proposal to the list. vii. MSK versus EMSK matrix, as root of the key hierarchy Key | Pros | Cons MSK - Existing [broken] EAP - Complexity to Methods don’t need to be decide which key to Fixed. Use. EMSK - Currently not used - May not work with - Never exported some deployments viii. Humming: MSK ( low ) ; EMSK ( loud ) ; Both (Silence)