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 <kivi...@iki.fi> wrote: > Paul Hoffman writes: > > At 9:17 PM -0500 1/21/10, <black_da...@emc.com> 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
