IETF July 2009
EMU
Agenda bash: review of today’s agenda
Tunnel Method Requirements:
Draft -03 to address Glen Zorn comments
Review received from Bernard will need further discussion in the reflector
About 5 people present have reviewed draft -03: request to get more review and feedback soon
From current list, discussion on:
Method chaining: requirements document has a SHOULD to allow both user and device authentication. Bernard points out that this could be avoided if there is a tunnel
This is question within a tunnel
Why would this be needed? If policy (server) wants to authenticate both a user and a device. Some comes from historical requirements from WiMax (though they have current dropped this)
Chaining doesn’t necessarily mean two servers, but two sets of credentials. In TTLS, tunnel allows for machine authentication during tunnel establishment and user inside the tunnel.
Would this also assume binding between the results? Yes
One circumstance where chaining is useful: posture checking; e.g. user auth followed by posture checking. So this can be a SHOULD in the draft.
Given that his is for requirements: it would be bad to prohibit chaining, but not clear that it is a hard requirement. Requirement to not make this infeasible, but not have it as a MUST. (Agreement by last 2 commenters: Paul Hoffman and Steve Hanna). In the circumstance of standardizing a particular method, we need to make sure it meets the use cases, where NEA will have it as a requirement (e.g. MUST).
Confusion of what the MUST means: clarification is that the language would be to “MUST allow for chaining” or “MUST provide for chaining” but not necessarily enforce chaining.
Another clarification is whether meta-data is required for differentiating user vs. device auth as today, it is implied by the authentication method used.
Given this discussion, there’s enough direction in how to respond to Bernard’s review comments.
Comment from Klaas: impossible to document when chaining is a MUST. Don’t know that the requirement document is the appropriate place to state this, but the groups defining the explicit use case (e.g. NEA where in there, it states a MUST).
Simplest fix would be to remove the paragraph listing NEA as a special case and just clarify chaining as a MUST….we can continue discussion on the list.
Next comment is on internationalization: the following sentence in the draft is not needed (comment by Paul Hoffman) “Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user’s language preference.”. Language negotiation is not well specified and not one that we should specify. Steve Hanna had discussions in how negotiation could be achieved (context was within NEA) using separate language tags. Unless there’s a way to specify language negotiation, leave this well enough alone.
Pasi notes that tagging the packet with language tag information can be useful. Paul notes that should be OK, as it doesn’t require negotiation.
Paul notes language tagging will require some mapping or negotiation to decipher what the tag maps to…it is not a solved problem. Using Plane 15 UTF-8 should be sufficient (based on Pasi’s requirements to allow, say, a server to tag the error code with the language its represented in…)
Glen questions whether we’re relaying free-form text? In essence yes: error and prompts. Glen asks why we need to be bothering with this at all? Alan DeKok welcomes a full enumeration of the error codes….. Glen says eventually, we will get there. Pasi notes that there may be error codes outside the protocol specification. Glen questions if its outside the protocol, then why is it in our scope? Pasi notes that it is because it may be vendor/policy specific (Alan states as an example is to enrich it with a bit more information to lower customer calls, as it may be localized to the actual use).
Steve hanna offers suggestion: international company that wants to send back “Sorry, can login between 9 and 5pm” (e.g. administrative specified string that is localized) and thus unlikely to be sufficiently predefined to map to a specific (numeric) code. Glen doesn’t agree as he believed it could be specified to a code #.
Next review comment: data outside the tunnel will need to be protected (version #, method ID and other data needs specific to the method)
Next review comment: mandatory attributes, is this required? Standard vs. vendor specific. No comments.
Next review comment: peer identity protection
Not concerned with protection prior to tunnel establishment
No further comments.
Next review comment: need clarification on recommendation to make authentication requirements (need to better understand Bernard’s request). No comments.
Channel Binding (draft -03) to address comments by Klaas
Presentation of the scope and goal of the draft.
Discussion and enumeration of what is required to be validated and checked.
Not many people (~2 or 3) have reviewed this document, request to have more reviewers for this draft so we can progress it to last call.
Glen was going to make a comment but stated “Oh, screw it”
Glen believes channel binding should be innocuous, and not implemented. It does concern Glen that this is so unlikely to be deployed and implemented; though it could be used as a tool to make people implement this. Would like to see it go away as deems it useless; but perhaps the chairs could think about “harm reduction”.
Alan asks for where Glen has particular issues or particular areas? Glen states: roaming. Chances that a home EAP server would know anything (or check with consistency of NAS’ in other domains)….are ISPs expected to share this data (as they do not today). Joe notes that draft does discuss this, if it insufficient then it should be clarified. Glen doesn’t believe its fixable. Alan states that this is useful for billing as there’s fraud potential in roaming. Do we want to forbid this? Or allow it? Glen retorts that, except for a single corner use-case, it is useless given the amount of effort required.
Pasi notes that there’s usefulness in looking at the information. Glen notes that there may be after-the-fact forensic value, but that’s not enough rationale to allow this work to go thru.
Alper also notes that perhaps this doesn’t need to be within the scope of EAP. Alan notes that this is though doing another form of EAP authorization. Alper notes that it may be stretching EAP too far…. Glen agrees that this is not really a “method update” as it requires a “new protocol”.
Pasi speaking as AD for EMU, this is a working group item as it is part of the charter. Asks if Glen is proposing to change the charter.
Joe notes that there were also discussions of channel binding in IPSec
EAP-EKE presentation (Yaron Sheffer)
Based on Bellovin 1992 EKE (encrypted key exchange)
Patent due to expire late 2011
Presentation of EKE mechanics
Students in Tel Aviv implemented inside wpa-Supplicant and FreeRADIUS and another team adding it to StrongSwan (IKEv2)
Based on implementations result in draft -02 to add integrity protection to encrypted nonce payloads to mitigate “cut-and-paste” attacks based on nonce exploitation.
Also added another HMAC stec based on draft-krawczyk-hkdf-00
Eliminated protected failures
Summary: where do we go from here?
Comments: Dometrio(?) question on privacy: Yaron mentioned true anonymity or pseudonymity and believes pseudonymity could be addressed in the next draft.
Chair discussion: given EAP-EKE and EAP-PWD, there may be interest in zero-knowledge methods. Wants to see who would be interested in addressing this? About 6…. About 4 willing to write and edit these documents….about 7 willing to review them. About 11 believe it would be deployed. Question to AD (Pasi) given that there’s interest what to do? Pasi notes that we could add to charter but comments that current work has been slowed. Joe notes that interest may have lost interest in current work item
Pasi notes a second choice, given that there are other groups like IEEE P1363.2 that looks into this and currently there is a last call for informational on EAP-PWD.
Yaron comments that the standardization would be to standardized on password method….Paul notes that paring it down to one doesn’t really need to be, nothing in the IETF prevents there from being just one. So we need to discuss what “this work” would mean. Pasi notes that there was also eap-srp. Pasi asks for those who raised their hands to express what they would like to see done.
Glen speaks as authors of both methods, not happy with EAP-PWD going thru as informational. The sponsor AD had agreed to move it as a standard, so is upset that it is now to be informational. Pasi asks: if folks who would want to deploy it whether it would be informational vs. standard? If there’s little difference why do you care? Glen notes because he knows the difference between the two.
Dan speaks as author of EAP-PWD, there is an internet record method that it is insecure. Since internet community has decided that it should address this problem, that is should be standardized and not information. Pasi comments as the AD for EAP-GPSK, it is well known that it is not meant to be for human passwords and not to address the zero-knowledge requirements. We have also chartered how to address passwords with currently existing protocol that do not require zero knowledge.
Dan notes that he presented EAP-PWD over a year ago and was mentioned that the group would not recharter. Pasi asks whether we should drop the tunnel for zero-knowledge? Dan says “no”, is just puzzled as to why this topic is now arising.
Nancy notes that the situation has changed given that new methods have now come to light: eap- eke, -srp, -pwd and given membership change, interests have changed. Pasi now still notes that we need to have discussion on what we need to do.
Glen notes that discussion is now “kafkaesque”…. Pasi notes that there was opposition to standards but information is ok. Dan notes that comments were made but could not remember anyone objecte. Paul retorts that there were people who did say opposed. Joe notes that he objected, not just on IPR grounds.
Dan notes that EKE doesn’t allow for ECC…. Yoren states that choosing of a function
Pasi notes that we should not be discussing this now….Paul agrees especially as this has not been made an EMU WG charter.
Alan notes that discussion of cryptography is off charter for EMU, so we need to move on.
Stefan notes as users (over a million), overhead of PKI is a concern. Would like to see zero-proof to allow for more choices. Users do look at IETF state and would like to see something standardized.
Yaron comments as alternative to EMU WG addition, is that there may be two informational zero-proof RFC’s. Whether we care or not, if both exist, there need not be a standard.
Pasi comments: taking this work in EMU would require rechartering, those who are interest in doing so should write in the reflector for what they would like to see. He is worried that the interest was not that large, so even having it as a WG item would not help their progress. Alan notes that we may need to revisit the current WG, but as to the password, given the controversy it would be good to get the discussion open.
Paul asks: haven’t answered why it can not be done as individual submissions. As individual submissions, there may not be consensus in the larger forum.
Steve: there’s a lot to be said to get them published to see how they get widespread development/deployment but as informational. After a period of time, once we know their traction in industry, we can review their informational to standards status update.
EAP for SIP Media authorization (Stephen McCann)
Take something from SIP (RFC 3265), e.g. session policy channel in a limited bandwidth and make it more efficient, especially for wireless networks.
Propose to encapsulate SIP policy inside an EAP method in an EAP tunnel
Joe asks if this has been presented in the RAI area. Andrew responds that there have been informal discussions but will evolve, starting the discussion somewhere as it needs to be raised in both. Joe asks if this is a request-response exchange? Andrew responds that it is basically yes. Joe asks if the information is to be achieved asynchronous? Stephen responds that on first session it would be synchronous, but from a general standpoint, it is asynchronous.
Steve what is in the red circles? PA is the policy server and could be co-located with AAA server as in practice it would be.
Steve Hanna is noting that it is similar to NEA that at the client there is some other agent that is following the contextual information to gain a SIP based authorization. How does the handset know what videos or audio it is authorized when it is turned on?
Stephen McCann/Andrew responds that this is part of the session setup.
Steve Hanna asks that there has to be network session established.
Joe: comments that EAP happens at network access and then other process takes over, so is not seeing where the optimization is happening. Andrew is stating that here you are authenticating for the purposes of SIP policy negotiation.
WAPI over EAP (Richard)
Intro to WAPI presentation
Independent of AAA architecture, supports mutual authentication using certificates
AP and STA send their certs to the authentication server for authentication
Presentation of certificate validation, unicast key negotiation and multicast key
Proposal to reuse the AAA architecture and carry EAP between the AP and the authentication server
Dan asks, communication between AP and Server, this isn’t really an authentication protocol. It is EAP tunneling a version of OCSP and perhaps not a proper authentication method to get certificate status. Richard asks for clarification. Joe notes that typically EAP acts between a supplicant and server, between the AP and AAA server, you normally use RADIUS. Here you are suggesting EAP between these parts.
Pasi agrees that this is more appropriate to be RADIUS attributes
Richard notes that it was initially desired to bring it in as RADIUS but he notes that WAI is not pass through.
Sam notes that in this proposal is that there is not a RADIUS client and suggests that EAP-TLS could be used. Is puzzled why we are discussing WAPI if it doesn’t help what we are trying to do.
Richard notes AAA is widely used. Can not define RADIUS attributes as it would still need another channel, otherwise could be used EAP.
Dan notes that this protocol does not do authentication, since server doesn’t do authentication, it can make up authorization but can’t really do any accounting. So, it is not really suitable. This protocol could be replaced by OCSP, as the AP already validates the certificate, and authenticates the user.
Pasi notes that the AAA could do the authentication; but retorts from Dan and Nancy note that, that is not currently done by WAI, the parameter negotiation for authentication is only done by the station and the AP and the server only does certificate validation.
Joe closes by stating group recommends that this work be done as RADIUS attributes, and recommending that the author send this item to RADEXT.