IETF 66 Hoakey BOF Meeting Notes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Summary ~~~~~~~ The meeting came to a consensus that a WG group should be formed to work on inter-domain and intra-domain rekeying of wireless mobile hosts. There were four presentations followed by an extensive discussion during which the chair queuried meeting participants on several topics. The presentation slides are at http://www.cs.columbia.edu/~smb/hoakey/ and a rough transcript of the discussion appears in the minutes below. Introductions and agenda bashing ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ S.Bellovin proposed an agenda, which was accepted. M.Richardson agreed to serve as scribe during the brainstorming session. M.Baugher volunteered to take minutes but was having jabber problems so there is no jabber log of this session. 1. Extensions to EAP Keying (EAP-Ext) L. Dondeti, V. Narayanan ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Presentation can be found at http://www.cs.columbia.edu/~smb/hoakey/IETF66_EAPExt.ppt L. Dondeti described requirements and motivation for EAP extensions to support inter-domain roaming in 802.11i, 802.11r and 802.16e environments. Master Session Key usage is inconsistent across these systems and unsuitable for extension. Extensions based on EAP-EMSK usage is proposed along with a new key hierarchy. A method of efficient reauthentication for inter-domain roaming is also proposed that uses a peer-initiated on-demand pull model and supports PSK bootstrapping through EAP keying. New protocols and hierarchies must co-exist with existing schemes such as CAPWAP, 802.11r and 802.16e. Work items for EAP-Ext include EMSK usage and hierarchy, method-independent EAP reauthentication, and PSK bootstrapping. 2. Pre-authentication Problem Statement - Ohba, et. al. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Presentation at http://www.cs.columbia.edu/~smb/hoakey/ietf66-hoakey-preauth-ps.ppt Y. Ohba described a preauthentication optimization that extends the 802.11i notion of pre-authentication across intra-ESS transitions to apply to inter-domain ESS transitions. An large reduction in delay is expected to be gained using this method by having less exposure to packet loss and interface activatino delay. There are two scenarios, direct and indirect pre-authentication. In direct pre-auth, the mobile host traverses a Target Authenticator to a AAA server; indirect pre-auth inserts a Serving Authenticator between the mobile host and the Target Authenticator. Requirements for pre-auth described in IETF 64 presentation and briefly reviewed. The scope of the work included Mobile Host - TA signaling, MH - Sa signaling and TA - SA signaling. Mr. Ohba began to describe deliverables but SMB asked that this discussion be postponed until the charter discussion. - Discussion - Pasi: This is an optimization ... is the cost worth the benefit? He doesn't think so. Glen Zorn: This is more than an optimization, but there's no single one way to do this. Russ H: The problem he wants to solve. If we're ever going to achieve roaming across L2 media, we're going to have to provide the framework at IETF. The various stds orgs can each work within teir domian, but not the framework for romaning between domains. EAP is what is common to all of them. Sam: Are we trying to create an EAP based framework for inter-media roaming. Russ: that's one of the things driving the energy. Pasi: If you read the 1st paragraphs of various drafts proposed in the BOF, then an inter-media romaing is importent. But then they propose solutions that such solutions already exist but they are trying to get rid of the 1 sec. delay currently in place. Sam: Pasi, what doesn't work? Pasi: If it works , then it works and the drafts don't motivate .... Bernard: There is a security req't in there somewhere ... its not just that current systems works, but some work faster than thsi (11r). But some of them are not secure enough (for inter-media case). Lak: 2 cases there ... the domino effect problem, over-exposing keys. The other one is 802.11 it works in ESS but not across an ESS. Some args say a user i most likly inside an ESS and if you roam across touch luck do re-auth. John Volbrook: How do yhou find re-auth servers (addresing question), and how does that server know who to tell? Also EAP methods are outside the keying hierarchy. 3. Problem of Handover Keying - Madjid Nakhjiri et. al. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Presentation at http://www.cs.columbia.edu/~smb/hoakey/Handover_keying_montreal.ppt M. Nakhjiri noted that these are the same slides as the last Hoakey meeting that considered requirements and technology for handover keying for mobile nodes on wireless networks. The issue is avoiding new EAP authentication during handover in the intra-domain case, and it is even more difficult in the inter-domain case. Different SDOs have different solutions. The IETF is needed to address the inter-domain authentication case and HOAKEY needs to create a key hierarchy that uses the EAP method. Some of these key derivations can be defined in the IETF whereas others are link-specific. Of particular importance is getting the terminology correct when communicating among SDOs on this problem. A list of terms was presented. It was noted that "ADC" is preferred over "authenticator" to cover both authentication and key management in one place. This allows better heterogeneous roaming/handovers per domain technology. It should be to the IETF to specify the handover root key (HRK), ADMSK. LSAP and LSK (link session keys and authentication protocol) derivation is outside IETF but guidelines should be provided by IETF. Progress since IETF 65 was discussed and charter revisions mentioned, but SMB asked the presenter to identify the contentious topics. Choice of HRK is one, but he had no strong opinion as of yet. 4. Discussion led by S.Bellovin (SMB) SMB noted that the slides are on his web page: www.cs.columbia.edu/~smb/hoakey and Two questions were posed for discussion and participants were polled during the discussion to understand where there was consensus. Much of the discussion was recorded by M.Richardson, who created an outline of the progress of the discussion. SMB: We'd like to hear the requirements and suggestions for each speaker on two issues, 1. must support multiple eap methods? and 2 must this work with multple subnets and not just 802.11, i.e. multiple layer 2 media. Madjid: we must be EAP diagnostic J. V: Most of this problem is outside of EAP and is a matter of being able to use multiple EAP methods Hasnaa: Should be general to EAP methods All of this has to work with multiple different subnets and kinds of subnets. Hetergeneous layer-2 media must be supported. (not just 802.11). Does it need to support handoff between dissimilar media? (Intra-media handoff) In what environments are we trying to handover? We should be supporting inter-media handover. SHOULD be lower-layer agnostic? Good support. (Not MUST) Inter-media --- it comes down to who operates each media? SMB: different administrative domains is a different question. There are parts of the spec which has to be media specific. Pasi: most of this work is an optimization. Are the benefits worth the cost? Does not agree that the EAP method is very expensive. Can be done once an hour without an issue. Bernard: is the goal to optimize handover, or something else? Is there some service that tells you where you are moving to? is that in scope? A: there are more goals other SDOs have not completed their key hierarchy. Glen: disagrees that this is just about optimization. there is no single thing that works well. This is yet another attempt by other SDOs to use the IETF as a communication channel to talk to each other. Problem we are trying to solve: Russ: If we are going to achieve roaming across L2 networks, the work will have to happen at the IETF. SAM: Are we trying to create an EAP based framework for inter-media roaming? VERY ROUGH CONSENSUS. Pasi: first paragraph of various drafts, it fits Sam's question. If you read the rest, you learn that the solution attempts to optimize the 1 second delay for the re-auth, assuming the roaming worked, period. SAM: If I roam, does EAP already work? Pasi: why is it important to reduce the 1s, if the roaming already works? Bernard: not only do existing systems work, they work faster. Maybe the problem is that the existing intra-media case is not secure enough. A: The domino affect problem in key compromise. John: I like Russell's formulation. How do I get layer-2 roaming. "There is an addressing question." "How does that server tell that access point what to do?" EAP/EAP-methods are outside the keying hierarchy. Managing the keying hierarchy is the most important thing. Russ: EAP is used to establish the root of the keying hierarchy. The breadth/depth is completely dependant upon the L2-media, and those pieces should not be addressed by the IETF. If we are going to use the roaming thing, we need more than one root, and we'd like to do this without going back to the AAA server, then we can get a time benefit. A: some parts of the network, you wind up passing keys from one system to another. You have traded off security for performance. Q: EAP works, even if you have to run it each time on each media. What does not work is the rest of the system trying to deal with handover. It is an essential optimization. Pasi: most wireless systems have already solved this problem. What problem do we need to solve here? Maybe there are security problems, maybe 11r has done something wrong, but should we fix it here? Q: SDOs are doing it now, but the IETF can build a framework. SMB: LATENCY OPTIMIZATION is a major REQUIREMENT. rough consensus. Q: disagrees with what Pasi said. Other SDOs have assumed a certain roaming architecture, and have tried to solve the problem for that. e.g: 11r does not work if you change the ESS. Q: other than 802.11r who else has solved the problem? Pasi: wi-max has solved it too. Pasi: pretty much what .11r does, but different protocols and different terminology. A: you are relaying on some kind of context transfer? Q: 11r has not solved all of the problems. We don't know what the secure channel between the access points are yet. This is a practical problem. Some SDOs have taken the approach that the network is secure. This does not solve inter-media roaming. The entire MSK is delivered to the authenticator, and lower layers use different number of bits. Pasi: 11r -> 16 would only work if you make before break. Clint: 11r charter part says within one ESS. Another group is looking at heterogeneous roaming, and between ESS. And maybe not even looking at security. A: 802.21 wants to do media-independant handover, including security. Clint: there are make-before-break options, but they require a new EAP. Bernard: there are many different ways, some involve EAP and some do not. Q: why do we need different root keys? Russ: I meant to say that the key that is delivered to form the key hierarchy, needs to be different for each media. A: re: Clint's statement, There might be a 16r trying to solve the problem. Q: Split up the key management from EAP, so that it can be used by EAP, or by other systems. TsingHa: the distinction between push and pull should not be made too strict. A: maybe too SMB: is this a requirement, or a tradeoff? TsingHa: both pull and push should be permitted. Clint: it depends upon if you want to proactive or reactive. In many cases, you can not plan ahead, so you have to use the pull model. It is unclear if this is a requirement. A: first time we called it AAA-based keying. EAP is now most fashionable. Always thought that the key came from the AAA, but based upon discussion thinks that it should be from EAP. It is about showing key derivation at all levels of the network. Deciding when to move the keys is another question. Clint: the problem is to roam and minimize loss of data. If we focus too much on keys, we loose focus on the goals. SAM: Did we get consensus that this was the problem we were solving? SMB: No, we didn't get that yet. Nancy: now we are not just talking about keys, we are talking about all sorts of other things too? SMB: happy to push that aside. SMB: Are we interested in inter-administrative domain handoff or not? Russ: if there are more than one AAA server? A: if we assume that we are using handover keying, then inter-administrative domain can not be done. Q: this can not be done. Clint: make before break! Q: yes, make before break solves a lot of things. SAM: If it is the same AAA server, then sure. Q: I thought the question was for more than AAA servers. SAM: metropolitan wireless networks are administrative domain, and starbucks is another. Can I roam between these two domains without a full EAP effort. Q: then yes, it's still the same home-domain AAA server. If the original interaction occured with the home-domain AAA server. Hoatow: three problems were raised. 1) latency optimization during handoff. (Might not be in IETF scope) 2) intra-media issue, some solutions in some media, but might be insecure. 3) when we have an existing solution to do a pre-auth, we do not know that it is in fact a pre-auth. Dave Nelson: use case needs low latency. Assuming intra-domain does not preserve contiguous service. SMB: IETF attendees get access to hotel's networks, and that works by having them talk to the IETF AAA server. Bernard: there is an issue of if you can talk to two networks (i.e. do you have enough radios, etc.) Glen: re: Steve's example. It's not the same as Sam's example. Does not believe that Sam's example is possible. The EAP goes back to the home-server. Clint: This is a political question, not a technical question. The owner of the domain does not want let the customer roam elsewhere, although the customer wants to do that. Moving from GPRS to 802.11, for instance. Jari: If you have two radios you can do make-before-break. Q: There is no peer to peer roaming agreements, so the 11r model does not quite work. But, obviously you have a roaming agreement with the home AAA server, so there must be some kind of way of making this work. We want to avoid creating state in the intermediate AAA servers. Q2: A station can see multiple providers at the same time, which one do you want to use? Clint said that there is a monetary issue, but there are other reasons other than signal strengh. SMB: Seems like out of scope. Q2: issue of multiple providers, there are multiple criteria, and some are on the user's side, but there are also some issues on the providers' side. A: SEAMOBY has worked on this question. Once we decide to move, do we have enough security issues. SMB: Is Inter-domain roaming important? ROUGH CONSENSUS. SMB: Is target selection important? How do you know to whom to talk? Q: Are we asking about mobile nodes knowing the target, or access networks knowing the target? Bernard: someone has to know the target. Q: What is client sending? And to whom? many: pre-auth requires some communication. A: the network and mobile need to derive the keys together. The triggers may be media specific. Q: what are the parameters that go into key derivation. We might not need to do any signaling, or we may need more freshness in the key derivation. Q: Had assumption that we would only work on a key derivation hierarchy, not the actual signaling. Maybe that's wrong, and it is a question. Q: target selection point. Often in practice, if the target is known early enough, make-before-break is great. Sometimes it is not feasible to detect who the target is going to be, so you can not do make-before-break. Do not make any assumptions about knowledge of the target. Bernard: is there assumption that the handoff is between technologies that support similiar kinds of handoffs. Is it network driven, or client driven? Q: We want to go across heterogeneous networks, we have to decide if it is network or client driven. Q3: Once we discover that we need to move, and where, what should we do? What are the signaling that needs to happen? Assume target selection is "solved" Sees other SDOs trying to solve this problem. Q4: 802.21 WG is working on this problem. When to trigger is very important. Decouple the target selection, and triggering operation. John Balbric: distinction between signaling and key management. Key management is done by EAP, and then you have some signaling method to distribute the keys, which may be very different. (Push/pull,etc.) Can not solve the timing problem for the signaling, but if we have ideas on how to do the key management faster/better, we can pick those things. SMB: ordinary key management really likes lots of randomness/fairness. This might not apply to access control key management. Jari: the IETF needs to understand some these issues, and we need to be ignorant about other things (i.e. target selection). I think that we need to be involved in the signaling / key derivation. Glen: disagrees with Jari's comments. Do not want to become an expert on every SDOs' handover method. A systems view implies that we have to do that. This is not just one system, but 3-4 or 5 systems. - - more hums - SMB: How much does the client NEED to participate in the signaling / key derivation process? A: do not decide in advance if it is client or network. Do that later. Derek: depends upon the architecture and EAP methods used. I can imagine both. SMB: people do not want to answer this question right now? Derek: believes that the client should be involved. A: client should participate, but may not need to make decisions. Q: How early do we need to make this choice, I don't know. But we do need to decide if the client is going to initiate the process. SMB: grasping on something to give a clear choice to the different solutions. SMB: Should we charter a working group in this area? ROUGH CONSENSUS. SMB: Should we take care of the key derivation hierarchy? SOME Or only it's root? MORE NO STRONG CONSENSUS. HANDS... more for key derivation hierarchy. Subir: What happened to pre-authentication? answer: it was one of the talks. Clint: did we succeed in avoiding the 18-month penalty? SMB: not yet. One of the Q's is: Alper Yegin. Another common Q: Vidya