Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Hi Pasi, Pasi Eronen writes: > > And I want to raise one more issue. Section 4 mandates support > > for both PKIX and preshared key for conformant implementation. > > Isnt't it too strong requirement? > > > This requirement has been in the document for 4+ years. > > Unless there is concrete evidence of multiple implementors > encountering difficulties with it (and not just hypothetical > garage door openers), I would propose *not* re-visiting this > topic at this time. The main problem is not in the requirement for PKIX support per se (althouth it seems to be too much for small implementation). The problem is in requirement for particular algorithm - RSA. I understand, that RSA is widely used, but there may be situations when it is unavailable for some reason. For example, here in Russia all state organizations are not allowed to use RSA and must use only GOST 3410-2001 signature algorithm. I suspect the same situation may take place in other countries as well. >From my point of view, it is better to move all requirements for particular algorithm support from RFC4306 to RFC4307, where most of them already resides. That will allow building implementations conformant to RFC4306 with any set of algorithms (as protocol itself is completely algorithm independent), while RFC4307 will list those algorithms which will provide "universal" interoperability. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Valery Smyslov wrote: > And I want to raise one more issue. Section 4 mandates support > for both PKIX and preshared key for conformant implementation. > Isnt't it too strong requirement? This requirement has been in the document for 4+ years. Unless there is concrete evidence of multiple implementors encountering difficulties with it (and not just hypothetical garage door openers), I would propose *not* re-visiting this topic at this time. Best regards, Pasi (not wearing any hats) ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Raj Singh writes: > > Not really. Not all requirements needs to be in one place. One place > > can say that XXX is required and another place can say that also YYY > > is required, but only if doing ZZZ. > > > > > 1. Section 4 mandates certificates but section 3.5 doesn't. > > > > Section 3.5 does not and should not say anything about certificates, > > it just lists which ID types there are which of them needs to be > > supported. > > Agree. But it should mandate ID_DER_ASN1_DN which it doesn't. Yes, that's what I meant. And I want to raise one more issue. Section 4 mandates support for both PKIX and preshared key for conformant implementation. Isnt't it too strong requirement? First, for some very simple implementations (garage door opener) it may be unnecessary and difficult to implement, providing resource constraints (note, that full PKIX support is required, so raw RSA keys are out of scope). Then, I don't like "MUST" for particular algorithm (RSA) with particular parameters. One might have good reasons not to use RSA at all in favour of other public cryptography schemes. On the other hand, one might want to completely get rid of preshared key authentication in his/her product. And last, these requirements will automatically make non-conformant such proposed protocol extensions as EAP-only and password-based authentication. I fully understand desire to help interoperability, but I think that all requirements listed at the end of section 4 may be lowered to "SHOULD" (note, that this will not make any existing product non-conformant). What others think? Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
On Fri, Jan 22, 2010 at 5:15 PM, Tero Kivinen wrote: > > Raj Singh writes: > > I agree with Tero explanation and Valery objection as well. > > There is discrepancy between 3.5 and 4. > > Not really. Not all requirements needs to be in one place. One place > can say that XXX is required and another place can say that also YYY > is required, but only if doing ZZZ. > > > 1. Section 4 mandates certificates but section 3.5 doesn't. > > Section 3.5 does not and should not say anything about certificates, > it just lists which ID types there are which of them needs to be > supported. Agree. But it should mandate ID_DER_ASN1_DN which it doesn't. > > > 2. Its seen in practice that some implementation uses IP addresses as > > default ID even though they are > > using certificate based authentication or they are behind NAT. > > And this is allowed and section 3.5 sees that ID_IPV4_ADDR support is > madantory (and ID_IPV6_ADDR is mandatory for IPv6-capable > implementations). > > Nothing in the section 4 claims otherwise, so they are still mandatory > to accept from the other end. > > On the other hand section 4 does not require ID_IPV*_ADDR address to > be one of those which can be configured to be used and it adds one > more requirement compared to what section 3.5 said i.e. it says that > if PKIX certifiates are used then implementations need to also needto > be able to use ID_DER_ASN1_DN. To put my point simply: 1. Section 3.5: - Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. --- Here we are mandating that an implementation MUST be able to configure to accept 4 ID types with types without any mention of ID_DER_ASN1_DN. Section 4: --- For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: - PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. Here we are also mandating than an implementaion MUST be able to configure to accept ID_DER_ASN1_DN. This is what i was referring to that there is some discrepancy between 3.5 and 4. As PKIX support is MUST for implementations of ikev2bis, we can't say that we are adding one more requirement if PKIX is supported. > > > This should is NO use as explained by Tero and should be discouraged in > > draft and proper ID types i.e. ID_DER_ASN1_DN for > > certificate based authentication should be encouraged. > -- > kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Raj Singh writes: > I agree with Tero explanation and Valery objection as well. > There is discrepancy between 3.5 and 4. Not really. Not all requirements needs to be in one place. One place can say that XXX is required and another place can say that also YYY is required, but only if doing ZZZ. > 1. Section 4 mandates certificates but section 3.5 doesn't. Section 3.5 does not and should not say anything about certificates, it just lists which ID types there are which of them needs to be supported. > 2. Its seen in practice that some implementation uses IP addresses as > default ID even though they are > using certificate based authentication or they are behind NAT. And this is allowed and section 3.5 sees that ID_IPV4_ADDR support is madantory (and ID_IPV6_ADDR is mandatory for IPv6-capable implementations). Nothing in the section 4 claims otherwise, so they are still mandatory to accept from the other end. On the other hand section 4 does not require ID_IPV*_ADDR address to be one of those which can be configured to be used and it adds one more requirement compared to what section 3.5 said i.e. it says that if PKIX certifiates are used then implementations need to also needto be able to use ID_DER_ASN1_DN. > This should is NO use as explained by Tero and should be discouraged in > draft and proper ID types i.e. ID_DER_ASN1_DN for > certificate based authentication should be encouraged. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Hi Team, I agree with Tero explanation and Valery objection as well. There is discrepancy between 3.5 and 4. 1. Section 4 mandates certificates but section 3.5 doesn't. 2. Its seen in practice that some implementation uses IP addresses as default ID even though they are using certificate based authentication or they are behind NAT. This should is NO use as explained by Tero and should be discouraged in draft and proper ID types i.e. ID_DER_ASN1_DN for certificate based authentication should be encouraged. Regards, Raj On Fri, Jan 22, 2010 at 3:24 PM, Tero Kivinen wrote: > Paul Hoffman writes: > > At 9:17 PM -0500 1/21/10, wrote: > > >Paul, > > > > > >> What does "Implementations SHOULD be capable of generating and > > >accepting all of these types" mean? > > > > > >It's hair-splitting time ... > > > > > >> To assure maximum interoperability, implementations MUST be > > >configurable to send at least one of > > >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be > > >configurable to accept all of these > > >> types. > > > > > >Short version: MUST be able to send at least *1*, accept all *4*. > > > > > >> Implementations SHOULD be capable of generating and accepting all of > > >these types. > > > > > >Short version: In addition, SHOULD be able to send all *4*. > > > > > >The SHOULD for "accepting" is redundant with the previous MUST, but the > > >SHOULD for "generating" is broader. > > > > > >[... snip ...] > > > > > >> If it means all the listed types, the sentence should be changed to > > >"Implementations SHOULD > > >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and > > >ID_DER_ASN1_GN." > > > > > >Which I think amounts to a SHOULD for certificate support. Is there a > > >good reason to go there? > > > > This interpretation is quite surprising to me (but I am surprised > > often these days...). What do others think? > > I interpreted it so that MUST be able to send one, accept all four > and SHOULD be able to send all four. > > Note, also that Section 4 also lists in its conformance list that all > implementations MUST be able to be configured to accept: > -- >For an implementation to be called conforming to this specification, > it MUST be possible to configure it to accept the following: > > o PKIX Certificates containing and signed by RSA keys of size 1024 > or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, > ID_RFC822_ADDR, or ID_DER_ASN1_DN. > > o Shared key authentication where the ID passed is any of ID_KEY_ID, > ID_FQDN, or ID_RFC822_ADDR. > > o Authentication where the responder is authenticated using PKIX > Certificates and the initiator is authenticated using shared key > authentication. > -- > > I.e. that adds ID_DER_ASN1_DN for certificates, and does not list > ID_IPV*_ADDR at all. > > I.e. even when ID_IPV4_ADDR is mandatory to be implement, that does > not need to be one of the configurations that is required from > implementation (which is ok, as if you make implementation which is > always behind NAT, then IP-address is not something you want to allow > to be configured as ID). > > So Certificate support is already MUST, Shared key authentication is > MUST. ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR are MUST for accept for both > authentication, ands ID_DER_ASN1_DN is MUST for accept for certificate > authentication. > > The section 4 can also be understood that sending all of the ID > formats is also required, as the text says "ID passed is any of ..." > which would indicate that it requires also sending those ID types. > > These requirements are not required to be same, as the other covers > the ID payload support, and the other covers the how the whole system > is configured and used. > -- > 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] Issue #156: SHOULD generate and accept which types?
Paul Hoffman writes: > At 9:17 PM -0500 1/21/10, wrote: > >Paul, > > > >> What does "Implementations SHOULD be capable of generating and > >accepting all of these types" mean? > > > >It's hair-splitting time ... > > > >> To assure maximum interoperability, implementations MUST be > >configurable to send at least one of > >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be > >configurable to accept all of these > >> types. > > > >Short version: MUST be able to send at least *1*, accept all *4*. > > > >> Implementations SHOULD be capable of generating and accepting all of > >these types. > > > >Short version: In addition, SHOULD be able to send all *4*. > > > >The SHOULD for "accepting" is redundant with the previous MUST, but the > >SHOULD for "generating" is broader. > > > >[... snip ...] > > > >> If it means all the listed types, the sentence should be changed to > >"Implementations SHOULD > >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and > >ID_DER_ASN1_GN." > > > >Which I think amounts to a SHOULD for certificate support. Is there a > >good reason to go there? > > This interpretation is quite surprising to me (but I am surprised > often these days...). What do others think? I interpreted it so that MUST be able to send one, accept all four and SHOULD be able to send all four. Note, also that Section 4 also lists in its conformance list that all implementations MUST be able to be configured to accept: -- For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. o Shared key authentication where the ID passed is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR. o Authentication where the responder is authenticated using PKIX Certificates and the initiator is authenticated using shared key authentication. -- I.e. that adds ID_DER_ASN1_DN for certificates, and does not list ID_IPV*_ADDR at all. I.e. even when ID_IPV4_ADDR is mandatory to be implement, that does not need to be one of the configurations that is required from implementation (which is ok, as if you make implementation which is always behind NAT, then IP-address is not something you want to allow to be configured as ID). So Certificate support is already MUST, Shared key authentication is MUST. ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR are MUST for accept for both authentication, ands ID_DER_ASN1_DN is MUST for accept for certificate authentication. The section 4 can also be understood that sending all of the ID formats is also required, as the text says "ID passed is any of ..." which would indicate that it requires also sending those ID types. These requirements are not required to be same, as the other covers the ID payload support, and the other covers the how the whole system is configured and used. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Black David writes: > > If it means all the listed types, the sentence should be changed to > "Implementations SHOULD > > also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and > ID_DER_ASN1_GN." > > Which I think amounts to a SHOULD for certificate support. Is there a > good reason to go there? It is already there :-) See section 4 (Conformance Requirements): For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. o Shared key authentication where the ID passed is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR. o Authentication where the responder is authenticated using PKIX Certificates and the initiator is authenticated using shared key authentication. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Paul Hoffman writes: > Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says: > > Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR. > > What does "Implementations SHOULD be capable of generating and accepting all of these types" mean? It can't mean the four just listed, because that list of four comes with MUSTs. If it means all the listed types, the sentence should be changed to "Implementations SHOULD also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN." In addition, this is inconsistent with section 4 (Conformance Requirements), which states: For an implementation to be called conforming to this specification, it MUST be possible to configure it to accept the following: o PKIX Certificates containing and signed by RSA keys of size 1024 or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or ID_DER_ASN1_DN. o Shared key authentication where the ID passed is any of ID_KEY_ID, ID_FQDN, or ID_RFC822_ADDR. o Authentication where the responder is authenticated using PKIX Certificates and the initiator is authenticated using shared key authentication. Regards, Valery Smyslov. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
At 9:17 PM -0500 1/21/10, wrote: >Paul, > >> What does "Implementations SHOULD be capable of generating and >accepting all of these types" mean? > >It's hair-splitting time ... > >> To assure maximum interoperability, implementations MUST be >configurable to send at least one of >> ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be >configurable to accept all of these >> types. > >Short version: MUST be able to send at least *1*, accept all *4*. > >> Implementations SHOULD be capable of generating and accepting all of >these types. > >Short version: In addition, SHOULD be able to send all *4*. > >The SHOULD for "accepting" is redundant with the previous MUST, but the >SHOULD for "generating" is broader. > >[... snip ...] > >> If it means all the listed types, the sentence should be changed to >"Implementations SHOULD >> also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and >ID_DER_ASN1_GN." > >Which I think amounts to a SHOULD for certificate support. Is there a >good reason to go there? This interpretation is quite surprising to me (but I am surprised often these days...). What do others think? --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Issue #156: SHOULD generate and accept which types?
Paul, > What does "Implementations SHOULD be capable of generating and accepting all of these types" mean? It's hair-splitting time ... > To assure maximum interoperability, implementations MUST be configurable to send at least one of > ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these > types. Short version: MUST be able to send at least *1*, accept all *4*. > Implementations SHOULD be capable of generating and accepting all of these types. Short version: In addition, SHOULD be able to send all *4*. The SHOULD for "accepting" is redundant with the previous MUST, but the SHOULD for "generating" is broader. [... snip ...] > If it means all the listed types, the sentence should be changed to "Implementations SHOULD > also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN." Which I think amounts to a SHOULD for certificate support. Is there a good reason to go there? Thanks, --David > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Hoffman > Sent: Thursday, January 21, 2010 8:49 PM > To: IPsecme WG > Subject: [IPsec] Issue #156: SHOULD generate and accept which types? > > Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, > ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says: > > Two implementations will interoperate only if each can generate a type of ID acceptable to the other. > To assure maximum interoperability, implementations MUST be configurable to send at least one of > ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these > types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable > implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations > MAY be configurable to send only ID_IPV6_ADDR. > > What does "Implementations SHOULD be capable of generating and accepting all of these types" mean? It > can't mean the four just listed, because that list of four comes with MUSTs. If it means all the > listed types, the sentence should be changed to "Implementations SHOULD also be capable of generating > ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN." > > --Paul Hoffman, Director > --VPN Consortium > ___ > 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
[IPsec] Issue #156: SHOULD generate and accept which types?
Section 3.5 lists a bunch of ID types (ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_IPV6_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN, and ID_KEY_ID), and then says: Two implementations will interoperate only if each can generate a type of ID acceptable to the other. To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types. IPv6-capable implementations MUST additionally be configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR. What does "Implementations SHOULD be capable of generating and accepting all of these types" mean? It can't mean the four just listed, because that list of four comes with MUSTs. If it means all the listed types, the sentence should be changed to "Implementations SHOULD also be capable of generating ID_IPV6_ADDR, ID_DER_ASN1_DN, and ID_DER_ASN1_GN." --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
