hokey 1520 Thursday Minute taker: Pete McCann Jabber scribe: Zhen Cao Work item status draft-ietf-hokey-ldn-discovery-10.txt Draft is in the process of working its way through the IESG No, it¡¯s in the RFC Editor Queue The rest of the documents will be discussed at this meeting. Hokey Architecture Design draft-ietf-hokey-arch-design-04 Glen Zorn (30 minutes) Would like to start WGLC now. How many people have read it? 2. Let¡¯s all read it together now. 2nd paragraph of abstract needs to be re-phrased. 1st bullet in introduction: say ¡°EAP-based¡± AKK->AAK betweem->between Change ¡°AAK the client interacts with the AAA to discovery and connect with CAPs¡±. That¡¯s not quite true. Simon: ¡°currently unspecified how EAP infrastructure can support the timely triggering¡± this is not a gap that this document fills; it is still implementation specific and out of scope. Rework last sentence in 1st paragraph of section 3. Semicolon instead of a comma before ¡°however¡± Another benefit to 3.1.1 is that re-auth can take place when the home AAA is unavailable 3.1.2: firstly->initially authorization->authentication LionelMorand: After the first round you are authorized, want to re-authenticate to preserve authorization YoavNir: I wrote this and it should be authentication Tina: in 3.1.1, when local/home server is remote, if you minimize too much, may need keepalives Simon: matter of policy; ERP server could just be allowed to extend the lifetime of the key until reachability of home AAA server is restored Tina: something about this needs to be said 3.1.3: remove ¡°see section 3.1.1¡±) 4.1: Simon: is it better to say that the authentication services could be delegated to the HOKEY system by the AAA Description of Figure 1: add ¡°or non-EAP based authentication¡± Simon: would it make sense to add a note after the bullet stating non-EAP subsystems are out of scope of this document? Sure. Simon: handover keys in scope? No. So don¡¯t mention it in last paragraph of 4.1 Actually, handover key distribution is in scope Simon: so just say AAK EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) draft-ietf-hokey-erp-aak-04 Glen Zorn (30 minutes) We¡¯re not going to read it in real-time, but please do so on your own. WGLC begins right now, will end in 3 weeks. Slight extension of ERP to designate a target access point that it wants a key sent to. Simon: a different key? its own SPI? Glen: we don¡¯t do SPIs. Simon: does the client know which of the two keys to use? Glen: sure, in the ERP/AAK request, it says where it¡¯s going. It has the identity of the CAP. Simon: EMSK associated with that key is still in the home server? If there is any request coming to the home server to compute derivative of EMSK, does the home server know which key? Glenn: yes, there is a key name NAI Diameter is used to send the key to the new CAP Probably a good idea to send a DSRK to the ER server, so it can derive a new set of keys for whatever CAP it goes to. Simon: ER server will maintain 2 independent contexts for the client during handover. Glen: there¡¯s only one EMSK, two different DSRKs Zhen Tsao: why didn¡¯t you send comments during WGLC? Glen: I¡¯m an author, we got no comments from non-authors Zhen: authors can just improve the draft, this is welcome Glen: who has read this draft? Only the authors Going to change so that it is more clear that only a single CAP is supported. Also talks about authenticating/authorizing the CAP. Not really feasible to do that. A CAP might be only tenuously related to the home network. NAS-Identifier not guaranteed to be unique across realms. RADIUS defines it as ¡°should be¡± unique to a RADIUS server. But, doesn¡¯t have to be. Need a new identifier. Suggest Diameter Identity. It contains an FQDN. AAA operation is underspecified: only works with Diameter. Many typos remain Questions Why is the key hierarchy different from ERP? What is gained? Simon: one of my questions too. AAK is a DSRK that will be activated later. Why call it something different? Glen: could be an RRK if it¡¯s going all the way to the CAP. Zhen: don¡¯t quite understand the first point. What do you mean by different hierarchy? PRK instead of RRK. Why not use the same names for the new keys? Zhen: that doesn¡¯t matter. Different usage, should have different naming Simon: same purpose Zhen: no, it¡¯s for preauthentication Simon: no usage is the same, delivering local key to local AAA server for creating the session key for the local environment. One is currently active, other will be active after handover. As for key purpose, it is the same, right? Qin Wu: two keys, RRK, PRK. Different usage, but both local keys. They do have different use/architecture. Simon: we are creating an intermediate key for local authentication, delivered to the local system, keys are produced the same way, the same derivation procedure, same hierarchy. In active subsystem, we are using DSRK. In the future subsystem that is prepared to accept the mobile, we are supposed to be using AAK for the same purpose. Future system is receiving the AAK in Diameter. Future system should take it and call it a DSRK. Zhen: difference is that in the AAK scheme, how to derive PRK from EMSK, randomness used is different. Randomness is transferred from SAP to CAP. Simon: need to look into the computation. Why not just an extension to ERP? Put it in RFC5296bis? please reply to this question on the list. EAP Extensions for EAP Re-authentication Protocol (ERP) draft-ietf-hokey-rfc5296bis-04 Qin Wu (25 minutes) Changes since previous version Replace MAY with SHOULD in 5.3.1.1. Need LDN in ERP-Reauth-Start Keep local and home distinction in accordance with last meeting consensus Separate the last two paras in section 8 as independent bullets. Simplify implicit and explicit bootstrapping Issue from Diameter ERP How to deal with Session-Id upon handover? could be the same or different session. If different, NAS generates different session-ID, need new authorization. If it is the same session, we don¡¯t know how to send a server-initiated message to the right NAS. Maybe use Acct-Multiple-Session-Id. Zhen: have you added inter-domain handover to this document? Qin: this is ERP, so it supports interdomain. Current version didn¡¯t do the change, but we plan to do it. Zhen: what is the delta between this and the original RFC? Qin: we can do that. Stephen: use rfcdiff Tina: maybe we need an appendix with a change log Glen: this is for accounting, if you start a new session you are going to get re-authorized. May need to say something about caching authorization at the local AAA server (or do it later). 2nd issue: multiple EAP servers located in the same home domain Which one has the EMSK for the session? Alternatives: allow only one EAP server, or allow local ER server to save the name of the EAP server Simon: we just discussed this issue in dime. not sure why we need to know which particular home EAP server is retaining the session? The home EAP server farm will take care of it. Home domain will find the place where the state is kept. Lionel: farm is only one option. Simon: otherwise you need to specify the interface between home EAP servers. One of them needs to say ¡°I hold the state¡± Lionel: assumption here is that you have standalone servers, not a farm, need to figure out which was the EAP server managing an ongoing session for the user. Could say home network takes care of it or we could define a generic solution that works for all implementations. Qin: local ER server can save home EAP server name. Don¡¯t need interface between home EAP servers, might need one between local ER servers if there is more than one. Simon: routing is based on the identity of the client, home domain finds the right server Lionel: IETF doesn¡¯t define this mechanism Simon: no, it¡¯s deployment specific Lionel: we don¡¯t have any solution in IETF. We can say it¡¯s implementation specific or we can specify a way to find it Simon: would rather not specify, home domain maintains context it might even move around from server to server. Local farm should manage it. Glen: not asking how to solve the problem, asking in the context of this document, what should we say about it? Magic occurs? Not a good solution. We need to say something, even something as simple as: the keying material must be available. Lionel: in that case, we need a solution. Glen: probably, but not in this document. Lionel: can¡¯t just say we leave this problem to the home network. Moving forward: Want to simplify the ERP mechanism, maybe remove explicit bootstrapping Encourage more review of draft and early feedback Stephen Farrell: Who has read a WG document that they are not an author of? Nobody. There¡¯s an issue here. Need to figure out a way of getting this done. ERP support for IKEv2 draft-nir-ipsecme-erx-01 Yoav Nir (20 minutes) IKEv2 uses EAP so it should have ERP. Having ERP allows a smooth transition between local networks such as 802.1x to remote access networking such as with IKEv2. However, IKEv2 as specified is not suited for ERP. 5296bis says: specifically, 802.1x spec must be updated and 5996 must be updated. Add EAP Start-Reauth to the IKEv2 EAP first exchange. Added: An ¡°ERP supported¡± notification in the IKE_SA_INIT response. add Local Domain Name ERP in the first IKE_AUTH exchange Issue: the LDN is passed in the clear Tina: if you need to update 802.1x in IEEE, does the system work? No. Need to send a liaison there. Glen: according to the IEEE chair, ERP does work in the latest version of 802.1x. Open Issues Local ER server for IKEv2? Home server is always reachable, so we can involve it in ERP. No use case for local server. Simon: IKEv2 server termination point is usually in the home domain, that¡¯s where the ePDG is. Lionel: can be in the local network. Simon: no, if it is in the local network, then IPsec doesn¡¯t make sense. Lionel: also some scenarios where you use IPSec and a local gateway Simon: don¡¯t know about it Lionel: you can use IPsec with a local gateway, you have IWLAN scenarios Simon: doesn¡¯t always have to be home domain, could be enterprise domain, but it has to be in a domain that the UE knows about, has to be a trusted domain. Glen: people have discussed the idea of securing just the air interface with IPsec. We are really talking about VPN access, so eliminating Local ER makes total sense. Should ask IPSECME, but they aren¡¯t meeting and aren¡¯t responsive on the mailing list. User name in ERP? With IKEv2 there is a granular policy based on user identity. Key name NAI is a hexadecimal string, can¡¯t be used for policy. Should we somehow retrieve the NAI from the home server? This is a work item for IPSECME, but they are hibernating. Closing (5 minutes) ========================================================= Would like not to exist as a working group by the time Taipai rolls around. There has been minimal activity. StephenFarrell: go find people, get comments on the list. Simon: or turn these documents into individual submissions Stephen: yes, could take them as AD sponsored or independent stream. Not saying that¡¯s appropriate.