********************** HOKEY WG Meeting Notes ********************** Materials on the IETF-67 meeting materials web site. Small agenda change: ordering Minute Takers: - Lakshminath, Dave Nelson "Opening Keynote" by Russ Housley - Long road to get the WG chartered, now on to the constructive work. - Lot of different drafts on the agenda, shows the level of interest. - Focus on requirements and problem statements. - Three milestones due before the next meeting, so there's a lot of work to do. ---------- Lakshminath Dondeti's presentation on EAP re-auth and key mgmt problem statement (see slides) Definitions of re-authentication. Want efficiency. Avoid full EAP method run. Method agonistic fashion. Motivations -- A full method run is expensive, introduces delay (latency) Some methods have a means to reduce complexity Focus on reducing round trips Interaction with the home network In 3GPP round trips to home AAA take too long Need a visited domain form of EAP Goals and constraints -- Low latency EAP lower layer independent Inter-technology handover Method independent AAA protocol compatibility Compliance to Housley criteria Q: What do you mean by latency? Q: Why do you need method independence? A: Could run an EAP method with the visited domain. Full method could take as few as two round trips. AKA can do one round trip. Method independent follows from the EAP framework. Two methods AKA TLS have pass through, can't use other methods. Method agnostic means you won't have to do it for each method. Q: Goals to get some EAP WG to standardize or do we change EAP here? A: We are chartered to do fast EAP re-auth here. Work here can be leveraged in other groups. EAP WG closed and left over work had to go somewhere. EAP keying not designed to provide for mobility. Work has to be done somewhere. Some of ht methods provide fast re-auth and some doesn't . We don't want to redesign old methods. Q: What does low latency operation mean? A: Put a number on it. Q: Round trips? A: No. Measurement start/stop, 802.11r kind of stuff. Q: How do we know when we achieve it? Russ: Significantly lower than doing an EAP round again. Q: How do we numerically verify that a protocol has met a time-based latency goal? A: Round trips is a better measurement. Q: Voice, data, what are we attempting to support? A: No specific application in mind. How fast can the handoff take place. Q: Are we allowed to change the EAP protocol? A: Yes. Lakshminath's presentation continues: - Keying considerations for re-authentication - re-issue of keying material - key from which you derive keys - keying separation - key hierarchy to support the domain - intra ESS 802.11r - what happens when you cross those boundaries. Cover that here - CAPWAP provides a solution for movement between WTPs of an AC - inter-technology roaming The current -00 draft contains a detailed of all aspects covered in the presentation Q: Why is the roaming case different? A: Mobility application, but not necessisarily roaming. Do we need different key hierarchy for different domains. LD: Has to do with what keys are handed out to whom. GZ: Roaming to a visited AAA server, knows what is in the message. Seems like it has the same threat model in home and visited networks. LD: Key hierarchy in home of visited domain could be the same -- in agreement. Root key may be different. Work on the principle of least privilege and avoid domino effects. Stay in the same domain. C: Agree with Glen's comments. C: Don't need to have a different root key depending on where you are visiting Q: Clarification of 3GPP use case -- take to the mailing list. C: IEEE 802.11r has solved all the problems? A: Differing opinions on that. Stop second guessing. C: Difference between domains is that the long term credentials exist in the home domain. Want the state machines to be the same. ---------- Presentation by Madjid Nakhjiri. (see slides) When you apply EAP to mobility you need to send one MSK to one authenticator and another MSK to another authenticator, which means another EAP round. Typical architectures have multiple physical components and thus transport of keys. Lump the access node and access gateway as the authenticator. Still doesn't solve the inter-authenticator problem. Security requirements, mobility requirements, design goals, tools and ideas. problem statements need consistent terminology specify security, mobility and management goals decide levels of key hierarchy how far down the hierarchy can IETF go? do the needed protocols exit? terminology concepts handover root key access domain controller Alper: Is ADC different from NAS Madjid: Has a hard time with the NAS. not comfortable with the term NAS A: NAS is where RADIUS client and authenticator lives M: Depending on the EAP signaling path, do you pass through the authenticator or not A: Wait until solution stage to name the entities M: ADC is a neutral term; it is a KH and KG for a domain TJ: Q for WG chairs. Will there need to be a terminology draft? Glen: We can worry about that later. M: ... G: Fine idea, thanks. VN: Is there a need to think about new terminology? G: Let's look at the full presentation. Madjid's presentation continues' ADC is a key holder and AAA client For IEEE 80211i , 802.16e and other lower layers the AN thing is the thing that decides where your EAP packets go. In a roaming scenario there may be trust relationships or there may be multiple sets of credentials. There is an issue of where you put the authenticator. Don't want to do EAP when handing over. Or maybe a specialized form of EAP. hard problems what key to use for the handover root key? architecture messaging channel binding Is keying at the access nodes outside the IETF scope? Positioning of EAP w.r.t . the ADC? Q: Solving only in EAP, or do we impact AAA? A: Can solve re-auth w/o AAA changes. Roaming may impact AAA. Don't want to change the initial EAP method. Not all today's methods support EMSK. Need some mechanism to negotiate the use of EMSK. Charles: Pictures like in Page 10 worry me. Authenticator at ADC seems to be outside of the scope. M: Let's wait until I get to that slide. Ch: Perhaps that belong to CAPWAP; we only handle keys that get to EAP LL. M: The charter talks about access technology independent keys. Clint chaplin: Comment: Let's not use MDC here; MDC and ADC are not the same. M: I don't want to reuse terminology. David J: 11i and 16e and other LL use EAP .... Does the AN in Page 10 get the key. In a roaming scenario, I might not trust the visited domain with my credentials. M: There is an issue of where you put the authenticator. When you run EAP in the beginning we need the authenticator role; afterward, you don't need to do "EAP." G: It may in fact be EAP, a specialized form of EAP. C: Where EAP terminates and AAA takes over? That the authenticator. M: ADC may not be in the path of EAP Hao Zhou: Are we trying to solve the problem within the EAP layer, without touching AAA. If we do, do we ask other WGs do this. Charles: Re-auth can be done without AAA changes. Visited domain stuff may need AAA changes. Glen: We can reserve the right to make mods to AAA as necessary. Hopefully small. Ha: no method changes? A lot of EAP servers now don't have EMSK and that could be a problem. Yoshi: Since EMSK is optional, we need to find a way to support those cases. ---------- Presentation by Yoshihiro Ohba on the pre-auth problem statement (see slides) We already have a pre-auth defined in EAP An example is IEEE 802.11i pre-auth The HOKEY WG aims to make EAP pre-auth to work across multiple ESSes Works across multiple technologies 2 scenarios direct pre-auth indirect pre-auth assumes signaling between access points pre-authentication forwarding layer pre-auth AAA requirements need to support various scenarios discussion of scope of pre-auth during charter discussions expected to use the same layer and protocol as the original auth List of out of scope pre-auth scenarios. Separation of EAP over L2 vs. L3 is more a mater of what you need to do to send the messages. The notion that the we can do intra-media pre-auth is moot, because you can always do it over L3 once you have a connection. Not sure this captures Sam Hartman's concerns. Not to introduce new requirements on the EAP lower layer. Take this discussion to the mailing list. Discovery of target NAS's IP address is always needed. In scope work is to define EAP pre-auth requirements applicable to any protocols. Slide 9, David J: What are EAPoL2 EAPoL3? Kapil: Why would you care how EAPoL is running? Yoshi: 802.21 will address this issue Kapil: Remove bullet 1 from Slide 9. Subir: Bullet 2, does this mean it won't work for different L2s? If both use EAP, my understanding is that it is different from Bullet 1. Yoshi: Same layer, different protocol. Alper: You cannot pre-authenticate from WiMAX to WiFi. Subir: that is a constraint to me. Lakshminath's presentation tries to address hetero technologies David: 16e and 11i allow carrying at L2. ... The separation of EAP over L2 and L3 is the case of what the network allows you to transmit. If you are in IP layer, then you can authenticate to whoever you like. The notion of cannot do inter-technology and ... V: I am not sure this point captures Sam's concerns. ... not introduce any new requirements due to EAP pre-authentication. As long as there is an out of scope method of discovering the authenticator, I shouldn't require pre-auth to run over different LL. If I am moving from 16e to 11i, if you can discover another network, I can run pre-auth. Subir: from an EAP perspective there is no difference. Alper: IP address discovery is necessary. The target authenticator's IP address need to be discovered. In the two cases, the target authenticator's IP address need to be discovered. Subir: Is it not an orthogonal issue? Alper: David: Is pre-authentication the method we are using for handover latency reduction. Charles: This is independent of re-auth. Subir: David: .... I am concerned pre-authentication as method type. Alper: one can use pre-authentication within the same technology. ---------- Presentation by Joe Salowey on Usage Specific Root Keys Problem is that USRK is to allow multiple keys for different uses with cryptographic separation. Coordinated derivation, tow usages will nto derive the same key Preserve the security of the EAP EMSK. USRK = KDF (EMSK, label, optional data len) KDF is flexible Default based on HMAC-SHA-256 Yoshi: I have concerns over USRKs. One thing is, if we derive multiple USRKs and only one of them needs to be updated, there may be issues to rekey. Joe: That depends on how the usage itself does the further hierarchy. That might be a good way of doing it. But might not be applicable to all cases. Hao: Is the KDF negotiable? In the draft we talked about a few mechanisms: use the method specific one, system-defined default KDF and then the KDF in the draft and so on. Hao: To be able to know which PRF to use, the client needs to indicate to the server about what it wants to use. Kapil: what's the motivation for having the KDF to negotiate. Joe: Algm agility. It is a good idea to update/change the KDF. Kapil: some additional complexity, a lot ?? What is the optional data? Joe: it probably won't be an authenticator id ----- Presentation by Vidya Narayanan on Extensions to EAP Key Hierarchy... (see slides) What exists today? Long term credentials use to derive MSK and EMSK. EMSK not exported from the EAP method today. low latency re-auth requirements constraints current key usages in mind disparate used of MSK today should visited domain entity be method independent support for legacy EAP peers root key selection MSK is delivered to the authenticator need to start with a different key Leads us to an EMSK based hierarchy Hao: Why do we have to use the EMSK? We can use the MSK. V: We could go back and redefine how to use the MSK, but if we go down that path ... Hao: this requires changes to client and servers and EMSK also requires changes to clients and servers V: need to support legacy clients. Hao: are you going to define a way to negotiate the KDF etc V: Joe was talking abt KDF negotiation as one possibility Hao: whether it is the MSK or EMSK, the changes are the same. Joe: you have to make a modification anyway Hao: There are methods that don't support EMSK Joe: you have to change client and server to derive keys Mad: the reasons given are not good No change to the authenticator, only changes on client and server side. Keep a consistent approach independent of authenticator. May also be security considerations if an authenticator gets a key that is the root of some other hierarchy. Server needs to undergo a change, some peers may need changes, some not, but we still need coexistence. Take the EMSK vs. MSK debate to the mailing list. Need a key for a proof of possession. Need an integrity key. One of the USRK is the root re-authentication key. Visited domain requirements on the EAP key hierarchy. Looks identical as the one coming from the EMSK, except called a VMSK. C: Lower layers have different key hierarchies. Charles: security issue: if you are delivering an MSK to an authenticator we might be giving away the root to a key hierarchy. Yoshi: if all we need to distinguish ?? ******MSK/EMSK Discussion to the list ... David: LLs have different Key hierarchies and there are issues with those. I suggest that we not be constrained by that. We can try and change those specs. I am thinking years ahead here. .. Charles: that discussion is out of scope here. --------- Madjid's presentation on key hierarchy (see slides) ADC MSK key holder AAA_REAUTH_KEY Glen: when do you send these keys. For the first one it is simple. For the second one, it is a matter of timing. Ma: If you go from one domain to another, you can ask Glen: This is on demand then Are you going to send it every ADC in the world? Ma: One option is per-domain Reactive or pro-active Glen: I am wondering, normally in EAP, the peer derives all these things on its own. How does the peer know when and how to derive? Ma: you have to get the identity broadcast Glen: Are we talking about IP broadcast? I am just wondering! Ma: Whether we do that kind of thing in the IETF May have to go back to the AAA, could be on-demand. Q: How does the EAP client know which keys to derive? A: Have to get the identity of the access omtaon communicated somehow. Need to know the identity. It could be broadcast Q: Does that STA authorize the distribution of ADMSK 1 and 2? A: When requesting to go to a different ADC, sign the request with the ?? key. Didn't think this all through. The current discussion is of key hierarchy, we will debate key distribution methods later. AN-to-AN handoff does not need to go to the AAA server. Q: Is each AN is included in only one ADC? A: In general, yes C: Issue with maintaining sequence numbers, or you need to need to change the keys. The session ran over time. Take remaining discussion to the mailing list