EMU IETF-71 - Philadelphia Thursday, March 13, 2008 0900-1130 ---------------------------- Chair: Joe Salowey Note Takers: Charles Clancy, Dorothy Stanley ---------------------------- Document Status (Joe Salowey) ----------------------------- + RFC2716bis (EAP-TLS) is in Auth 48 + EAP-GPSK is in AD-review, new revision is needed Charter Update ----------------------------- + General Text Joe: Text Should be updated to reflect current status of method publication. Propose to accept and revise. When the original charter was written, there weren’t many published EAP methods. Now there are. Need to update the text. Joe: does anyone object to modifying the text to reflect current status? Gorup: No objection + Tunnel Method Joe: became a potential work item due to desire to support legacy databases. Needs to work when clear text password or a derivation thereof is not available on the server side. Could look at other password methods separately. Sam Hartman: if had a proof of concept, could do legacy methods without a password. Design team method used a TLS handshake, didn’t support tunneling an arbitrary method. If going to use “tunneled” in that manner, need to clarify this in the charter. Need terminology that means “tunnel other EAP methods” so that we are clear. Joe: Bernard had raised question on the list regarding need to avoid fruitless arguments. Acceptable outcome to update one or more existing methods if they meet the requirements. Bernard Aboba: Don’t have to pick just one. If group can’t come to consensus to one method, what do you do? Work on none? On more than one? Seems more reasonable to work on more than one, where there is interest. Steve Hanna: Better to agree on one than on “n”. Reluctant to have charter assume we can’t agree on one. Have charter be silent on the number. Having 2 or 3 is not a desirable outcome. Joe: First thing to do is to come up with requirements on the tunnel method to support passwords, channel bindings and multiple EAP method. After we have the requirements, then move forward to look at number of methods to meet. Concern, have not had a lot of volunteers to contribute text for requirements. Steve Hanna: volunteers to contribute text for requirements. Joe: Thank you. For charter revision for a tunnel method, proposal is to not state the number of methods. Work through requirements, and then work on meeting those requirements. Legacy password, legacy EAP methods and channel bindings. Steve: Don’t object, discuss the question – what happens if two methods come forward? Bernard: Merger is the worst possible option. Likely to be a garbage outcome, worst of both. Tim Polk – As an AD – don’t like to see groups provide multiple competing protocols. Hope that “n” is a really small number. Don’t have the charter bind you in a corner. But multiple solutions not viable either. See what the candidates are, and their strengths. Sam: Agree, words of wisdom. Joe: Take this to the list, good direction Hao Zhou: Can you show the current proposed charter revision? See current text? Dan Harkins: Obliquely talking about N methods, really only 2. Prefer a cage match. Merger would be bad. Glen: Tend to agree with Dan. This would take care of the editor and contributors needed. Pasi Eronen (as AD): Share Glen's concern. If you're willing to work on this, say so. Dan: massive deployed base for each method. We won’t be changing the methods. Vendors won’t want to change deployed base. Steve: We have identified requirements that neither of the current methods meet. There will be some minor changes or revisions to the current method. Steve Hanna again volunteers to work on requirements. Hao: Crypto agility, channel binding, internationalization all necessary, so we need a requirements document. Willing to contribute. Joe: Requirements document is a good thing to do. Pasi: Have requirements that alternatives don't meet. Supports documenting requirements. Don't spend too much time on it. Short and done quickly. Glen: Not sure a full requirements document is not a waste of time. Put as a section of the protocol document itself. We've already identified the requirements. Pasi: Don't need to publish document as an RFC as long as it completes a WGLC. Tim: In PKIX set back 1-2 years by developing a requirements document. What is important is to document the requirements – need agreement, when there are multiple candidates, or won’t move forward. Hao: Agrees. Glen: This changes the tunnel method item on the power-point. Don’t need editors and contributor. Joe can send a list of requirements to the list. Get comments reviewers on the list. Finish in 2-3 weeks. Then those in un-named companies can busily work on modifying their proposals. The have knife fight to determine solution. Hao: Do we really want a knife fight? Have a deployed base, some don’t want to upgrade. Tim: Initial goal is to make a decision and pick one, but that doesn't always happen. Gene Chang: Interested in consensus and requirements document. Joe: Light-weight requirements, sent to list for review, goal is to select a single protocol. + Secure Password Only Method Joe:Secure password only method. Access to clear-text or some consistent form of password available. No other credentials necessary. Ask for presentation from Dan Harkins on motivation for the method. This is another set of requirements. (Dan Harkins Presents on draft-harkins-emu-eap-pwd-01.txt.) Sam: Does not work with legacy password databases, and is therefore out of scope for the charter. Everyone is probably interested in it if it's IPR-free. Bernard: IPR concerns are about to expire in the next few years. Dan: 2010 is the EKE patent, but doesn't think it applies. SPEKE and Certicom patents are of concern. Belief is that if you use ECC with prime field you can avoid IPR. Minefield but *possibly* navagable. Pasi: Believe not in current charter, can be added in the charter revision, subject to usual conditions – volunteers to contribute, edit, review. Dan: WRT charter – current charter doesn’t mention tunneled method. Pasi: Legacy password methods don’t work with this method. Dan: This consensus was confirmed on the list in the fall. Not something that is new. Glen: The thing about the fall – that was the previous charter. Joe: Work on password method for legacy data bases, agreed on modifying the charter to add a tunneled method. Look at adding a new separate item to the charter. Dan: This method is useful and not yet another password based method. It doesn’t require use of certificates. Pasi: Show of hands? Tim: (Jumps the queue) This is the IPR space that killed other working groups. Worried that this is a heavily encumbered space. Other groups have failed at this point. If mentioned in the SPEKE patent, nervous. Happy to see work continue on the draft. Prefer not to add to the charter at this point. But I’m not your AD. Mines are close together here. David McGrew: "Authentication with short authentication strings" are similar class of protocols, but avoid IPR claims. Steve: metaphor of a minefield is a good one. There may be submarine patents here too. Just looking at published claims not enough. Support moving forward, will fully support if not encumbered. Sam: If not standards track, shouldn’t be in the charter. If informational, then don’t need to spend our time on. Two issues need more info on – security analysis, is this method secure. Second – IPR. Talk to Phoenix, will they say this is not covered? Implementers to look at this, and they don’t believe that patent licenses – commercial implementers, rather than open source. If either of these happened, then would feel comfortable with. Dan: On the security front – sent to some reviewers, “looks good”, need a formal proof. Will still work on this. Charles: Prof Katz's work from UMD. Sam: If EKE patent is expiring, we should start looking at an EAP method that does EKE now. This might be a good approach. Glen: Since EKE is ready to expire, why bother with this? Sam: Because this approach is better, if it is secure. Bernard: Suggest taking this to the SAAG, since it doesn’t affect just us. Dan: Deterministic process would be good. Could be submarine patent, security proof difficult. Wants an outline of steps to reach goal. Joe: IPR steps are fairly well laid out. Security review needs a broad set of eyes. Pasi (as AD): This is a new topic -- tackle other work items first before taking on new work. Tim: This is a standards process, not a deterministic one. If WG is evolving, there is no reason to not revise the charter as long as progress in being made in the group. There is a lot of interest in this type of method, need to build consensus that IPR space is sufficiently unencumbered. Or maybe WG will decide that even if it is IPR encumbered, that it is so compelling that it should go forward. Dan: Doing charter revision now, so add it now. Yaron Sheffer – Believe there is significant value in this work. Do an IPR anaysis on paper rather than relying on open source developers to prove that it is unencumbered. Pasi: Individuals may have opinions on IPR, but not working groups. Dan: Will initiate a process on IPR; lawyers get involved because people disagree. Yoshihiro Obha: Start from experimental, and then consider standards track. Pasi: Wouldn't expect IESG to actively block it as long as there is a reasonable security evaluation. + Channel Bindings (Presentation by Katrin Hoeper) Clint Chaplin (Clint): Thanks for working on this, and encourage this work to continue. No good definition to date. Sam(individual): Have a reference to 5056, that uses the “channel binding” term in a different way. Bind different layers of a session; prevent a man-in-the-middle attack. Include this in the document that you are writing. Bernard: Echo Clint’s comments. Note that in an implementation, there are impacts to the drivers to pass up specific data – from driver to the method. Joe: What are the important parameters – need to define. Dan: Agree that this work should go forward. Concern with viral nature of EAP, and EAP being used to solve every problem. Authentication requires identifying the entity that is being authenticated. Pasi(AD): draft aarko-eap-service-identity-auth defines “channel binding” but with a different name. Katrin: First need to agree that this is a working group item. Joe: Is there interest in working on a channel binding draft? Then, provide specific recommendations. May be one or 2 drafts. Joe: Should the group take on this work (raise hands?) Hands raised – yes. Joe: Asked for text contributors – 3-4 people. (Charles, Katrin, Bernard) Joe: Asked for reviewers – many hands. Tunnel Method Requirements ----------------------------- Joe: Next discussion item, tunnel method requirements. Steve and Hao have volunteered to be contributors. This is a little light. Joe: How many people are willing to review? About 5 hands are raised. Joe: How many people have reviewed a draft list of requirements? 3 people. Hao: May be useful to separate the generic EAP requirements from the tunnel method requirements. Steve: Good start on the list. Need to contribute a description of each list item. Joe: To move forward, get contributors together in the next week to prepare a canonical list to publish to the list. Joe: Any other comments on requirements? None Channel Binding Drafts --------------------------- (Charles Clancy presents) Charles: See slides. Two phases, Information exchange and consistency check. Bernard: More than a consistency check. Peer has to verify correctness. Glen: What is the info that is being sent? Charles: Depends on the type of the network. 802.11 – SSID, contractual billing information Glen: What are the endpoints of the channel? Charles: Trying to bind the info from the authenticator to the channel. Glen: In service provider network? Charles: Related to the billing agreement. Glen: Not related to the authenticator. CHarles: Home auth server can validate the rates from the roaming partner. Glen The data from the authenticator isn’t being bound in this case. Charles: Binding info from the network, not the authenticator. Glen: Info about the network to which you are connecting. Previous understanding was that what was bound was related to a single authenticator. Charles: Isn’t relevant in this case. Joe: Look at this as authorization in addition to authentication. Glen: The peer in a roaming situation is connected to a roaming partner. What does this do for me in addition? If only one roaming partner – then it’s real or not, then get key from authenticator. Charles: Roaming partner is advertizing as a home network. You will be charged roaming rates rather than home rates. Glen: Sounds like something you fix with lawyers rather than a protocol. Charles: Allows detection of these contract breaches. Glen: Send back – all ok Charles: Happening in the connection to the home server, roaming network can’t spoof this. Hao: Which EAP methods? How do you know what information to send? Charles: Solution in document works for GPSK, PSK, PAX, TTLS, FAST Charles: Client sends as much info as it has, server sorts out what it needs. Katrin: In response to Glen’s comments – prove that it is important to have a definition of channel bindings. Glen: This redefines channel bindings as I understand it. This doesn’t solve the lying NAS problem. Charles: Solve lying NAS for enterprise, but not for service provider roaming Trying to solve practical problems. Commenter: Is useful to have definition of channel binding. What is driving us to work on channel binding – are there requirements from the real world other than our own comments on each others’ documents. Pasi: Have seen comments asking for binding to determine the type of lower layer network being used by a network. Yoshi: If don’t know the layer network, then can’t solve the channel binding problem. Charles: There is a computational problem in the roaming environment, can’t know all the lower info at the authentication server. Send all info we have. Commenter: That aspect is consistent with GPSK – include a container for a set of information element. Charles: Need to standardize to use with arbitrary peer and server. Commenter: IKEv2 tried to talk to everyone. But in EAP, need to indicate the required fields. Joe: Want to reference fields that are understandable. Commenter: Won’t know all the MAC addresses. Joe: Need an extensible framework. Charles: We are defining an extensible framework that items can be added to. Commenter: Need to understand why the GPSK solution isn’t sufficient. Bernard: There is a threat model issue here. May have a lying service provider. No way to detect that service provider and local one are both lying. Sam: Have more comments, get through rest of slides first. Charles: Reviews design choices (see slide) Easy add-on to existing methods. Hao: Don’t agree that no modification is needed, adding more messages. Charles: Method itself is extensible. Hao: Limiting applicable to only methods that are extensible. Charles: Agree Hao: Could also run in a tunnel. Charles: Binding Information slide – exact parameters to bind are open to discussion. Charles: Trust model slide description. Charles: EAP Method Requirements slide description. Hao: Why do you need info1 and info2? Charles: Took assumption that there are cases when the AS would provide more info to the peer than the peer sent to it. If we find out that it isn’t needed, can be deleted. Hao: Then not doing channel binding, it is a different problem. Need to call it something else. Charles: Future work slide description. Glen: I think I understand now. Can you enumerate the EAP methods that this works with? Charles: EAP method must carry integrity protected blobs. Glen: Not a tunneled method. Charles: Correct. Can include in GPSK for example. Dan: Trust model assumes that the peer is honest. All of info that is bound is up to the peer. Make sure that identities are consistent. Charles: If every layer runs a method that supports bindings. Haven’t though about how you validate every level. Sam: One part of the trust model, what are the implications of the peer being untrustworthy. View most peers as untrustworthy. Make this explicit in the document. What are the implications of a peer that falsifies info to the server. Charles: Thinking of a DOS attack to shut down the NAS. Katrin: That is not the EAP-FAST model –a ssume that the peer is trustworthy. Channel binding solves only one problem, not the lying peer. Charles: Need to address this in security considerations section. Sam: Assuming an honest peer isn’t realistic. Charles: Summary – this is an -00 document, solicit input on the direction to take. Joe: That is it for the agenda. Has everyone signed the blue sheets? Joe: The session is adjourned (11:25am).