EAP Method Update (EMU) MINUTES Meeting: IETF84 Tuesday, July 31, 2012 Location: Vancouver, BC 0900-1020 Chairs: Joe Salowey jsalowey@cisco.com Alan DeKok Minutes: Nancy Cam-Winget Version: 1 ========================================== 1. Note Well, agenda, note takers (5 Min) 2. Document Status (15 Min) - chairs Completed Documents: http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-09 http://tools.ietf.org/html/draft-ietf-emu-chbind-16 Joe: Only two more documents (crypto binding and TEAP) so if we can conclude them in this meeting we may not need another slot at the next IETF meeting 3. Mutual Crypto Binding (10 Min) - Hartman/Dacheng http://tools.ietf.org/html/draft-ietf-emu-crypto-bind-00 EAP Mutual Cryptographic Binding (D. Zhang) - Title on the agenda slide needs to be updated to Mutual Crypto Binding. At the last meeting it was decided to adopt work to use EMSK cryptographic binding to address MITM attack. Presentation: Background: peer relies on the EAP server info, can present the "lying NAS" issue. If the MSK is used, the attacker can still obtain the MSK if it is propagating the information between peer and EAP server if: - Peer doesn't validate the attacker's identity - Auth method doesn't provide keying material Mitigating factors can include: - Improve on cert validation (trust anchor and naming rules are needed) - Strict security policies - EMSK based crypto-binding (as suggested in this draft) Pros and cons of EMSK Pros: - simple and intuitive as its transparent security Cons: incapable in some cases - Inner auth method can't generate EMSK - Case where intermediate AAA Update since last draft - fixed typos - EMSK-based crypto-bind rename from "mutual crypto-bind" - Add figures - Added text on crypto-bind MAY be provided as optional facility and peer may use other means to authenticate the NAS Questions: : confused as peer has to authenticate the NAS but in the update it states to update the EAP server. Joe: asks "legal servers" really means "legal NASes" : agree, even if its "legal NAS", it is still involving the server? Joe: believes the issue is that while tunnel is between peer to EAP server; if the client can't validate the server's identity to allow the NAS to impersonate the server then it can provide whatever services it wants. Joe: asks how many have read the document: only a couple. Sean: asks what next steps are, wants to make sure we move forward. Joe: believes we need to get more to commit to reviewing it before it goes to last call. Joe asks for reviewers: Jim Schaad, Nancy Cam-Winget, and Steve Hana volunteer. Jim Schaad: instead of using MSK use EMSK, does that require peer to guess which to use or is there explicit signal as to which to use? Zhang: if its optional, then the peer has to have a means to determine this. Jim: then the peer needs to know this more long term. Joe: in tunnel method draft says it always uses the EMSK. Jim: clarifies that it presumes that the peers can always get access to it. 4. Tunnel Method (25 min) - Salowey/Cam-Winget http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-03 TEAP updates (Joe Salowey) Issued -03 draft, only 2 were really controversial but all comments on -02 were resolved. Updates include changes in terminology, more significant changes were in the certificate enrollment and use of EMSK or crypto binding EMSK crypto-binding: given the last presentation, eliminate some more cases of "lying NAS" by using EMSK. So rules are provided for its use: if method generates EMSK then use it, else use MSK if neither are used then the key is set to 0 (e.g. no key to bind to). While this is simple, it may restrict some implementations; so we could add signaling to explicitly determine what to use. Looking for feedback if this given approach is acceptable. Jim: comments that he'd need to read the document. Joe: agrees that it needs more review. - For certificate enrollment, use the tls-unique to bind with the tunnel. One thing noted is that there's an EST document in PKIX and whether we should align to that draft as well. TEAP is fairly close but don't know if there's further that needs to be done. - Dan Harkins: comments that it was raised in Paris; to prevent the tunnel attack binding, keying material is needed for both inner and outer method so not sure tls-unique would sufficient so more text is needed for allthe conditions. Joe: if you've bound to the outer method, then it should be OK but if there's no keying material generated by inner method, there's nothing to bind with. Jim: asks Dan if the validation needs to go back to the trust anchor? Dan: yes. Joe: mentions that there could be a different trust hierarchy between the EAP server versus CA server. Dan: need to follow the full path. Joe: typically when doing the enrollment, the party issuing the certificate could be different than the AAA server. Sean: wouldn't necessarily be in the PKCS#7 "bag" Jim: may be that you're getting a self-signed cert with a different trust anchor than the one from the tunnel. Joe: could be 2 different trust anchors (1 from issuing CA, other for validating AAA server) Sean: needs to ensure the peer knows which path to get so it depends on what gets put "in the bag". Jim: "get trust anchor cert" is what's needed . Joe: if its not ambiguous for the client then it should be OK. Sean: that's the problem Steve: there may be cases where the client hands the full bag to who it trusts for validation. Sean: back to the lying problem, it's good to address. But we'll need a discussion with the authors to see how to address the EST alignment too. Joe: mentions that we could follow EST but Sean mentions that they¹re not the same as EST uses a different transport. Joe: asks draft status for EST, Sean: mentions that it has a lot of comments but maturing. Joe: asks how many read TEAP: a few (5) Joe: asks for more reviewers: Jim will add and Sam may review it. Joe: will not send it to last call until a couple more reviews are done, Klaas Wierenga volunteers. Mike Boyle (NSA): what's the possibility for defining a mandatory to implement inner method? Joe: there isn't one, the document defines how to pass a password within the tunnel as well as certificate based authentication, but there's no inner method defined. Mike: either (password or cert) would be good, as concern is to get interoperability. Joe: can go back to draft to see how to get maybe the certificate based in there in the tunnel method, or specify eap-tls inside the tunnel but that may be redundant. Alan: the group needs to agree if that really needs to be specified and if so, what that method would be. Joe:right now, you can get the full authentication with the current draft. Mike: will review the document and perhaps send further comments as needed to address this. Alan: next steps if for more reviews. Once reviews are in, last calls can be done; so we can get them ready for publication before the next meeting so that we don't need to meet face-2-face. Alan: how many have TEAP in roadmap? Steve: when you're in a commercial company it's hard to make promises but customers want it then of course we'd do it. Alan: speaking as individual, open freeRadius will likely have it by end of year, same with HOSTAP so there'd be 2 open source implementations. Alan adjourns the meeting.