Re: [Emu] TLV type layout
On 8/24/2011 3:03 AM, Dan Harkins wrote: Hello, I noticed that the initial registry for TLV types starts out with three reserved numbers which is pretty odd. It says in the IANA Considerations (similar verbage is in the General TLV Format of section 4.2.1): A summary of the EAP-FAST TLV types is given below: 0 Reserved 1 Reserved 2 Reserved 3 Result TLV 4 NAK TLV 5 Error TLV et cetera Since this is the initial layout of a new registry it doesn't serve a purpose to have 1 and 2 reserved. Zero I can understand, Can you explain it to me, because I don't ;-). All numbers except those specifically assigned are by definition reserved, right? but not 1 and 2. I propose this get changed to move everything from 3 on up by 2 so Result TLV becomes 1, NAK TLV becomes 2, et cetera. I would prefer to start at 0. regards, Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ 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
