EAP Method Update Working Group (EMU) Minutes Meeting: IETF-82, Tuesday, November 15, 2011, 0900-1130 Location: 101B, TICC, Taipei, Taiwan Chairs: Joseph Salowey , Alan DeKok Minutes: Nancy Cam-Winget Version 1 ===================================================== AGENDA 1. Administrivia (5 min) Note takes, blue sheets, Note Well, Agenda 2. Channel Bindings (45 min) http://tools.ietf.org/html/draft-ietf-emu-chbind-11 3. Tunnel Method (60 min) http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-01 4. EAP Applicability Statement Update (10 min) http://tools.ietf.org/html/draft-winter-abfab-eapapplicability-01 ====================================================== Meeting Report 1. Administrivia Nancy Cam-Winget assigned as note taker EAP applicability statement added to agenda ------------------------------------------------------ 2. EAP Channel Bindings - Chair asks how many reviewed draft: about 7 people Chair: Sam has been working through latest set of comments. Would like participants to raise issues now (if any) even if it has completed WGLC - Some technical issues raised: - Code point assignments start at 1 - Namespace identifier uses RADIUS namespace to cover group's needs, question was whether to include DIAMETER. Felt this was not something that needs to be done at this time but doesn't preclude us from doing so (including DIAMETER namespace) in the future - Alan raised comment on what RADIUS AVP looks like (as informational note): leave it there as it helps with clarity - Values are returned in channel binding responses: returns what the client sends - Yoshi raised ERP interoperability (slide has typo, EAP should be ERP). Yoshi requested more info which has been fulfilled in the latest revision - EAP server reflects value sent to it by client in channel binding response but client MUST ignore the value and only look at the presence of the attribute itself. - Added EAP lower layer attributes. Joe enumerates them: 802.1X, 802.11 (no preauth and pre-auth), 802.16e, IKEv2, PPP, PANA, GSS-API, PANA. Diffs in 802.1X versions were removed since EAP processing is the same; in 802.11 some cases were removed where EAP was not used Hao Zhou: asks why the numbers are not in order and numbers are missing: Joe: states that's because those items were removed, but will have to ask Sam why the renumbering was not made (to be contiguous). Hao: asks that draft does state that it can work with ERP so what's the request. Yoshi: responds if lower channel binding is there, it can work with ERP, but here it is method based but believes that the current text is fine. Joe: says ERP channel bindings may not work Yoshi wanted mention of lower layer channel binding as it doesn't exist, but once it is defined it should be made to work. Hao: reads the text from the draft and asks if we need to explicitly add text to state that it would work. Joe: asks if text is ambiguous. Hao: states the previous bullet asks that channel binding doesn't work with ERP, but there's no text to explicitly state that . Joe: mentions that today, it doesn't work so perhaps we should look at the text to improve on this. Joe: continues that other attributes were raised with 802.21 but as it is still in draft didn't want to reference it. In 802.16m the EAP processing wasn't necessarily changed, but don't know enough whether it does get affected and thus should be added or not so for now its not included. It seems that it's the same lower layer, so may not be appropriate to add another attribute just to deal with PHY differentiations. Nancy: mentions that we did not do so for the different PHYs in 802.11 Yoshi: mentions that 802.16m will be published as 802.16.1 so it would be considered as a different lower layer. In his mind it is very different than plain 802.16. Believes it is not a revision, it is a new spec. Joe: asks whether 802.16.1 reference 802.16e; Yoshi: "No" Nancy: asks how the security was handled in the new draft. Yoshi responds that the text was copied from 802.16e to 802.16.1. Joe: believes that we should just move forward with what we have. Dan: agrees that we should just move forward too and asks about numbering sequence. Sean: mentions asking same question to the list. Joe: states that it may have been an oversight. Jim: mentions there's a sentence to say holes are numbers to be assigned. Dan: says it seems odd. Joe: asks if there are any other comments? Seems like a sound approach, no fine grain differentiation in the lower layers (like 802.11) but if group believes its needed it can be done later; though one can argue now that it may or may not be relevant to the connection. Goal now is to define the minimal set. No further comments. Joe: continues with updates: some editorial issues were clarified: AAA attributes may be inaccurate so text has clarified them. Peer and NAS do not share trust which is the point of this exercise (e.g. enhance the ability to do so). Constant sort of tension between AAA and EAP server as they are diff entities, though in real deployments they are bound together in spec clarifies that they are separable. Joe: concludes that this is current status that has covered all issues. Only last issue may be final review of ERP and numbering so unless there's more issues we can pass this to IESG soon. Does any one have any other issues? Jim: not sure Sam's addressed a couple of his issues, so will rethink as to whether he may raise more issues on the list. Joe: notes last call has ended but would like to close all issues in the next 2 weeks (beginning of December given Thanksgiving). Glen walks in Joe: asks him now that we've gone thru the issues and asks if there are any other issues to be raised. Glen: responds that he may; as he understands, WGLC ended and he didn't get a chance to provide feedback so asks why we're discussing this now when in theory we should be done now. Joe: responds that he's not closing if there are still issues to be raised, but wants to close as soon as we can. Glen: states that he didn't know that, as Bernard has been known to throw them away (comments after WGLC) .notes that there are fundamental issues with draft and believes that it will not work (as it reads) and will send an email as its too complicated to go through now. Draft doesn't allow anyone to detect a lying NAS: example, suppose there's an attacker that's installed an AP which is not connected to AAA infrastructure but has channel to corrupt AAA proxy (unofficially), proxy has channel to AAA-infra. AP amplifies to attract victims to advertise as a "real AP" (e.g. its lying about everything). This draft assumes EAP server holds DB of stuff which is treated as if its secret, but its public (as anyone can get info on advertised info) if victim seems the bad AP, it can be lured to connect to the bad-AP and do the channel binding and all the data will come out right and thus be connected to a bad-AP. Joe: states when referring to a lying NAS, it's not a bad-AP Glen: says its not for that case, or we can say and concoct to special solutions, but draft claims to be a special solution that it is not. Joe: clarifies that it doesn't state the problem space for which it was designed. Glen: agrees, and we can discuss that problem space as it appears that it is for ABFAB but doesn't feel is being heard. If draft says all the right assumptions, it raises another question: if it is ABFAB specific, why discuss it in EMU vs. ABFAB? As that group is willing to change all kinds of other things too. Joe: states that current document there are examples that are not ABFAB. Glen: reiterates that there is a long email from him to describe this: that problems to solve are rather simple but there are examples where this draft does not solve and it takes some text from Glen to convince the group of the issues thought that he missed WGLC and would submit in IETF last call. Joe: asks on timeline. Glen: is pushing to get another (different) RFC published, so it is going to take him some time as that is his first priority; maybe after next week? Joe: asks if there are suggestions for how to fix the document or not to publish the doc? Glen: wants draft to be extremely clear of what is actually solved and what is not solved, will make it less impressive but is OK with draft being published (skeptical whether real or general case can be solved). Joe: reiterates that there are a couple things to resolve still in the next couple weeks and encourages Glen to submit now so that we can close but will not hold up if we need to keep waiting. Glen: agrees but he has another draft that is more important than this; Hokey should be done soon so that can free him up to address this too. Joe: concludes to encourage Glen to submit comments as soon as he can, but group will not wait for them. Glen: objects that Joe can not say that the draft will be published as there's still the IETF LC . Joe: agrees but wants to keep making progress and better if it goes before IETF LC: would also be good if suggestions were included to move draft. Glen's: not clear that problem is solvable. Joe: says fine, but given appropriate scope it could still move forward. Joe: asks if there are any more comments? None given. Joe: concludes that it will take a couple weeks to get the remaining issues before it goes to IESG; if Glen gets time and provides comments, we'll try to address them. --------------------------------------------------- 3. tunnel Method Update - Hao Zhou presents current status: -01 issued to address some of issues provided. Since then, more comments have come in; Hao lists reviewers and thanks them for their review. Issue tracking list created: 13 issues now and encourages more review -Provides chart of the 13 issues and which ones addressed in -01 -Starts discussion of each individual issue. -Issue 28: closed as -01 renames it to TEAP .asks if there are questions Dan: comments that TEAP was not on the list discussed at the last meeting. Hao: mentions that TEAP was one of the candidates . Glen: asks how the name was chosen. Hao responds that at the last meeting the consensus was to let the editor pick, asks "so what is the objection to the name?" Joe: states that naming is fine; if we really have a problem with this name we can do a global replace on draft. But don't know of good process for naming the method. Mentions that Sean mentioned "that we throw a dart" to choose. Glen: believes that this would be appropriate to vote for the name and mentions name (TEAP) was already used. Hao: responds that it was never used publicly. - Joe wants other issues covered asks the group move on. - Issue 29: changed version from 2 to 1 - Issue 30: Dan sent comment on PAC provisioning thru TLS ticket or within Phase 2 .updated text to bring in some text in a couple sections to reference RFC 5077 and PAC provisioning in Phase 2 (section 3.8) - Issue 31: support for outer TLVs in the initial messages are now included in -01, the AID is now sent in the outer TLV - Issue 32: since we're now including outer TLVs, and EAP-Type are now included in the crypto binding in draft -01 - Issue 33: this is still open. Dan raised prev draft used PKCS#7 but now needs how request was sent, so added PKCS#10 in -01. Asks if Dan is OK with this. Dan: mentions there's a typo and why it's still open. Hao: says some text may still be needed for how enrollment needs to be clarified. Joe: agrees that we may need to reference other enrollment text or if the current text is sufficient. Dan: is OK with this. -Issue 34: mandatory to implement was discussed on the list for when server is not authenticated by the client. Current spec doesn't specify mandatory to implement method; Dan: suggested one but there is still discussion on the list and Hao presents option of whether to just leave the current text or whether we describe this in a separate document. Dan: mentions that when he raised this only objection was from Sam and he objected as text was optional; so Dan would be happy if properties for what is required is fine as Sam's suggestion of a method didn't meet the properties. Joe: asks if we remove text of what is mandatory to implement ok? Dan: says sure, can remove any method name reference but list out properties and did provide some text (just remove pwd). Hao: says can look at it. Glen: responds that even if it's optional, need to define how it is to be done or as Dan says, list out the requirements. Its fine if we move it to a separate document, but if so, then text needs to be removed from this draft. Joe: agrees, but there are 2 options: either describe it as with properties versus what method it is to be or to just move it to separate document (and remove all text from this doc) for what the mandatory to implement should be. Glen: prefers the latter approach: to remove it from this document that updates this document for how to do provisioning. Sean: piles on that this can just be treated as "for future discussion". Joe: states that if we list the properties it leaves us with ability to address it later. Dan: disagrees with Glen as having another draft will take eons to complete. Joe: presents an option is to start working on text (though we're not chartered to do that) to fill the gap as there'll be discussion on that. Joe: checks consensus of the group, Hao clarifies that there are 2 options: Add text with properties or remove it all together - Joe asks choose option: (1)Remove all reference to cert provisioning or (2)add some of Dan's text and leave open to what method to use - favor option 1 (only 1 hand) option 2 (about 4). Joe will take consensus check to the list. - Issue 35: discussed at last meeting, -01 restarts numbering at 1. Dan: mentions that there are still gaps in the numbering, why can't it be sequential? Hao: mentions the only reason is that PEAP and FAST already uses some of the numbers so would like to share code. Dan: mentions that this is new method TYPE. Glen: mentions if you're hardcoding don't want code, e.g. its not a good reason. Joe: closes that this can be taken to the list as its not a big deal either way. - Issue 36: Jim raises that if there are multiple EAP sequences, not clear on what to use for peer ID and server ID. In -01, the first authenticated ID is used even if other IDs are used. Joe: mentions that there are several places where authentication takes place (e.g. in the tunnel or in the tunnel itself). Hao: says if it's in the tunnel, then that would be used. Joe: says if the cert in the tunnel used and an inner method uses a different ID, seems that the inner method would be used. Hao: mentions that there would be an issue of synchronizing peer and server. Joe: says that's fine, you use whatever ID is provided. Jim: asks whether then we now need a distinguishing between peer and machine ID? Hao: says the draft makes no such distinction. Steve: reiterates there are cases where there is no user. Joe: is not comfortable with this being a closed issue as there needs more discussion, as if there is a machine authentication first then how do you assign this? Jim: asks other than PAC, is the peer ID used for anything? Hao: believes the PAC doesn't use it either. Jim: asks if the peer ID is used for anything? Joe: states that the output of the authentication should be based on a peer ID. Jim: says that in theory for the policy it should use all of the IDs used inside the method. Joe: states there is no description in the EAP doc what methods outputs in a standard way, do we need to change this in the tunnel method as there are multiple identities as they may all be important; so am nervous that it is only one. Steve: mentions that if doing a NEA exchange, the concept of single ID would be basis of access control may be somewhat dated. Joe: mentions that document should reflect that peer ID could have multiple parts or leave the text looser? Steve: not sure that its appropriate for this document for changing the EAP framework, but maybe list the limitation: if it only supports one peer ID then it only does. Hao: states that it may not be limited to one, it could send back XML will all the info if needed. Joe: states it could, but is that what we want to do? Steve: doubts vendors have done this, his product doesn't do XML; is this conceptual and nobody really uses this? Joe: asks are there other places where peer ID is used? Steve: asks if we can ask this to the list to see how implementors do this? Joe: says yes. -Issue 37: Jim provided comment on version negotiation to clarify when peer only supports higher version. Next draft can clarify that NAK would be sent - Issue 38: Jim commented a couple issues crypto-binding process. Next draft can clarify that it will run after every inner method and if a method is skipped there would not be a crypto-bind. To discuss is that if we skip the bind then the outer TLVs may not be protected if the inner method is skipped. So proposal is to always run at least one crypto-bind regardless of whether an inner method is run or not. - Issue 39: proposal to remove EAP-GTC as the reference - Issue 40: proposal to clarify how the channel binding TLV can be used bidirectionally - Concludes that there are a few of the issues that remain to be discussed on the list so that we can submit another version and hopefully move to WGLC. - Joe asks how many have read the draft: about 10. comments that we are making better progress than in past but would like to get more reviews and issues resolved. Asks if any more comments: No 4 EAP applicability statement(from ABFAB) - Draft-winter-abfab-eap-applicability discusses things like authorization, endpoint assessment, credential management, different lower layers, application use put bounds on what are good things that can be done, what's already done - Encourages people to read and comment on draft - Endpoint assessment needs to be updated - Expects it to be an ABFAB document but needs to be reviewed in EMU and NEA and other in Glen: comments that this is just wrong channel bindings is really just for ABFAB and EAP Applies to everyone should be in EMU Leif: ABFAB does not care where it happens Stefan: Draft contains more than ABFAB Glen: Agrees. Why not change the rules so that blithering is OK? Stefan: NEA over EAP is fine so there is a conflict Glen: What the IETF wants to sanction is interesting. Just because you want to do something does not make it correct. Stefan: is NEA wrong Glen: yes Leif: Running code is what matters. This work will be done as it is on the ABFAB charter Steve: Lets have some real discussion Glen: Chances of having real technical discussion is nil. Joe: I hope we can uncover why things are problematic. Talk with Sean to see were is its appropriate home. Sean: we can update a charter is needed. The ADs can work out where it goes. Steve: it seems clear it belongs in EMU. ========================================================================= - Joe asks if there are any other issues? None, Joe adjourns the meeting Participants in above minutes: - Joe Salowey, Jim Schaad, Steve Hannah, Dan Harkins, Glen Zorn, Hao Zhou, Yoshi Ohba, Stefan Winter, Nancy Cam-Winget, Sean Turner, Leif Johansson