Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
>From a developer point of view, I share the same opinion as Yaron about this issue. Instead of creating new solutions, I personally think that it would be better to offer guidlines on how to implement current solutions (i.e EAP) and provide documents targeting implementers. This would create less confusion and keep IKEv2 a clean, easy to understand and use protocol. Regards, Matthew 2009/12/1 Yaron Sheffer > Hi everyone, > > [WG co-chair hat off] > > I believe this effort is misguided, and would be a waste of the WG time. > > EAP was added to IKEv2 to provide "legacy" (a.k.a. password) > authentication. In the past it did not do it very well, but this is > changing. We should improve the use of EAP in IKEv2, rather than replacing > it by a homebrew solution. > > Specifically, the following EAP methods can be used today (or in the near > future) for mutual password-based auth: > > - Dan's own EAP-PWD, > http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12 > - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 > - The long expired EAP-SRP, > http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 > - A rumored EAP method based on the PAK protocol ( > http://tools.ietf.org/html/draft-brusilovsky-pak-10) > > Embedding one of these methods as the single way to do mutual auth in IKE > simply doesn't make sense. > > In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto > protocol. It has had by far the least crypto review than the other three > protocols. IMHO, this working group should NOT be developing new > cryptographic protocols. This is not where our expertise lies. > > Lastly, one of the major criticisms with IKEv1 was the number of protocol > modes. And here we are, with a proposal to add another mode to IKEv2. > Doesn't seem like a good idea to me. > > Thanks, >Yaron > > > > -Original Message- > > From: Dan Harkins [mailto:dhark...@lounge.org] > > Sent: Tuesday, December 01, 2009 1:35 > > To: Yaron Sheffer > > Cc: ipsec@ietf.org > > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > > (SPSK) > > > > > > Hello, > > > > As can be inferred by my previous posting on EAP-only authentication, > > I favor this particular method for mutual authentication. > > > > I believe this is a general purpose exchange, useful for more than the > > narrow focus of EAP-only, does not require extraneous encapsulations or > > unnecessary code (ala EAP-only), and is secure regardless of its use > > (unlike EAP-only). > > > > I am committed to working on this as a WG work item. I agree to > continue > > contributing to the text and (co-)authoring the text. I solicit help, and > > support, from those who are interested in this task. > > > > regards, > > > > Dan. > > > > On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > > > This draft proposes a particular method for mutual authentication of > > IKEv2 > > > peers using a short, low quality shared secret (a.k.a. "password"). The > > > proposal is to embed this method in the IKE exchange, rather than use > > EAP. > > > > > > Proposed starting point: > > > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. > > > > > > Please reply to the list: > > > > > > - If this proposal is accepted as a WG work item, are you committing to > > > review multiple versions of the draft? > > > - Are you willing to contribute text to the draft? > > > - Would you like to co-author it? > > > > > > Please also reply to the list if: > > > > > > - You believe this is NOT a reasonable activity for the WG to spend > time > > > on. > > > > > > If this is the case, please explain your position. Do not explore the > > fine > > > technical details (which will change anyway, once the WG gets hold of > > the > > > draft); instead explain why this is uninteresting for the WG or for the > > > industry at large. Also, please mark the title clearly (e.g. "DES40- > > export > > > in IPsec - NO!"). > > > ___ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hello Dan, [WG co-chair hat off] EAP-only authentication is a small IKE extension that does not change the existing IKE architecture; neither does it change many of the extant implementations. Given the right EAP methods, it would provide us exactly what EAP was supposed to provide from day one: mutual non-PKI authentication. And the solution is generic: any suitable EAP method can be deployed, so implementors can make their own security/interoperability/IPR/simplicity tradeoffs, instead of having one specific authentication method mandated. To address your specific concerns: - The case of client-to-gateway authentication happens to be one of the top use cases of IKE/IPsec. Certainly not a "small use case". I'm not saying that EAP-only auth is limited to this use case, but it certainly solves it well. - It would depend very much on the specific product/scenario whether "both client and server state machines" need to be implemented. Specifically this is incorrect for client-to-gateway. - EAP as you well know is a 3-party protocol, it is not necessarily terminated on the IKE peer. So it is incorrect to say that "both sides MUST possess the shared secret" - exactly the right parties will need to: the client and the authentication server. - EAP-only auth can also be applied to scenarios where no Auth Server is deployed. However in these cases both peers would indeed need a full EAP implementation. - The EAP community is (very slowly) coming to terms with EAP channel bindings. While this is not provided by your EAP-PWD (and I hope this is fixed before publication), EAP-EKE has been extended to add this capability. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 1:06 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2 > > > Hello, > > I do not believe this is a reasonable activity to spend WG time on. > The reason is that for this proposal to be useful for more than a > small, specific, edge condition the following must apply: > > - both sides MUST implement both client- and server-side EAP state > machines. > - both sides MUST possess the shared secret. > > And in that case EAP encapsulation of the underlying key exchange would > be completely pointless and extraneous, would double the number of > messages required to complete the exchange, and would increase the amount > of security-critical code. More work for no benefit...not a good idea. > > In addition, EAP-only authentication increases potential insecurity, > where an external EAP server can authenticate any identity an IKEv2 > gateway wants to claim-- the "lying NAS problem". Authentication depends > on a verifiable identity and if one side can claim any identity it chooses > then the mutual authentication properties of IKE cannot be met. > > Even if one believes that the small, specific, edge condition is really > important there is an alternative to address that case, one that can also > address other peer-to-peer, subnet-to-subnet, and tranport mode, use > cases. That is the "Secure PSK authentication" option as defined in > draft-harkins-ipsecme-spsk-auth-00.txt. > > It seems to me that EAP-only authentication in IKEv2: > > 1. does not solve a general problem; > 2. solves the specific problem it is aimed at poorly-- doubling of > the number of messages, requiring writing and testing of new > state EAP state machines that are, otherwise, unnecessary; and, > 3. is insecure (unless something used nowhere today is employed: EAP > channel bindings). > > To provide the benefits of EAP-only authentication-- certificate-less > mutual authentication based only on a password-- it would be much better > to support the inclusion of "Secure PSK authentication" as a work item. > That work item will not only address the small use case that EAP-only > authentication is aimed at, it will also address other peer-to-peer, > subnet-to-subnet, and transport-mode use cases. And it will do so in a > manner that ensures security. > > regards, > > Dan. > > On Sun, November 29, 2009 9:18 am, Yaron Sheffer wrote: > > This draft proposes an IKEv2 extension to allow mutual EAP-based > > authentication in IKEv2, eliminating the need for one of the peers to > > present a certificate. This applies to a small number of key-generating > > EAP methods that allow mutual authentication. > > > > Proposed starting point: > > http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt. > > > > Please reply to the list: > > > > - If this proposal is accepted as a WG work item, are you committing to > > review multiple versions of the draft? > > - Are you willing to contribute text to the draft? > > - Would you like to co-author it? > > > > Please also reply to the list if: > > > > - You believe this is NOT a reasonable activity for th
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK) - NO
Hi everyone, [WG co-chair hat off] I believe this effort is misguided, and would be a waste of the WG time. EAP was added to IKEv2 to provide "legacy" (a.k.a. password) authentication. In the past it did not do it very well, but this is changing. We should improve the use of EAP in IKEv2, rather than replacing it by a homebrew solution. Specifically, the following EAP methods can be used today (or in the near future) for mutual password-based auth: - Dan's own EAP-PWD, http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-12 - My EAP-EKE, http://tools.ietf.org/html/draft-sheffer-emu-eap-eke-03 - The long expired EAP-SRP, http://tools.ietf.org/html/draft-ietf-pppext-eap-srp-03 - A rumored EAP method based on the PAK protocol (http://tools.ietf.org/html/draft-brusilovsky-pak-10) Embedding one of these methods as the single way to do mutual auth in IKE simply doesn't make sense. In addition, SPSK (which is equivalent to EAP-PWD) is a novel crypto protocol. It has had by far the least crypto review than the other three protocols. IMHO, this working group should NOT be developing new cryptographic protocols. This is not where our expertise lies. Lastly, one of the major criticisms with IKEv1 was the number of protocol modes. And here we are, with a proposal to add another mode to IKEv2. Doesn't seem like a good idea to me. Thanks, Yaron > -Original Message- > From: Dan Harkins [mailto:dhark...@lounge.org] > Sent: Tuesday, December 01, 2009 1:35 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Proposed work item: IKEv2 password authentication > (SPSK) > > > Hello, > > As can be inferred by my previous posting on EAP-only authentication, > I favor this particular method for mutual authentication. > > I believe this is a general purpose exchange, useful for more than the > narrow focus of EAP-only, does not require extraneous encapsulations or > unnecessary code (ala EAP-only), and is secure regardless of its use > (unlike EAP-only). > > I am committed to working on this as a WG work item. I agree to continue > contributing to the text and (co-)authoring the text. I solicit help, and > support, from those who are interested in this task. > > regards, > > Dan. > > On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > > This draft proposes a particular method for mutual authentication of > IKEv2 > > peers using a short, low quality shared secret (a.k.a. "password"). The > > proposal is to embed this method in the IKE exchange, rather than use > EAP. > > > > Proposed starting point: > > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. > > > > Please reply to the list: > > > > - If this proposal is accepted as a WG work item, are you committing to > > review multiple versions of the draft? > > - Are you willing to contribute text to the draft? > > - Would you like to co-author it? > > > > Please also reply to the list if: > > > > - You believe this is NOT a reasonable activity for the WG to spend time > > on. > > > > If this is the case, please explain your position. Do not explore the > fine > > technical details (which will change anyway, once the WG gets hold of > the > > draft); instead explain why this is uninteresting for the WG or for the > > industry at large. Also, please mark the title clearly (e.g. "DES40- > export > > in IPsec - NO!"). > > ___ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: IKEv2 password authentication (SPSK)
Hello, As can be inferred by my previous posting on EAP-only authentication, I favor this particular method for mutual authentication. I believe this is a general purpose exchange, useful for more than the narrow focus of EAP-only, does not require extraneous encapsulations or unnecessary code (ala EAP-only), and is secure regardless of its use (unlike EAP-only). I am committed to working on this as a WG work item. I agree to continue contributing to the text and (co-)authoring the text. I solicit help, and support, from those who are interested in this task. regards, Dan. On Sun, November 29, 2009 9:20 am, Yaron Sheffer wrote: > This draft proposes a particular method for mutual authentication of IKEv2 > peers using a short, low quality shared secret (a.k.a. "password"). The > proposal is to embed this method in the IKE exchange, rather than use EAP. > > Proposed starting point: > http://tools.ietf.org/id/draft-harkins-ipsecme-spsk-auth-00.txt. > > Please reply to the list: > > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? > > Please also reply to the list if: > > - You believe this is NOT a reasonable activity for the WG to spend time > on. > > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...)
Hi Tero, Groups 1 and 2 were defined in RFC 2409 and repeating them in a subsequent RFC does not change that. I suggest leaving the reference to RFC 2409 for groups 1 and 2 (and 3 and 4 for that matter) that currently exists today at http://www.iana.org/assignments/ipsec-registry, as of 2315 GMT on 30 November 2009, aka "right now". regards, Dan. On Mon, November 30, 2009 4:43 am, Tero Kivinen wrote: > Now talking only about the Tranform Type 4 - Diffie-Hellman Group > Transform IDs IANA registry. > > Valery Smyslov writes: >> Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not >> defined in IANA. >> For me this is inconsistent. Either change two abovementioned lines to: >> >> 1 768-Bit MODP Group[RFC4306] >> 2 1024-Bit MODP Group [RFC4306] >> >> 14 2048-Bit MODP Group [RFC3526] >> 15 3072-Bit MODP Group [RFC3526] >> 16 4096-Bit MODP Group [RFC3526] >> 17 6144-Bit MODP Group [RFC3526] >> 18 8192-Bit MODP Group [RFC3526] > > Hmm... I think the IANA registry should really list these out, instead > of using range to reference to the RFCs. > > I think we should fix the IANA registry so the group names will match > the section / appendix names in the appropriate RFCs and where there > would not be any range allocations. The resulting IANA registry would > be like this: > -- > Registry Name: Transform Type 4 - Diffie-Hellman Group Transform IDs > Reference: [RFC4306] > Registration Procedures: Expert Review > > Registry: > NumberNameReference > -- - > 0 NONE[RFC4306] > 1 Group 1 - 768 Bit MODP Group[RFC4306] > 2 Group 2 - 1024 Bit MODP Group [RFC4306] > 3-4 Reserved[RFC4306] > 5 1536-bit MODP Group [RFC3526] > 6-13 Unassigned [RFC4306] > 142048-bit MODP Group [RFC3526] > 153072-bit MODP Group [RFC3526] > 164096-bit MODP Group [RFC3526] > 176144-bit MODP Group [RFC3526] > 188192-bit MODP Group [RFC3526] > 19256-bit random ECP group[RFC4753] > 20384-bit random ECP group[RFC4753] > 21521-bit random ECP group[RFC4753] > 221024-bit MODP Group with 160-bit[RFC5114] > Prime Order Subgroup > 232048-bit MODP Group with 224-bit[RFC5114] > Prime Order Subgroup > 242048-bit MODP Group with 256-bit[RFC5114] > Prime Order Subgroup > 25192-bit Random ECP Group[RFC5114] > 26224-bit Random ECP Group[RFC5114] > 27-1023 Unassigned [RFC4306] > 1024-65535Private use [RFC4306] > -- > > Unless anybody objects, I will be requesting IANA to make the change > next week. > > -- > kivi...@iki.fi > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Proposed work item: EAP-only authentication in IKEv2
Hello, I do not believe this is a reasonable activity to spend WG time on. The reason is that for this proposal to be useful for more than a small, specific, edge condition the following must apply: - both sides MUST implement both client- and server-side EAP state machines. - both sides MUST possess the shared secret. And in that case EAP encapsulation of the underlying key exchange would be completely pointless and extraneous, would double the number of messages required to complete the exchange, and would increase the amount of security-critical code. More work for no benefit...not a good idea. In addition, EAP-only authentication increases potential insecurity, where an external EAP server can authenticate any identity an IKEv2 gateway wants to claim-- the "lying NAS problem". Authentication depends on a verifiable identity and if one side can claim any identity it chooses then the mutual authentication properties of IKE cannot be met. Even if one believes that the small, specific, edge condition is really important there is an alternative to address that case, one that can also address other peer-to-peer, subnet-to-subnet, and tranport mode, use cases. That is the "Secure PSK authentication" option as defined in draft-harkins-ipsecme-spsk-auth-00.txt. It seems to me that EAP-only authentication in IKEv2: 1. does not solve a general problem; 2. solves the specific problem it is aimed at poorly-- doubling of the number of messages, requiring writing and testing of new state EAP state machines that are, otherwise, unnecessary; and, 3. is insecure (unless something used nowhere today is employed: EAP channel bindings). To provide the benefits of EAP-only authentication-- certificate-less mutual authentication based only on a password-- it would be much better to support the inclusion of "Secure PSK authentication" as a work item. That work item will not only address the small use case that EAP-only authentication is aimed at, it will also address other peer-to-peer, subnet-to-subnet, and transport-mode use cases. And it will do so in a manner that ensures security. regards, Dan. On Sun, November 29, 2009 9:18 am, Yaron Sheffer wrote: > This draft proposes an IKEv2 extension to allow mutual EAP-based > authentication in IKEv2, eliminating the need for one of the peers to > present a certificate. This applies to a small number of key-generating > EAP methods that allow mutual authentication. > > Proposed starting point: > http://tools.ietf.org/id/draft-eronen-ipsec-ikev2-eap-auth-07.txt. > > Please reply to the list: > > - If this proposal is accepted as a WG work item, are you committing to > review multiple versions of the draft? > - Are you willing to contribute text to the draft? > - Would you like to co-author it? > > Please also reply to the list if: > > - You believe this is NOT a reasonable activity for the WG to spend time > on. > > If this is the case, please explain your position. Do not explore the fine > technical details (which will change anyway, once the WG gets hold of the > draft); instead explain why this is uninteresting for the WG or for the > industry at large. Also, please mark the title clearly (e.g. "DES40-export > in IPsec - NO!"). > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...)
At 2:43 PM +0200 11/30/09, Tero Kivinen wrote: >Unless anybody objects, I will be requesting IANA to make the change >next week. Not only do I not object, I thank you for doing something I volunteered to do. --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-11.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename: draft-ietf-ipsecme-traffic-visibility-11.txt Pages : 15 Date: 2009-11-30 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) [RFC4303], and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec ESP standard, there is no way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename: draft-ietf-ipsecme-esp-null-heuristics-03.txt Pages : 36 Date: 2009-11-30 This document describes a set of heuristics for distinguishing IPsec ESP-NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. These heuristics can be used on intermediate devices, like traffic analyzers, and deep inspection engines, to quickly decide whether given packet flow is interesting or not. Use of these heuristics does not require any changes made on existing RFC4303 compliant IPsec hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
>> I don't agree with you. Remember, when IKEv2 was being developed, >> one of the motivations for single self-contained document was complaint >> from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 >> was very inconvinient and provoked confusions that led to interoperability >> problems. Now you suggest to make IKEv2 not self-contained again. >> Of course, I understand that IANA registry is not another RFC, but >> I still prefer single self-contained document for core protocol. >> If you need extensions - go to IANA and look for added numbers, >> but core protocol must be implementable reading as few sources, >> as possible, preferrably one. > >I completely agree on that. I also agree with Valery and Tero. Dave Wierbowski ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Diffie-Hellman group transform IDs IANA registry (was #123: ...)
Now talking only about the Tranform Type 4 - Diffie-Hellman Group Transform IDs IANA registry. Valery Smyslov writes: > Currently exact groups for numbers 1, 2, 14, 15, 16, 17 and 16 are not > defined in IANA. > For me this is inconsistent. Either change two abovementioned lines to: > > 1 768-Bit MODP Group[RFC4306] > 2 1024-Bit MODP Group [RFC4306] > > 14 2048-Bit MODP Group [RFC3526] > 15 3072-Bit MODP Group [RFC3526] > 16 4096-Bit MODP Group [RFC3526] > 17 6144-Bit MODP Group [RFC3526] > 18 8192-Bit MODP Group [RFC3526] Hmm... I think the IANA registry should really list these out, instead of using range to reference to the RFCs. I think we should fix the IANA registry so the group names will match the section / appendix names in the appropriate RFCs and where there would not be any range allocations. The resulting IANA registry would be like this: -- Registry Name: Transform Type 4 - Diffie-Hellman Group Transform IDs Reference: [RFC4306] Registration Procedures: Expert Review Registry: NumberNameReference -- - 0 NONE[RFC4306] 1 Group 1 - 768 Bit MODP Group[RFC4306] 2 Group 2 - 1024 Bit MODP Group [RFC4306] 3-4 Reserved[RFC4306] 5 1536-bit MODP Group [RFC3526] 6-13 Unassigned [RFC4306] 142048-bit MODP Group [RFC3526] 153072-bit MODP Group [RFC3526] 164096-bit MODP Group [RFC3526] 176144-bit MODP Group [RFC3526] 188192-bit MODP Group [RFC3526] 19256-bit random ECP group[RFC4753] 20384-bit random ECP group[RFC4753] 21521-bit random ECP group[RFC4753] 221024-bit MODP Group with 160-bit[RFC5114] Prime Order Subgroup 232048-bit MODP Group with 224-bit[RFC5114] Prime Order Subgroup 242048-bit MODP Group with 256-bit[RFC5114] Prime Order Subgroup 25192-bit Random ECP Group[RFC5114] 26224-bit Random ECP Group[RFC5114] 27-1023 Unassigned [RFC4306] 1024-65535Private use [RFC4306] -- Unless anybody objects, I will be requesting IANA to make the change next week. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Valery Smyslov writes: > >> What about EAP Message format and magic numbers? Remove and just > >> reference RFC3748 (or IANA entry for EAP)? > > > > No, those were left in because they came from an RFC, not from a > > particular IANA registry where the names match what we have in IKEv2bis. > > EAP numbers listed in RFC4306 might also be changed in future, > so from your logic it's better just to point to > http://www.iana.org/assignments/eap-numbers, right? This is good example of confision what happens when you point to external iana registry. In RFC4306 we have "Nak (Response only)". If you look to the iana registry for eap, you cannot find that one. You do find "Legacy Nak". Are those two same? As both tables have also the number 2 associated to the code, you know they are same. Reading RFC3748 you notice that it uses both "Nak" and "Legacy Nak". > I don't agree with you. Remember, when IKEv2 was being developed, > one of the motivations for single self-contained document was complaint > from implementers that having 3 RFC (2408, 2409, 2407) for IKEv1 > was very inconvinient and provoked confusions that led to interoperability > problems. Now you suggest to make IKEv2 not self-contained again. > Of course, I understand that IANA registry is not another RFC, but > I still prefer single self-contained document for core protocol. > If you need extensions - go to IANA and look for added numbers, > but core protocol must be implementable reading as few sources, > as possible, preferrably one. I completely agree on that. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
Paul Hoffman writes: > If a developer does not know how to read the IANA tables, we are all > in trouble. Nothing in the tables says "you must implement every > thing in these tables", of course. Then we are already in trouble. There is lots of developers who do not know about the IANA tables, they just grab the RFCs (without knowing about the IETF) and start to implement them. Not all developers follow IETF work, and quite a lot of developers do not know how IETF work, and what is the relation between IETF and IANA and so on. Also I do not think developers NEED to know the this kind of things, it should be enough for them to grab the documents and implement them. I do not think it is mandatory for them to understand what different IANA registration procedures mean. There is also lots of developers who do not know the difference between Informational RFC and Standard track RFC, and if they see numbers in the IANA registry they will think they should implement all of them. > I am now deeply concerned with this WG's relationship to the IANA > registry. We are not talking about the developers who are working on this WG. The whole world is not this WG, there is other people out there. Also I myself do find extra unnecessary indirections very annoying, and if possible, I try to avoid those. > >3. Sometimes there might be difficulties in matching names from RFC > >with IANA entries. For example, IANA registry has an entry named > >ENCR_AES-CCM_8, but in RFC5282 this algorithm is called > >AEAD_AES_128_CCM_SHORT_8. Are you sure these names reference the > >same algorithm? I prefer to check their IDs in RFC and in IANA > >registry. > > This is a bug in the IANA registry that needs to be fixed. It is not really a bug in IANA registry, as RFC4106 use those names, and it did allocate them. It is bug in the RFC5282, which should have used the same names for the same algorithms. On the other hand the rfc5282 do have table mapping the names it uses to the ENCR identifier numbers, and it DOES NOT have IANA actions for the Encryption Transform identifiers table, as those numbers have already been allocated before. > It is not related to the values being in the RFC. Tero has spent a > lot of time trying to fix the registry, but clearly we need more > effort here. I will certainly make sure that the names in the > registry match those in RFC 4306, and that the exact names are used > in IKEv2bis. On of the problems is the RFC4106 which predates IKEv2, which means it used completely different naming scheme than what was used in the rest of the documents, i.e. their algorithms do not have ENCR_* format, but is just text. I do not think we change that anymore. > >4. Some entries in Diffie-Hellman Group Transform IDs table do not > >really assign individual numbers, but instead point to other > >documens, even to RFC4306 itself, where the numbers are assigned. > > Again, I am concerned that you think we should get rid of the IANA > registry. That is not how the IETF works. I do not think anybody proposed to get rid of the IANA registry. I think everybody agreed that yes, we should have pointer to the IANA registry. But as those numbers are never going to change, they should also be listed here. > >Those numbers won't change, so their > >presence must not hurt, > > This is probably incorrect. In many WGs, when errors are found in > old definitions, the error is corrected *and a new value is > assigned*. That is the only way to assure interoperability. Which means they existing numbers are not going to change. There may be new numbers meaning almost same thing (but with fixed semantics), but the old number can only mean exactly what was meant at the time the RFC was written. > >just will make implementing of base protocol more > >convinient. > > The goal of our work is clarity and interoperability, not > convenience, particularly when the inconvenience is remedied by one > extra lookup. Extra lookup which WILL cause more bugs, which means implementations are not interoperable. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] #123: Proposal to remove the IANA tables from IKEv2bis
> >You probably speaks about "ideal" developers. I speak about real people. > >I've seen a few cases when people implemented a bunch of really > >unnecessary things just because "it was in standard". > > We still agree, and your answer is still inconsistent. If you worry about > those type of developers, then you must want to get rid of the IANA registry, > because that is what is giving them the silly ideas. No, I didn't mean that. I meant that the simpler description of the protocol is, the better implementation is (usually) developed by an average person. In this context adding one more step in the process of developing may (and, I think, will) lead to increasing number of non-ineroperable implementations. I suspect, you may get just the opposite results than you expects. > >I fail to understand how removing values from the RFC will help > >understanding the context for them. > > The context for the values is "they are assigned and maintained by IANA". > It is not "they came from this RFC". You may not like that, but that's how the IETF works. IANA doesn't assign any number by its own will - there must be request for that number and a corresponding RFC. And if this is a change to existing number, then this new RFC must either update base RFC or make it obsolete. Is it right? And even laziest developer will start implementing from finding the most recent RFC, updates and errata. > >It's not hard, but what for? I see some drawbacks and I don't see > >how it will help interoperability. > > Again: it helps interoperability if developers look in the IANA registry at the time > of coding and see changes have been made to what they thought was true based > only on reading an RFC. Those changes don't come from IANA itself, they come from updating RFC. And it is this RFC, which developer starts implementing from, not IANA. And only after finding this RFC he/she will usually go to IANA. And making changes to already assigned values must be as rare as possible, because it automatically makes existing implementations non-compliant. On the other hand, adding new values usually doen't affect base protocol. > >In any case base RFC will be updated. And the first thing one must do before > >implementing any protocol is to find most recent RFC for it, including > >all updates and erratas. This is natural way to go, and if one starts > >implementing old RFC, then even if you manage to force him to go > >to IANA for numbers, I doubt if he will get interoperable product. > > The IANA registry lists the current RFCs. Do you not think that is enough clue? No. RFC Editor Search Engine gives much more information regarding current status of RFC, existence of updates and errata. IANA is best for looking for protocol extensions, but it gives only current snapshot of the situation. If some values were changed, IANA wouldn't keep old references, and if you want to keep your product interoperable with previous versions, IANA won't help you. And if you remove number values from RFC, keepeng new products interoperable with previous in case of changing some assigned values will become next to impossible - you just will have no sources for old numbers. Regards, Smyslov Valery. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
