Minutes on HOAKEY and Preauth BOF, IETF 65th Dallas. Co chairs: Madjid Nakhjiri and Yoshihiro Ohba Outline: Agenda bashing Introduction Handover Keying Pre-authentication Application Keying EAP keying gap anaylsis Scope/non-scope Charter summary presentation: Madjid provided a summary of the current combined charter Combined charter: Handover latency is a big issue. Access authentication and key management cause large delays and can be solved by two ways 1)One way is preauthentication, runs EAP 2)Derive keys for new attachment based on existing session Application Keying Providing full service access requires various network signaling protocols Ways to bootstrap many of the security association Presentation Handover Keying: Madjid Handover in Wireless Access Networks and providing security requires re-establish secure links with new BS. EAP keying for fixed peers means pushing MSK down to the BS. After EAP, the peer and the BS do a SAP. When we need to do handover, we should not use the same MSK at the new BS, When we need to do handover, we should not use the same MSK at the new BS, this means we need to send a new MSK to the second base station? An architecture with Access Gateways was shown, where the gateway acts as authenticator and BS acts authenticator port. Both Intra-authenticator (handover between BSs within the area of the same authenticator) and Inter Authenticator handover were discussed? It is still seems that for inter-authenticator handover, new re-authentication is required. An optimization to use the initial EAP for inter-authenticator handover should be possible. The idea is to Use EAP generate master keys EMSK/AMSK as the root key and create further keys and extend the hierarchy to create per-authenticator keys and then per-BS keys to support both inter-authenticator and intra-authenticator to avoid new EAP authentication as much as possible. Define key derivation at each level down to the AP. Try to specify whatever it is within IETF scope and provide guidance (for SDOs) on whatever is not within IETF scope. As well as guidance on channel binding, key caching, storage, etc. Also, Protocols for key request/distribution for handover optimization: proactive or reactive key requests/ fetch as well as requirement for secure key transport. Questions: David Perkins: This is exactly CAPWAP and what CAPWAP working group is doing ? What is the difference? People: Dave Mitton: CAPWAP is all about 802.11. There is much more generic. Madjid: This is to cover all the access technologies. Not about 802.11 and not about PHY/MAC separation. This is specifically about handover. David Perkin: Ok, your model has Access nodes and authenticators. In Capwap, we have the same model, AP and AC (as gateway) and they have AC-AC communications (authenticator-authenticator). A bunch of vendors Cisco/Aruba also support this today. Madjid: The picture shows a common deployment model, Just because the architecture looks the same, it does not mean that they are covering the problem we are solving. Yoshi ? CAPWAP does not specify between Access Controller/ authenticator. some people do provide inter-AC communications, but We need some standardized way of doing this optimization for inter-authenticator handover. Sam (AD): your group is focused on key hierarchy and keying, right? Madjid: Yes, we are covering Domino Effects ? CAPWAP is not going to do key hierarchy design Sam (AD): Even if you need CAPWAP to do the signaling protocol, you still need the crypto to be done somewhere. I am hoping CAPWAP does not do key hierarchy design. Maybe the protocols look like the capwap signaling, but what really flows over the protocol is not in CAPWAP. Lady ? Stefan ? Gateway , what is not clear , is it between 802.11 or any access technology? Madjid: for any access technology. Lady: Switched architecture: Airespace has a Proactive key caching approach airespace in the switched. Is there a new approach? Is this for all access techs. Bechet: CAPWAP ? draft presented in CAPWAP? but not clear whether CAPWAP is interested in roaming solution. Would like to present a draft next time. Madjid: lets see if there will be a next time, sure otherwise. Dave Nelson: Potential similarities between 802.11r EAP framework document Madjid: Proactive vs. Reactive. Major focus is on key hierarchy. Depending upon what approach people have. It all depends on what sort of trigger you have and how you want to optimize the handover. Next presentation (Pre-authentication: Yoshihiro Ohba) ================= Motivated by 802.11i pre-authentication, so that it can be done at the higher layer so that pre-authentication can work over multiple technologies and so on. Objective is to Minimize potential performance degradation due to handover, performing EAP prior to handover, using the connectivity to the current network. There are cases such as inter-domain handovers that EAP authentication will still be needed. In general, If we do access authentication and authorization before handover while connectivity is available there should be no performance degradation due to handover. Two ways to do pre-authentication. 1 way: MN and target authenticator communicate using the current authenticator, but the current authenticator is completely transparent in signaling (work in PANA working group). We can use EAP keying signaling, to use MSK. We need some extensions to provide pre-authentication.Backend AAA signaling may need extension or pre-authentication. Second way: Current authenticator is involved in the signaling, and the pAuth and target authenticator interact with each other. Current authenticator 1 invokes signaling. What should be newly designed to achieve this model. In some cases mobile host may not know what is the target authenticator, that might introduce some network based pre-authentication. Impacts on pre-authentication on AAA: Avi Lior ============================================ There are 5 main issues. The goal is to not have another AAA dip when or soon after the mobile moves. Pre-auth should pre-authentication as well as pre-authorization. -The AAA server needs to know that the new access request is related to a pre-authentication, otherwise it might reject, if there is policy that the mobile can only authenticate to the network once. The AAA server needs to know how long to wait for the pre-authentication before timing out. Session timeout for pre-authentication may be different from normal authentication. If the mobile moves after the session timeout, then the pre-authentication can become normal authentication. Resource Reservation, How do I get all the resources I need a the target autenticator, whatever you have prior to handover, needs to be reobtained. context transfer of the resources when the authentication is done may be a way to do this. Accounting: Pre-authenticate may require reservation of resources prior the user moving there. Accounting records may be needed for guaranteeing this reservation at the time of pre-authentication, not when mobile moves. The Operators may want to bill for the resources being held and the user may have to pay for that. the user may end up paying double. so the records may be needed at the time of pre-authentication, and not after the move. Pre-authentication can help allow the context transfer Avi: . Charles Perkins: Requirements for Pre-authentication, time limited reservation, 100 ms. Q Aidan: Comment on last bullet statement, noting double billing. Why wouldn't you generate accounting record at the time of actual movement? Let the billing situation sort out at the end. This is another possible way to address this issue. Avi: If you basically choose to ignore it, then you have to consider how much it will take for pre-authentication. If you have 15 minutes of unused resources and there are millions of users that you are not getting compensated for it. Can you stand it? Q: If there are certainly big numbers, it does have an interesting effect on how many pre-authentication attempts there are. Probably we want to design not knowing the number of preauthentications. Q: My question is, it seems to be widening the scope, one thing that is obvious is authorization. Authorization is considered the same as reservation. But I think you should define yourself the resource reservation. Avi: When the target network is starved for resources, Authorization is a reservation for a VoIP path, you want to guarantee that. By this authorization you will prevent others to use that reservation. Madjid: I would like to clarify. This is really about pre-authentication not a full pre-AAA, defer to charter discussion. Dave Nelson ? What sort of resources are being reserved and how long may be discussed later. But one of the confusion points comes to my mind is the notion of reservation of resources first at the beginning of the session. You consider that a session can start based on pre-reserved resources while a session actually starts when the mobile actually arrives and uses the resources. It is interesting to connect that distinctions. It is good if in this meeting or the next meeting we can discuss the nature of resources that are reserved is supposed to be more general discussion. this meeting or next meeting Madjid - Main problem to solve how to avoid full EAP exchange during handover, there are a lot of problems to solve during handover, so we have to see which ones we want to do. Application Keying (Kuntal) ============================ Problem stated in Hokey-amsk-ps-00.txt Mobile doing authentication with the same server again and again. Mobile operators may offer multiple services, mobile authenticate for IP access (MN to NAS) then for Mobile IP (to AAA infrastructure, HA/FA), then SIP service (MN- xCSCF), Mobile IP server: AR-HA. In each case operator requires authentication transactions. It seems that to get to one service you have to do multiple authentication and that is the problem we are trying to address. Scenario 1; Multiple EAP scenario MN wants to get service, the Multiple EAP transactions with the same network is shown, first access (EAP), then Mobile IP registration (again EAP), then with service equipment (another EAP). We are doing 3 EAP transactions for this scenario. EAP is used for network access auth for many network services. This increases network load and call set of latency. Scenario 2: Mobile IPv6. Integrated scenario (Mobility service provider and authorizer are same). How to solve these two problems: Use the EAP during access authentication. Use EMSK to generate AMSK and describe how to distribute the AMSKs? and how to cache, etc. Two models for AMSK generation: Push vs. Pull Model Questions Sam: There was a BOF that went into a fair amount of details. A couple of conclusions: First of all, SIP is outside of the applicability statement for EAP. You should not use EAP for SIP. There are some mechanisms that EAP shares and SIP shares (AKA). There is some significant concern about layering, I would ignore that concern and say you could do that, but this will need to significant community discussion if you want to do that. I Recommend other approaches for eliminating this authentication rather than by reusing the single EAP authentication. E.g. Mobike may be another approach for eliminating the Mobile IP authentication for all access networks, for solving the authentication at various layers. Kuntal: How MOBIKE can be used. I am talking about double IPSEC with a gateway, with HA behind it. How could I do double IPsec just to get HA. Jari: You only want to do the Mobile IP stuff only once. Once you create the SA you are done, it may take a while but after that you are done. Kuntal: The issue is that I have to hit the same server multiple times. Jari: not sure it is significant. Jim Kempf ? Only scalable way of doing authentication/authorization on Internet is via TLS. 802.11 said we can only use AAA and PPP, they spent incredible amount of time. Right way to do it is use authorization certificate Jari: There are some cases where AMSK are useful, but your examples are not very good. When it comes to other services such as SIP, there are other credentials and authentications are being specified and there is no needed for such keying solutions. Kuntal: The point is we need to do optimization. Yoshi: There are certain usage of MSKs, could you provide examples. Jari: I do not have a good example myself Madjid: Getting into the specific example, I don't have background for using or not using EAP for SIP. The generic problem is this,there is a protocol that has two agents, and a peer. The protocol needs keys for securing the signaling between the agents. People seem to go to EAP to get the keys. This is what we are after. We have EMSK from EAP, how to get AMSK per application and then use AMSK for keying that application. Maybe the example provided here was not useful. Pasi: Sure Scheme solves some round trips, whole point of Internet is separating the layering principle. Hard coding business assumptions where multiple services are provided by the same providers to make a generic solution is poor engineering, severely limits the applicability of solutions. Kuntal: Most of Access authentication do EAP. If the provider offers two services and they are both at IP layer, if you can derive two AMSK at the same time what is the problem. Pasi: If one hard codes the assumption business opportunities, it is limiting. Madjid: There are two scenarios. Layering is the issue with only one scenario. the other is using EAP for one application. do you have an issue with that as well? Pasi: coupling the services may increase the complexity, I run EAP for Mobile IP. There are two scenarios, One you like one you do not like and it seems we are in agreements. Vidya: saving roundtrips should not be presented as motivation for Mobile IP, it is really about the bootstrapping issue. Sam: Recommend seriously decoupling of the rest the material from this item and see if you can get consensus on anything rather than having the hole BoF fall apart. Vijay: People should stop picking up Mobile IP as an example. Mobile IP works regardless of what you do here. Madjid: Clarification, I gave a specific SDO problem for application keying and people were interested in that. Subir: Comment (Handover optimization) and this presentation are two different problems. Madjid: Only coupling is rekeying John Albert: Idea of keys getting generated, if one can have single sign-on for a particular provider and do keying for multiple application it would be great, I would applaud the discussion, even though the use of EAP can be debatable , Good idea Dave - Two things related to key hierarchy: 1) Rapid handover, 2) trying to form a single signon- EAP is for network access not application access. We should not cross that boundary. What respect to handover, Do we need a suitable attribute in AAA or Radius to provide pre-authentication. Yoshi: In term of pre-authenticator, in addition to AAA attributes, some Signaling between authenticator is needed besides the attribute. May mean some additional work for layer 2, but we hope we don't have to do mods to layer 2 Joe Saloway: Issue of coupling between the layers: why there is a discussion of using EAP, I am not sure about why there is an issue with applicability of EAP to higher layers. Parviz: The focus is on How to generate keys, If we are really limited to layers, we should then just say, MSK key generation will be limited to layer 3 only., Layer 3, layer 2 layer 4, where to limit the charter/key distribution. Madjid: Please Sam comment. I don't know issue with supporting SIP with EAP. I can understand the issue with Mixing layers. Sam mentioned that Sam: EAP is designed for network access, go to RFC and look at applicability statement, SIP is not a network access, despite what some people have done to it. Bernard: Sam quote is pretty accurate. It is little bit puzzling, there is an application layer security solutions, linking Kerberos to EAP you could do application keying if you needed. Whether there is something like that is the issue here? a bunch of applications are already kerberized, is it figuring out how to use Kerberos with EAP? is that the issue here?, should we get a certificate that we should use SAM: He would be happy to see Single sign-on solution, but let us not do it here. Some people: why not? some laughs... SAM: there are a bunch of items in this charter. The probability of getting consensus on this specific item during this session, If we spend most of our time on this items on this session, we will make it very unlikely for a working group getting formed is very low, even though there are other items that have sufficient consensus. People can propose a bar-Bof to solve that solutions. Unless it is very critical to the over problem statement, we should not spend time on this problem here. Madjid: Be clear that next is a personal presentation and is the view of the presenter and is not clear whether it has a bearing on the charter or not. Extending EAP keying, EAP keying gap analysis, Qualcomm ============================================= Personal presentation thanks the chair for giving us the slot, being late request... Motivation for Extending EAP what are the issues with the work done in EAP WG. concerns with HOAKEY drafts. Presenter: These are our individual opinions and does not reflect who I work for. rehash of issues talked in other presentations: Handoffs, Pre-authentication, Localized re-authentication Proactive Keying, Bootstrapping legacy PSK-based application Extensibility for future uses?? Areas of Work Key hierarchy, naming, derivation, distribution, etc Madjid: You say next step here, what does that mean? where do you think this work will be done, here? or in EAP Vidya: not included in the charter so far. Bernard: EAP WG is shutting done. Extension for EAP is important to be done based on a problem statement and to see what you want to do first, which items would be critical. Madjid: Those problem statements may not be valid for these charter. We went through Russ AAA key management draft and added the security goals and definition of various entities and the SAs between them. EMSK is the product of EAP, I am not sure whether EMSK to AMSK specification has to be done here and I don't think we should put everything on hold for that. Bernard has an extension draft that talks about many of these. If people want to solve other EAP problems, maybe that is a good idea for another BoF, but we have specific problems we want to solve. Yoshi: One of expected outcome of the group is the Keying hierarchy may contain the problem statement. Madjid: The idea is the solution should include the security goals. could be in one or two docs. Vidya: There is no proposition on AMSK/EMSK usage guideline that describes how the AMSK can be derived. Joe Sal..: You need to both in parallel and you will find good application that will help you. Madjid: I agree EMSK to AMSK needs to be done. Where this work should be done is the question. Jari: EAP WG talks about EMSK, but the derivation of AMSK is not done. There is a need for specifying this for people who needed. Madjid: Presentation on What are out of scope. ============================== HOAKEY out of scope: No Extending EAP, EAP keying, or over the air EAP signaling, no new RADIUS messages, but may RADIUS/ Diameter AVPs. No new signaling security extensions. Pre-authentication out of scope: Yoshi: No proactive IP address configuration-Pre-authentication. Making changes to L2 security is out o scope Handover keying Deliverable: Madjid ============ Handover Keying hierarchy draft (Informational RFC) functional model, entities, key derivation, reqs on caching/distribution Not sure whether informational or regular, open to suggestion. Handover keying protocol requirements (informational RFC) either use existing protocols, or extend them, attributes, Signaling Optimization try to get the keys at appropriate places in a good time related to handover. Application keying ? This BOF may not focus on this, so skip Pre-authentication deliverable: Yoshi ============================== Protocol requirements AAA attribute requirement, two scenarios for pre-authenticator Current authenticator is transparent and in second case the current authenticator is not transparent. Q/A session ============== Madjid Q: Are these problems to be solved? more problems to be solved? Parviz - Identification of L2 changes we can only recommend to SDO? Yoshi: requirements, guidance is to be provided here, actual changes done in SDO. I hope we don't require L2 changes to support pre-authentication. Parviz: Suggest to remove that line from your deliverables. Pasi: When you do handovers, you have to move a lot of states, Most of the states that are being managed are not keys, why such big focus on Keys. How about the rest of the states? Why not design a procedure for all states. Madjid: Since it is security, Seamless mobility group in IETF did context transfer. There are Security issues with moving keys, we are trying to avoid that. There may be situations where you run out of options. Pasi: does not seem you should have multiple protocols here. Alper: Mobile IP moving IP related things, it does not do other things. Madjid: can you do QoS reservations inside Mobile IP? there are all kinds of things you do Uri Blumenthal: Keys are special context, they require special treatment. Bernard: If you read IETF context transfer, it does talk about keys. They are saying that that practice is insecure. 802.11r uses anchored authenticators, Madjid: A lot of SDOs are using context transfer, simply due to the availability of the proper trust model. one may not have the trust model available. We need a solution for that. Uri: Just wanted to say that. Dondenti: Confused by Informational Standard, What are these ? Alper: There are two kinds of documents here. Keying hierarchy is following the model of EAP keying draft (that being informational). The other thing is Protocol works belong to other SDOs, such as RADEXT and Dime, so that is why it is info. dondenti: Requirement makes sense, but why the hierarchy is informational. Madjid: I think AD s should talk about whether to have informational RFC. Having an informational RFC is the most modest way to go. Dondenti: Modesty is not required. Why are we not talking where the key comes from. Madjid: I understand the issue with the key derivation. Whether that is an item for the WG. Madjid: We tried to be independent of EAP changes. Decided to use AMSK key, let us just call it xMSK. We have to have somewhere to start it from Stephano Facin: Abstract model, Analysis of which link layer. Having a new problem statement draft is important. coming for IEEE, 11r does it, 3GPP does it. Madjid: The work has been inspired by 16e not using 11r. We are not ignoring 11r (but that is evolving for 11r). We are too late for 11r and 16e. EAP is an IETF protocol, people will go to IETF for getting EAP specs for mobility, so for next 802.xx we will have a solution. In the meantime Stephano Faccin: We need to have a practical justification, who is using it. There is no specific requirements from SDOs. Madjid: Tell me, how many SDOs are using Mobile IP? It never stopped IETF to developing protocols that are appropriate for entire Internet. Many SDOs including 3GPP are evolving their system architectures. There is not keying solution out there today. They either do context transfer, or have a backend entity that does encryption/decryption such as that in SAE proposal. I don't think we need to do work based on SDO request. Faccin: Move SDO requests out of your justifications. Sam: SDO request is not required per RFC 2418, but whether the work would be useful. But we need to make sure people will use the specification, We produce requirement documents in this space. Jim Kempf: Preauthentication why not in PANA WG Yoshi: There is a PANA pre-authentication draft being developed in PANA WG, but there are other things need to be specified for pre-authentication to work. AAA requirements are one of such things that are outside the scope of PANA WG. We are also identifying the other pre-authentication scenario in which current authenticator involves in pre-authentication signaling, which is not part of PANA. Jim: Note back to Bernard comment on use of Context transfer. RFC 4067on CTXP does not make recommendation on doing context transfer on KEYs. That is a bad idea. Yoshi: More thing: The other pre-authentication requires inter-authenticator communication, but only EAP messages are carried over this communication. There is no key transfer between authenticators required to realize pre-authentication. Bechet: Trying to understand the scope of the BoF, Pre-authentication , What is the relation between handover keying and application keying. Madjid: Handover keying and application keys are not related only coupling is EAP. Madjid: Application keying is getting more resistance. Bechet - As per Jim - what is wrong in transferring key using CTXP? Yoshi: Please look at the AAA key management doc by Russ and Bernard. Madjid: AAA context includes a lot of more than just keys, bandwidth, accounting, authorization context. If you generate keys that supposed to be alive for a time, and you move it over and over again, without thinking about life time and compromise. Vidya: xMSK we have not defined AMSK or EMSK, we don't care? Madjid: that is a different issue Vidya: you can't start anything unless EMSK to AMSK. Madjid: are you ok if we include EMSK to AMSK, are you ok with the rest. Vidya: No. Laughs.. Sam: Is the handover protocol intended to run between two authenticators, suggestion would be going to AAA: Madjid: This is part of solution. My idea of the solution is that you would go to the AAA server. Bernard: if you have AAA server across the world. Do we need to go to AAA server all the way? to optimize the handover. Madjid: We would like to use AAA server complex as the trusted authority, it could be home AAA server or visited AAA server. Very few of EAP methods provide fast re-authentication where you can do a quick exchange with the AAA server with a quick exchange to do that. That is what I am looking for. A simple request signed with a specific key to the AAA server and get be done. Bernard: SAM's original question on whether this will be used or not, SDOs like to create their own security association and figure out how to do that. A useful thing to do that they have not done yet or shied away from, is authenticator to authenticator portion. How authenticators obtains keys from an anchor point, that protocol is not defined in 11r. protocol based on EAP and not based on the L2 protocol. you don't go back to any AAA protocol, you go the proxy based on latency issue. describing 11r does not define the protocol between authenticator and authenticated Subir: Whether we should local AAA and home AAA, fast authenticator, with pre-emptive authentication, you can do it with the AAA server, when you have time, the other thing one authenticator to another authenticator. Vidya: Q on Pre-authentication. How about Radext and Dime? Yoshi: we need to first identify requirements, before pushing attributes there. Vidya: Can Requirements come from PANA WG? Alper: there are multiple scenarios. One is PANA based and one is not. We need to identify all the requirements on RADIUS and Diameter. Kuntal: Inter authenticator for every handoff one has to go to AAA Madjid: Russ please do the wrap up question. Ross: ====== Raise hands on these questions: Why we are all here? The BoF attracted a lot of people. Make sure something happens something happens? A lot of people Something does not happen? not many Out of Curiosity? Constituency: vague definition or proceed with WG- Needs much greater clarification or not? numbers are roughly Equal Interested in Handover Key? 1/4 Interested in Pre-auth ? 1/4 Interested in Application keying ? 1/8 Whether a second BOF and more aggressive (clarify the charter)? on another BoF 1/3 of room aggressive chartering work before next BoF 1/3 or the room.