RE: [Emu] Re: Thoughts on Password-based EAP Methods
Bernard, By that is probably the place to start, I am assuming you mean insert all EMU changes into an EAP-TTLSv1. What happens with the existing EAP-TTLSv1? Are the authors okay with us taking over and calling something different than theirs EAP-TTLSv1? If yes, then I am for it. Not sure how we can get away with crypto-binding IPR if it is a blanker IPR, I have not read the patent myself. R, Madjid -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Saturday, April 14, 2007 12:54 PM To: [EMAIL PROTECTED]; emu@ietf.org Subject: RE: [Emu] Re: Thoughts on Password-based EAP Methods The emu working agreed on the fact that a secure channel is needed Item1. - a) Is there a consensus for TTLS (what version ?) - b) Is this possible to push TTLS as an RFC (from an IT point of view) Item2 -c) Do we need a new password based method ? I agree with Bernard point of view. Many methods already exist. My personal feeling is a=yes, b=yes, c=no I agree with this. With respect to a) there is realy only one deployed version of EAP-TTLS, namely EAP-TTLSv0. EAP-TTLSv1 has not been implemented. So that is probably the place to start. With respect to b), a fothcoming version of the EAP-TTLSv0 specification will be submitted for publication as an RFC. This will address questions from implementers and address the need for a stable reference from WiMAX Forum, OMA, TNC and other organizations that are incorporating EAP-TTLSv0 into their standards. With respect to c), one needs to take several factors into account, such as the certification/testing situation, availability of reference implementations and IPR declarations. EAP-TTLSv0 is currently being tested for interoperability by WFA so that a certification program is already in place. As far as I could tell, there is only one IPR declaration relating to EAP-TTLS, and that relates to EAP-TTLSv1, rather than EAP-TTLSv0: https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=594 Compare this with the IPR Declarations relating to EAP FAST: http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-cam-winget-eap-fast-provisionin g-03.txt http://www.ietf.org/ietf/IPR/cisco-ipr-draft-salowey-tls-ticket.txt https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=595 http://www1.ietf.org/ietf/IPR/microsoft-ipr-draft-cam-winget-eap-fast.txt ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Re: Thoughts on Password-based EAP Methods
Hi Steve, Sorry for jumping late. Internally within the design team and not having followed this thread, I suggested that we could follow the TTLS path in a way that it meets our requirements. The fact that Paul has agreed to give up control of the draft to IETF is really good news, however, I am a bit confused as how the process you suggested will happen, so let me understand this: We publish the current TTLSv0 as an RFC, and we also publish TTLSvX based on the changes EMU does as a separate RFC in a way that it does not deprecate the first one? (sort of like IKEv1 and IKEv2 scenario?) As good as that sounds to me, the not so rhetorical question would be: wouldn't the two versions still get two different method types? BTW, I am hearing that Paul has promised to add EMSK generation to TTLSv0, so may be TTLSv0 is not quite there yet:)? R, Madjid -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 3:00 PM To: [EMAIL PROTECTED] Subject: [Emu] Re: Thoughts on Password-based EAP Methods Sorry it took me a few days to respond to this thread. I agree with Bernard that there's no benefit in creating Yet Another Password-Based EAP Method (YAPBEM). There's no point in reinventing the wheel for a fourth time and it's not the IETF way. We're not researchers. We're practical engineers who respect running code and rough consensus. So, yes, we should have a bias toward existing, well-tested and well-understood protocols. In a security group, it's especially important to avoid the temptation to reinvent the wheel. We should focus our efforts on one secure tunneled EAP method and make that one secure. We should consider existing methods and only invent something new if we need to. I have spoken to Paul Funk, the primary author of the EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested: 1. Publish an updated EAP-TTLSv0 spec that documents current practice (as Informational or Experimental) 2. Give up change control to the IETF so that the EMU WG can make any necessary changes or additions to EAP-TTLS I'm also glad to assist with this effort, since Paul is pretty busy these days. Thanks, Steve -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 8:07 AM To: [EMAIL PROTECTED] Subject: [Emu] Thoughts on Password-based EAP Methods After listening to the IETF 68 presentation on a password-based EAP method, I would like to voice some concerns. Today we already have an over abundance of such methods. These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions with customers, I invariably hear complaints about this explosion, and about various interoperability and compatibility problems that it causes. Simply put, customers do not want yet another password-based EAP method; they want a single method that is widely implemented and interoperable. I am concerned that by defining yet another password-based authentication mechanism, EMU WG will be making this problem worse, not better. Creating yet another mechanism which differs little from the existing ones also seems to have very little chance of being implemented. There is a better alternative that EMU WG should consider. This is to choose an existing method for inclusion on the IETF Standards Track, rather than creating a new one. In order to maintain backward compatibility, this would require that the owners give up change control to the IETF. I would suggest that the best candidate for this would be EAP-TTLSv0, since it is very widely implemented, and has an existing certification program in WFA. Also, EAP-TTLSv0 had previously been on the Standards Track in the PPPEXT WG, before work on EAP methods was removed from the PPPEXT WG charter and the EAP WG was formed. In terms of steps to be taken, this would require the following actions: a. Review and publication of the existing EAP-TTLSv0 specification as an RFC. The goal here would be to document EAP-TTLSv0 as it exists today. b. Agreement by the authors to give up change control to the IETF. c. EMU WG efforts to publish an EAP-TTLSv0 bis document, specifying additional capabilities (such as Channel Bindings). ___ Emu mailing list Emu at ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/emu
[Emu] Q C on 2716bis-08
Hi Bernard, others, I have a few comments/ questions on 08 of the 2716bis. I apologize if this has been discussed before. Section 2.1.3 If the EAP server authenticates unsuccessfully, the peer MAY send an EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert message identifying the reason for the failed authentication. The peer MAY send a TLS alert message rather than immediately terminating the conversation so as to allow the EAP server to log the cause of the error for examination by the system administrator. To ensure that the EAP Server receives the TLS alert message, the peer MUST wait for the EAP-Server to reply before terminating the conversation. The EAP Server MUST reply with an EAP-Failure packet since server authentication failure is a terminal condition. What sort of benefit does this provide. If a server fails to authenticate due to a security reason, then its EAP failure would not matter, since it cannot be trusted anyway. If the authentication fails because of channel errors, we are not giving the server another chance to authenticate, since it must send failure, so no benefit here either. Is this to allow the server to shut down the EAP state machine successfully? Section 2.1.4 An EAP-TLS peer supporting privacy MUST provide a certificate list containing at least one entry in response to the subsequent certificate_request sent by the server. If the EAP-TLS server supporting privacy does not receive a client certificate in response to the subsequent certificate_request, then it MUST abort the session. How would the peer and the server know this is a subsequent certificate request and not the initial certificate request? is there anything in the protocol to indicate this, not sure how? Or you simply rely on the state for TLS tunnel. Nit on key hierarchy text: TMS only mentioned in the figure 1, but nowhere in the text. Finally, this might be a dumb TLS question: Seems that if the TLS session is being resumed, it seems that only a sessionID is being presented by the client, no server certs, no key exchange records. Is possession of anything (except of sessionID) being proven? Anything is signed? Or the client and server just start using the established TLS master key (TMS)? Thanks, Madjid ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Q C on 2716bis-08
Hi Bernard, Thanks for the quick reply. I am ok on the first and third questions, thanks. However, what I meant by my second question was how do we know from a protocol stand point that this is not the first but a subsequent request? Are we relying on the server state (a tunnel is established now)? Madjid -Original Message- From: Bernard Aboba [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 6:35 AM To: [EMAIL PROTECTED]; emu@ietf.org Subject: RE: [Emu] Q C on 2716bis-08 What sort of benefit does this provide. If a server fails to authenticate due to a security reason, then its EAP failure would not matter, since it cannot be trusted anyway. This is an optional mechanism for enabling the server to log the reason for the error. This might allow an administrator to diagnose and correct the problem. How would the peer and the server know this is a subsequent certificate request and not the initial certificate request? Because the peer did not provide a certificate in response to the first request -- that is how privacy is provided. Is possession of anything (except of sessionID) being proven? Anything is signed? Authentication is provided in the Finished message. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] Looking for WG input: Password based method requirements
Hi folks, The design team working on password based authentication has arrived at the set of requirements to be met by the following design and is looking for input from the WG on these requirements, especially on the second subset below. MUST requirements (design team has agreed on the MUSTness :-) = 1-Support transport of encrypted password to Support legacy user Data/password databases, 2-Provide server authentication 3-Provide resistance to offline dictionary attacks, man in the middle attacks, and replay attacks. 4--RFC 3748, RFC 4017 compliant, compliant with EAP-Keying draft (includes MSK and EMSK generation) 5--active User identity confidentiality for the peer 6-crypto-agility/ cipher suite negotiation (need to define mandatory supported ciphers) 7-Session Resumption (avoid need for new passwords when resuming) 8-Fragmentation and reassembly Requirements we are looking to WG for input, i.e. should we include the following requirements as MUST/SHOULD === 1-support password/pin change 2. Support other password based protocols (CHAP, MSCHAP, etc) 3. Cryptographic binding of password exchange to tunnel 4. Defined Extension Mechanism 5-Support transport of channel binding data FYI: the team is narrowing down its options towards use of TLS based encryption for the tunnel carrying pass-word exchanges. Comments/ input are welcome, Thanks and Regards, Madjid Nakhjiri On behalf of the password based authentication design team. ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Hokeyp] [Emu] Re: MSK but no EMSK
Hi Yoshi, Sorry for the very late response. I think the issue was whether methods generate EMSK or not, there was not a discussion of usage. Now, some method do generate EMSK and some don't. The same way that some EAP method did one-way authentication and some did mutual authentication. It is the job of the security engineer to pick the right EAP method, more clearly, if he/she needs EMSK and the method does not give it, he/she picks something else, there is no rocket science here. R, Madjid -Original Message- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Sunday, November 19, 2006 5:36 AM To: Madjid Nakhjiri Cc: 'Yoshihiro Ohba'; 'Blumenthal, Uri'; [EMAIL PROTECTED]; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Hi Madjid, The problem we are facing with EMSK is that the key and its usage were not defined *at one time. For this reason, I don't agree with mandating the use of EMSK for all implementations. Only making use of EMSK optional makes sense to me, regardless of how it is going to be used. Yoshihiro Ohba On Tue, Nov 21, 2006 at 08:50:46AM -0800, Madjid Nakhjiri wrote: Hi Yoshi, I don't quite agree with this. Defining the full functionality of a new EAP method (including how it spits out MSK and EMSK) should be the job the EAP method designer. 3748, EAP keying framework and hokey specs then define how MSK or EMSK is used. This is modular design. People who use EMSK then do not have to worry about the crypto behind EMSK generation. Using your analogy is go buy the key and lock but then wait to see which door you want to install it on:) I as a home owner do not need to know how to make locks. R, Madjid -Original Message- From: Yoshihiro Ohba [mailto:[EMAIL PROTECTED] Sent: Friday, November 17, 2006 11:36 AM To: Blumenthal, Uri Cc: [EMAIL PROTECTED]; emu@ietf.org Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK Hi Uri, I have a different view. Mandating generation of EMSK without having defined its usage *when it was introduced* seems not much different from not having defining it at all. It looks like selling a key without a lock, make the lock later and say You MUST use this key and lock for your car. Make sense?? Yoshihiro Ohba On Fri, Nov 17, 2006 at 09:22:04AM -0500, Blumenthal, Uri wrote: The discussion focuses on the problem EMSK is optional or mandatory. I don't think this is a problem - GENERATION of EMSK is compulsoty as spelled out in RFC 3578. The problem is non-compliance. Some, er, people seem to think the standard says do A, but since I don't use A at the moment - I won't bother. RFC3578 defined EMSK is mandatory, And that should be the end of discussion. but it is not used at all. First - do you know all the applications that use key-generating EAP methods? But really - who cares? If EMSK must be used, it is mandatory. if no, I think, it may be better that it is optional. VERY strongly disagree. Mandatory is what is explicitly specified as mandatory, period. Otherwise many would implement just those pieces and features of the standard that his particular product needs today. (I'm proud of my restraint - not even once using a term B*S* :-) ___ Hokeyp mailing list [EMAIL PROTECTED] http://www.opendiameter.org/mailman/listinfo/hokeyp ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] RE: [Hokeyp] USRK issue
Hi Yoshi, I cced EMU since I thought we could use some of the expertise there. Yes, this absolutely has to do the key derivation portion of application keying. We just thought the term application is confusing and used usage specific instead. Please note that the full scope of application keying is a lot wider than just deriving the USRKs. No child key derivation, key distribution or authorization issues are being discussed. We may however need to create a handover USRK if we go based on EMSK for hokey. So at least we got a small part of application keying idea approved in the charter and that is not a bad thing IMO. Now, any time you have a key hierarchy where the lifetimes are completely dependent on the top level key lifetimes, you need to re-key the whole tree. I don't know how that is different for Kerberos, say you are doing a Kerberos-EAP combo method, where your key wrapping mechanism uses a key that itself is based on an EMSK that is refreshed, then you are back to square one. You have to rekey your key wrapping key too. I don't agree with the fact that rekeying one USRK would require rekeying other USRK, there supposed to be a crypto-separation between the USRKs and from USRK up to EMSK. So as long as you can access the EMSK you can rekey an individual USRK if you want. Now as far as the need for rekeying USRK based on rekeying EMSK, the more philosophic question is this: say I have a usage (take Mobile IP) that needs a MIP-USRK, from which a bunch of other MIP related keys are derived (say Mobile node-home agent key, MN_HA_key). The AAA needs to authorize MIP before the MIP-USRK is generated, but EMSK is not exported to the AAA layer, which means, the AAA server/layer needs to request the EAP/ method layer/EMSK-key holder to generate the MIP-USRK for it. At this point and beyond, it should be up to the AAA server to decide how long the user is authorized to do MIP and then decide the life time for MIP-USRK or the children keys (MN_HA_KEY). Why would the AAA have to tie the MIP-USRK or MN_HA_KEY to the EMSK anymore? Why should MIP authorization and security be tied to the initial EAP access authentication? If you agree with this, then EMSK rekeying would not automatically require USRK rekeying for every USRK? If not, then yes, there is a problem. Madjid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yoshihiro Ohba Sent: Wednesday, November 22, 2006 5:46 PM To: [EMAIL PROTECTED] Subject: [Hokeyp] USRK issue (I tried to reply the following thread but somehow my reply did not appear to the list: http://www.opendiameter.org/pipermail/hokeyp/2006-November/000356.html, so let me post with a new thread.) I have a fundamental issue with deriving multiple root keys used for different purposes as a form of key hierarchy. There are two reasons. When re-keying of EMSK happens, it would require all USRKs derived from EMSK to be re-keyed, regardless of the purposes the USRKs are used for. Second, it is difficult to re-key only a specific USRK without re-keying other USRKs as well. If we consider use of EAP for multiple different types of applications, this issue seems critical to me. I would suggest further investigating this fundamental issue before WG adoption of draft-salowey-eap-emsk-deriv-01. My sense is that a Kerberos-like approach (i.e., use of tickets that carries encrypted key and associated attributes including lifetime and key scope/usage) is much better than key derivation approach such as described in draft-salowey-eap-emsk-deriv-01, from key management perspective even if we consider the complexity aspect of a Kerberos-like approach. I would like to also point out that USRK is related to so called application keying in HOAKEY BOF in March 2006, and application keying was ruled out from the BOF discussion. Regards, Yoshihiro Ohba ___ Hokeyp mailing list [EMAIL PROTECTED] http://www.opendiameter.org/mailman/listinfo/hokeyp ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
[Emu] RE: [Hokeyp] CAPWAP and HOKEY interim meetings
Hi Charles, Not sure why EMU is cced:) So I cc CAPWAP. I appreciate the sense of urgency. Given that some of hokey deadlines are in January, it was a bit unfortunate that we did not get to discuss hokey future steps, but can we please specify what we want to achieve in this meeting and possibly even more important define specific action items to be completed before we start the meeting, since some of hokey deadlines are actually right around the time of this meeting and the meeting itself might hinder us from meeting the deadlines (I think I used as many double meaning as I could:)) The hokey community has generated problem statements that have gone multiple revisions and presented many times. I hope we don't want to go through those presentations AGAIN. I personally think a quick rewrite/merging of the existing documents will help us meet some of the deadlines we are facing without the travel. I personally have travel restrictions and would rather not do this trip and we need to think about the effect of people not being able to show up given that this meeting is an interim outside IETF schedule and whether we can do conference calling instead. That said, if we are still planning to meet, and if there is a discussion in CAPWAP that relates to hokey, then I suggest that such CAPWAP session is as close in time to the hokey day, so we can minimize travel needs. If the first is true and there is a need to coordination, I would suggest to have the CAPWAP-hokey meeting on a half day next to hokey meeting day next to day, e.g. if hokey is on Thursday, the CAPWAP-hokey meeting would be on Wednesday afternoon. Regards, Madjid -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Clancy Sent: Friday, November 17, 2006 10:01 AM To: [EMAIL PROTECTED]; emu@ietf.org Subject: [Hokeyp] CAPWAP and HOKEY interim meetings CAPWAP and HOKEY WGs, The chairs of both CAPWAP and HOKEY feel an interim meeting between IETF 67 and 68 is necessary in order to meet their respective milestones. Due to a likely overlap in some participants, consecutive, co-located meetings are suggested. The chairs propose to hold a 3-day event (1 day for HOKEY followed by 2 days for CAPWAP) in the San Francisco Bay area the week of January 22. Due to a preference of not traveling on weekends, meeting Tue-Thu (Jan 23-25) is suggested. Please send comments to the lists on the proposed schedule, area, preference on dates, and which meeting(s) you're likely to attend. Also please indicate any possible overlooked conflicts with conferences and other events. If your organization would be interested in providing a venue to host the event, please let us know. In particular, we are interested in your site's space availability, accessibility to visitors, guest Internet connectivity, ability to provide lunch, and proximity to a major airport and reasonably-priced hotels. Thanks! -- t. charles clancy, ph.d.[EMAIL PROTECTED]www.cs.umd.edu/~clancy ___ Hokeyp mailing list [EMAIL PROTECTED] http://www.opendiameter.org/mailman/listinfo/hokeyp ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
