EAP Method Update (EMU) Minutes Meeting : IETF 78, Wednesday 28 July 2010 Location : MEC Maastricht, Chairs : Joseph Salowey , Alan DeKok Minutes : Nancy Cam-Winget Version 0 =========================================================== Agenda 0: 0900 - 910: Preliminaries 1: 0910 - 0925: Channel Bindings - http://tools.ietf.org/html/draft-ietf-emu-chbind 2: 0925 - 0935: Federated Identity 3: 0935 - 0940: Tunnel Requirements 4: 0940 - 0950: EAP ID Protection - Zhen Cao 5: additional topics ============================================================ 1: Sam Hartman provides update on channel binding Sam: Had offline discussion with Glen Zorn to understand his issues. Strongest disagreement seemed to be on usefulness of channel binding. Sam asked chairs to decide whether the group would take this as a work item. Sam: Also had list discussion of channel binding interaction with tunnel. - Sam now the editor for the channel binding draft - Changes to draft to: Clarify examples, problem statement No distinction between roaming and enterprise Need channel binding to address use of different NAS’es and allow for differences in how network is viewed - Sam requests comments to see if we have group consensus. Has received one review from a previous author, so need more comments. - Only 2 or 3 have read the latest version….. Joe Salowey: requests more reviews. He’s looked at document and believes its an improvement but more work is needed. Sam: claims document is a protocol, but it really is not….no way to implement from this document. Most bits for how to handle channel binding within each method should be defined in this document; though this should not be a specific EAP method document. Want to get as much details as could be done to ensure interoperability. Sam: Would like to see approach similar to Clancy-emu-aaapay Russ Housley: asks why extra roundtrips are needed….Sam defers for later discussion. Alan DeKok: do people in group need more explanation on the Clancy-emu-aaapay proposal? Stephen McCann: asks if there’s a proposal to carry something over RADIUS vs. diameter only? Sam: responds that using diameter should be back compatible with radius as well. Sam: can we input Clancy draft into channel binding? About 7 or 8 people responded “yes”. Sam: notes that commenter suggested using 1.5 roundtrips to allow server to indicate what info it needs. But doesn’t understand where it may be useful? Joe: expresses concern that there could be a lot of channel binding data required, not sure that extra roundtrips are required but we do need to address potential for large amounts of data. Sam prefers to find other solutions to address this than introducing extra roundtrips. This answer satisfies Russ’s earlier question. Sam: discusses the need for non-AAA attributes. Would like to remove complexity for how to add these attributes as Joe has also expressed concern in using diameter attributes. Joe: responds with no known use cases of using attributes that are not AAA but does express concern where there may be different ways in presenting binding data. Example is use of SSID, while there is an attribute (Alan notes that there is a call-station-ID, but not sure if there’s a diameter attribute to serve this) in Radius but there may be other attributes that convey same info. Sam responds that documenting specific guidance for say, 802.11 as a way to approach L2 (lower layer) guidance. Dan Harkins asks: thought point of channel binding was to ensure that the same info is shared between client and NAS and NAS and server. Sam agrees, but adds that also need to validate identity. Dan: asks how this can be achieved if it isn’t a AAA attribute? Sam: explains with scenario: if there wasn’t an attribute (for example) for 802.11 bit rate; further there’s a database mapping for bitrate to a NAS-ID….eap server could verify this in a way that is not through AAA since it doesn’t really care but in principle this shows existence for this need though there’s no practical scenario he can think off. Joe: responds that its not sufficient to do comparison as the NAS could be lying in both direction, there needs to be a way to validate these values. Sam: explains that there are cases (uses billing as example) where the database may not be needed. Dan: is lost where NAS’es could be lying in both direction…. Sam: requests that the draft be reviewed as that is documented. Alan: notes that the info could go to different backend consortiums (e.g. trusted in AAA sense but lying from a billing view). Dan: thought idea was to prove that there’s no NAS lying to both the client and server. There’s some agreement that the AAA server should know what the NAS should be saying. Dan believes there should be no non-AAA data passed as the use cases today are contrived; simplify with only AAA data. Joe: believes this may be a good assumption; but do need to look at L2 data that may be required and maybe add them as part of AAA data and evaluate them on a per need basis. Side conversations on how to carry info through AVP’s; Sam: concerned on this as they are not labeled properly and they could lead to security issues (or at least complicate security analysis)….so even if method has means to carry AVPs, unless that method is exclusively for channel binding, we should define an AVP exclusively for channel binding. Alan: asks if there are objections….none raised Sam: noted that this was discussed with Steve Hanna Steve Hanna: concurred that doing specific AVP would be okay. Joe: notes that good progress is being made, requests more review for the draft. 2. Discussion on federated identity Alan: notes that this is open discussion to ensure interactions between channel binding and use of federated identity is raised. Sam: noted BOF (on Federated Auth) that there is use of channel binding to ensure appropriate application is used in federated auth. Hopes group gets charted and if so, that would be another use for channel bindings; involving AAA AVPs for carrying ID of server to guarantee consistency. 3. Tunnel Requirements status update Joe: believes draft is complete, should go to RFC editor maybe this week Joe: notes there’ll be call for proposals for EMU method; initial proposals don’t need to be formal documents that would be published as RFC’s but should be ID-drafts to roll into another document (or broken into several documents). Concrete proposals should be in draft form. 4. EAP-ID protection presentation by Zhen Cao (China Mobile) - Problem: identity can be forged even at start (as server uses this to determine which EAP method to use), should consider protection to avoid downgrade attacks - Proposes solution to hash the identity using the public/private key pair and send ID as CBID||Nonce||PK||Signature where CBID is the hash of PK and optional content - Considerations are to use the Nonce to mitigate replay attacks; this requires the EAP server to keep state of the nonces to prevent replay - Asks if there’s interest to pursue this work Dan: asks what signature covers; response is that it covers the CBID and Random. Dan notes that CBID may be extraneous (not necessary). Question is whether you just need to hash the PK and Random in the signature Dan: notes that this puts a tremendous load on the client and the server. Especially on the server as it has to keep a long list of identities (the ID is now user based which can be a very long database); further more burden is imposed if the random is used to avoid replays. His suggestion is that if nonce is in the request, the NAS could filter some of the replay vs. the server. Zhen: responds that the “match” logic should be that burdensome. Alan: notes that removing the human readable outer identity, it makes it hard to forward to the appropriate domain to route to….believes that original info should still be included. Server maintains the realm for the identity (many realms). Dan: suggests replace CBID with original form (e.g. real identity) and make random be part of the ID request. Zhen: believes doing this would not mitigate the forgery…. Dan: notes that if this is done thru private key, that should be OK. Zhen: notes that that would require PKI….. Dan and Joe disagree. Joe: adds that current proposal breaks AAA routing; also not convinced that this is a big problem nor how often method is selected based on identity (e.g. method strength). Alan: notes that client could always NAK the method response too. Alan polls: how many believe that protected identities is useful? (a few)… how many believes that its not useful and nobody cares (no one)…. how many believes this is interesting and should continue discussion (a few). Joe: suggests that other mechanisms should be looked at…. Sam: asks if any IPR has been filed? Zhen: answers that there is no IPR (or not aware of any). 5. Additional topics Joe: wants to raise awareness in 802.11 looking at speeding up initial authentication; not sure what technologies are being reviewed, but there may be interactions required in the future. Hiroshi Mano: notes that the study group has started to reduce the initial authentication time; to speed up the L2 link association (like mobile cell phones). Believes that message exchange combination may be needed to shorten the time for full association (e.g. L2 and L3). Fast initial authentication (FIA) is studying technical feasibilities….need collaboration with upper layers here in the IETF. There is a document in 802.11 to review for chartering the task group in 802.11. Stephen McCann wants to add: identifies himself as 802.11/IETF liaison. Asks whether the documents should be posted to EMU or how to handle the liaison issues? Joe: states should be sufficient to send the links docs to the list to minimize process; but if the group does rely on IETF then formal liaison may be needed at that time.