Re: [Emu] server unauthenticated provisioning mode
On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote: On 8/26/2011 4:22 AM, Dan Harkins wrote: 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. I completely missed that. Sorry. But if the IETF standardized a wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a shared key) Please check your sources refrain from spouting nonsense; if EAP-pwd is really so wonderful you shouldn't need to disparage other work, it should stand on its own merit. I stand corrected. That must be why draft-zorn-emu-team proposed using MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. then I really don't understand your opposition to EAP-pwd. MSCHAPv2 became widespread solely due to Windows. Hardly. The fact that the IETF was busy a) insisting that there was no, and never would be, any need for dynamic key generation (let alone mutual authentication) in network access protocols (specifically PPP; how could there be, since the only appropriate usage of PPP was to connect two routers which can easily be configured with telnet) and b) waiting with baited breath for the magical genesis of the universal PKI (which would happen because IPsec required it that hamstrung niche protocol was so wonderful that the world would change to satisfy its requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded because it satisfied a need that the IETF was simultaneously too ignorant and arrogant to see. That's great Glen. You accuse me of disparaging other work and then you go and disparage other work. Do as I say and not as I do. OK, I promise. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
On 8/26/2011 1:13 PM, Dan Harkins wrote: On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote: On 8/26/2011 4:22 AM, Dan Harkins wrote: 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. I completely missed that. Sorry. But if the IETF standardized a wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a shared key) Please check your sources refrain from spouting nonsense; if EAP-pwd is really so wonderful you shouldn't need to disparage other work, it should stand on its own merit. I stand corrected. That must be why draft-zorn-emu-team proposed using MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. this has a relation to your misrepresentation how? then I really don't understand your opposition to EAP-pwd. MSCHAPv2 became widespread solely due to Windows. Hardly. The fact that the IETF was busy a) insisting that there was no, and never would be, any need for dynamic key generation (let alone mutual authentication) in network access protocols (specifically PPP; how could there be, since the only appropriate usage of PPP was to connect two routers which can easily be configured with telnet) and b) waiting with baited breath for the magical genesis of the universal PKI (which would happen because IPsec required it that hamstrung niche protocol was so wonderful that the world would change to satisfy its requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded because it satisfied a need that the IETF was simultaneously too ignorant and arrogant to see. That's great Glen. You accuse me of disparaging other work and then you go and disparage other work. Do as I say and not as I do. OK, I promise. Actually, Dan, I disparaged the _lack_ of work (in PPP) and the unrealistic expectations of the leaders (in IPsec). IPsec need not have been hamstrung by an unrealistic dependency upon PKI and needn't have been turned into a niche protocol either. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
On 8/26/2011 1:27 PM, Glen Zorn wrote: ... Hardly. The fact that the IETF was busy a) insisting that there was no, and never would be, any need for dynamic key generation (let alone mutual authentication) in network access protocols (specifically PPP; how could there be, since the only appropriate usage of PPP was to connect two routers which can easily be configured with telnet) and b) waiting with baited breath for the magical genesis of the universal PKI (which would happen because IPsec required it that hamstrung niche protocol was so wonderful that the world would change to satisfy its requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded because it satisfied a need that the IETF was simultaneously too ignorant and arrogant to see. That's great Glen. You accuse me of disparaging other work and then you go and disparage other work. Do as I say and not as I do. OK, I promise. Actually, Dan, I disparaged the _lack_ of work (in PPP) and the unrealistic expectations of the leaders (in IPsec). IPsec need not have been hamstrung by an unrealistic dependency upon PKI and needn't have been turned into a niche protocol either. in any case, you can disparage other work (esp. MS-CHAP) all day long; all I really want is that you do it with some accuracy. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
On Thu, August 25, 2011 11:27 pm, Glen Zorn wrote: On 8/26/2011 1:13 PM, Dan Harkins wrote: On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote: On 8/26/2011 4:22 AM, Dan Harkins wrote: 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. I completely missed that. Sorry. But if the IETF standardized a wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a shared key) Please check your sources refrain from spouting nonsense; if EAP-pwd is really so wonderful you shouldn't need to disparage other work, it should stand on its own merit. I stand corrected. That must be why draft-zorn-emu-team proposed using MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. this has a relation to your misrepresentation how? It doesn't really, it was a reference to your implication that EAP-pwd cannot stand on its own merit, and requires the disparagement of other work to prop it up. Which I think we can both agree is not the case. Anyway, yes I misrepresented MSCHAPv2. It does produce a key. I was wrong. But I still think the statement that MSCHAPv2 is inappropriate for doing server unauthenticated provisioning mode is valid even with a secret key output by MSCHAPv2. I hope we can both agree on that too. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Dan: 1) My desire to use GPSK with anonymous server authentication is more or less unrelated to any other part of this discussion. I want to be able to do it because I think I might deploy it and I don't want the spec to forbid a deployment I consider reasonable. There is no security justification for forbidding GPSK with strong keys combined with anonymous authentication. Again I'd be happy to provide text. 2) You've convinced me that GPSK is not a good MTI choice because of the dictionary attack resistance issue. I didn't carefully consider before suggesting GPSK as an MTI mechanism. I do think GPSK should be permitted to use (point 1) but I agree that's a kind of obscure deployment. 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. 4) I don't think we have any generally appropriate MTI mechanisms here, so we should not choose one. I think it would be fine to say implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of their choice. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Sam, On Thu, August 25, 2011 8:35 am, Sam Hartman wrote: Dan: 1) My desire to use GPSK with anonymous server authentication is more or less unrelated to any other part of this discussion. I want to be able to do it because I think I might deploy it and I don't want the spec to forbid a deployment I consider reasonable. There is no security justification for forbidding GPSK with strong keys combined with anonymous authentication. Again I'd be happy to provide text. If you have a scalable way to securely deploy large uniformly random blobs of bits in multiple disparate locations you have the ability to deploy a PKCS#12 containing everything you need to use the tunnel method with nice strong certificate-based authentication. 2) You've convinced me that GPSK is not a good MTI choice because of the dictionary attack resistance issue. I didn't carefully consider before suggesting GPSK as an MTI mechanism. I do think GPSK should be permitted to use (point 1) but I agree that's a kind of obscure deployment. The rare, and obscure, deployment in which it is appropriate to use EAP-GPSK would also be quite appropriate to use EAP-pwd. But the converse does not hold. The more common, and unobscure, deployment that is inappropriate for EAP-GPSK would still be quite appropriate for EAP-pwd. So there's no use case that EAP-GPSK is uniquely appropriate for, but there are plenty that EAP-pwd is uniquely appropriate for. 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. I completely missed that. Sorry. But if the IETF standardized a wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a shared key) then I really don't understand your opposition to EAP-pwd. MSCHAPv2 became widespread solely due to Windows. A fait acomplii is much more of an end run than a down-ref to EAP-pwd. 4) I don't think we have any generally appropriate MTI mechanisms here, so we should not choose one. I think it would be fine to say implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of their choice. Like EAP-GPSK? Why stop there? How about EAP-MD5! It's their choice after all. The thing is, EAP-GPSK allows for using short, low entropy, ASCII strings as the shared secret. You may say that your particular use is gonna have large uniformly random hexadecimal blobs of bits as the shared secret but the RFC says the UI must support ASCII and sets no lower limit on the size of the shared secret. So, effectively, you're insisting that the tunnel method be susceptible to dictionary attack! Maybe my frustration is getting the better of me but RFC 3967 (which clarifies when standards track documents may refer normatively to documents at a lower level) says in its security considerations that: inappropriate or excessive use of the process might be considered a downgrade attack on the quality of IETF standards or, worse, on the rigorous review of security aspects of standards. and I'd like to know: - why it is not inappropriate to insist on the completion of a non-existent process before we require the use of any ZKPP; and, - why making it possible to launch a dictionary attack against the tunnel method is not a downgrade attack on the quality of this IETF standard. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
On 8/26/2011 4:22 AM, Dan Harkins wrote: 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. I completely missed that. Sorry. But if the IETF standardized a wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a shared key) Please check your sources refrain from spouting nonsense; if EAP-pwd is really so wonderful you shouldn't need to disparage other work, it should stand on its own merit. then I really don't understand your opposition to EAP-pwd. MSCHAPv2 became widespread solely due to Windows. Hardly. The fact that the IETF was busy a) insisting that there was no, and never would be, any need for dynamic key generation (let alone mutual authentication) in network access protocols (specifically PPP; how could there be, since the only appropriate usage of PPP was to connect two routers which can easily be configured with telnet) and b) waiting with baited breath for the magical genesis of the universal PKI (which would happen because IPsec required it that hamstrung niche protocol was so wonderful that the world would change to satisfy its requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded because it satisfied a need that the IETF was simultaneously too ignorant and arrogant to see. ... ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Dan == Dan Harkins dhark...@lounge.org writes: Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method. I support all of dan's changes regarding unauthenticated server mode with the exception of the quoted text above. I do not generally support a down-reference to an informational document in a case like this. (It would need to be a normative reference in that context). I don't think RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have any MTI choices for this other than GPSK. I'd be happy either with GPSK or leaving the MTI eap method unspecified. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: Dan == Dan Harkins dhark...@lounge.org writes: Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method. I support all of dan's changes regarding unauthenticated server mode with the exception of the quoted text above. I do not generally support a down-reference to an informational document in a case like this. (It would need to be a normative reference in that context). I don't think RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have any MTI choices for this other than GPSK. I'd be happy either with GPSK or leaving the MTI eap method unspecified. EAP-GPSK is not resistant to dictionary attack and therefore would be unqualifed to be used according to the changes I propose that you already support (i.e. that the EAP method be resistant to dictionary attack). Regarding what it means to be resistant to a dictionary attack, let me quote some experts in the field [1], One sees whether or not one has security against dictionary attacks by looking to see if maximal adversarial advantage grows primarily with the ratio of interaction to the size of the password space. You will note that with GPSK it does not. Given a password space of X (all numbers less than 2^128, or the words from Webster's, whatever) there can be one single interaction followed by computational work to exhaustively go through the password space seeing if a guess is correct. The adversarial advantage grows through computation and not interaction. Increasing the size of the password space (which is what EAP-GPSK recommends) may make a successful dictionary attack harder but it does not magically make a protocol resistant to dictionary attack. On the other hand, EAP-pwd is resistant to dictionary attack. Normative reference to Informational RFCs is done all the time. What would we do without RFC 2104! regards, Dan. [1] Mihir Bellare, David Pointcheval, and Phillip Rogaway in Authenticated Key Exchange Secure Against Dictionary Attack. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] server unauthenticated provisioning mode
Dan == Dan Harkins dhark...@lounge.org writes: Dan On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: Dan == Dan Harkins dhark...@lounge.org writes: Dan and MUST support EAP-pwd [RFC 5931] as a phase 2 method. I support all of dan's changes regarding unauthenticated server mode with the exception of the quoted text above. I do not generally support a down-reference to an informational document in a case like this. (It would need to be a normative reference in that context). I don't think RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have any MTI choices for this other than GPSK. I'd be happy either with GPSK or leaving the MTI eap method unspecified. EAP-GPSK is not resistant to dictionary attack and therefore would Dan be unqualifed to be used according to the changes I propose Dan that you already support (i.e. that the EAP method be resistant Dan to dictionary attack). OK. Then I think we need to broaden up your text somewhat. I think GPSK is fine in a deployment where you expect random keys. I think something that has offline dictionary attack resistance would be fine in an area where passwords might be used. I'd like to relax your text to permit both. Dan Regarding what it means to be resistant to a dictionary Dan attack, let me quote some experts in the field [1], One sees Dan whether or not one has security against dictionary attacks by Dan looking to see if maximal adversarial advantage grows primarily Dan with the ratio of interaction to the size of the password Dan space. I think that definition is OK. I don't want us to require ZKPP to get the dictionary attack resistance security claim. I agree GPSK should not have the dictionary attack resistance security claim. I do want GPSK to be permitted in environments where it is appropriate. I absolutely do not support EAP-PWD as a MTI for this document unless EAP-PWD is moved to the standards track. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] server unauthenticated provisioning mode
Hello, The tunnel method draft indicates that an anonymous TLS ciphersuite should only be used in accordance with the server unauthenticated provisioning mode described in RFC 5422. This is unfortunate because the technique described in RFC 5422 requires changes to an existing EAP method, which is unnecessarily confusing, and it is also susceptible to attack. I propose we fix this problem by defining a server unauthenticated provisioning mode in the draft itself, something similar to the technique used by TEAM. To do this there are a couple places that need to get touched. - Section 3.2 says, Other ciphersuites MAY be supported. It is RECOMMENDED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in [RFC5422]. I suggest it say, Other ciphersuites MAY be supported. It is REQUIRED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in new section. - Adding a new section to describe the technique. I suggest making this a new 3.4 and bumping 3.4-7 to 3.5-8. New section should read: 3.4 Server Unauthenticated Provisioning Mode In Server Unauthenticated Provisioning Mode, an unauthenticated tunnel is established in phase 1 and the peer and server negotiate an EAP method in phase 2 that supports mutual authentication and key derivation that is resistant to dictionary attack. This provisioning mode enables the bootstrapping of peers when the peer lacks a strong credential usable for mutual authentication with the server during phase 1. Upon successful completion of the EAP method in phase 2, the peer and server exchange a Crypto-Binding TLV to bind the inner method with the outer method and ensure that a man-in-the-middle attack has not been attempted. Support for the Server Unauthenticated Provisioning Mode is optional but to ensure interoperability, an implementation that does support Server Unauthenticated Provisioning Mode MUST support TLS_DH_anon_WITH_AES_128_CBC_SHA as a TLS ciphersuite and MUST support EAP-pwd [RFC 5931] as a phase 2 method. Other anonymous ciphersuites MAY be supported. Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST provide mutual authentication, key generation, and be resistant to dictionary attack. regards, Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
