Hi Tero, Valery,
As much as it would be fun to discuss the conformance criteria (personally I
agree that they are too stringent, and would become even less relevant if we
add things like password-based auth), it is out of scope of the IKEv2-bis
discussion. Referring to the guidelines we agreed upon,
http://www.ietf.org/mail-archive/web/ipsec/current/msg02958.html, the goal of
this document is to *clarify* RFC 4306, not to change any normative language.
Thanks,
Yaron
> -----Original Message-----
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> Of Tero Kivinen
> Sent: Tuesday, January 26, 2010 11:16
> To: Valery Smyslov
> Cc: ipsec@ietf.org
> Subject: [IPsec] IKEv2-bis, conformance requirements
>
> Valery Smyslov writes:
> > Section 4 lists conformance requirements for IKEv2 implementations.
> >
> > First, the following text:
> >
> > Every implementation MUST be capable of doing four-message
> > IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for
> IKE,
> > one for ESP or AH).
> >
> > is formally incorrect, because IKE_AUTH results in two child SAs -
> > one in each direction. Moreover, AH support is purely optional, so
> > why is it here? I suggest to rephrase:
> >
> > Every implementation MUST be capable of doing four-message
> > IKE_SA_INIT and IKE_AUTH exchanges establishing one SA for IKE,
> > and a pair SAs for ESP.
>
> This change looks good to me.
>
> > Then, paragraphs:
> >
> > A minimal IPv4 responder implementation will ignore the contents
> of
> > the CP payload except to determine that it includes an
> > INTERNAL_IP4_ADDRESS attribute and will respond with the address
> and
> > other related attributes regardless of whether the initiator
> > requested them.
> >
> > A minimal IPv4 initiator will generate a CP payload containing
> only
> > an INTERNAL_IP4_ADDRESS attribute and will parse the response
> > ignoring attributes it does not know how to use.
> >
> > seem just to repeat what is said in previous paragraph. I suggest to
> > remove them.
>
> Yes, they just repeat what could be also seen from the generic text,
> but they do agree on the same thing and I think they clarify (at least
> a bit) what are the minimal requirements.
>
> > And last (but not least). THe following requrements:
> >
> > 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.
> >
> > suggest that every implementation MUST support both RSA PKIX
> certificates
> > and preshared key. Isn't it too strong requirement?
> >
> > 1. Why to pay so much attention to "minimal IKEv2 implementation"
> > lacking some not-so-difficult-to-implement functions, if we still
> > require it to have full PKIX support? I see no logic here.
> > PKIX support requires quite a lot of code and resources, so
> making
> > "IPsec garage opener" becomes problematic.
> >
> > 2. Some implementations may have pluggable crypto modules (or use
> > external tokens for authentication), so it may not have RSA at
> > all, while having all public key authentication support for
> > other algorithms. Or implementation may elect not to support
> > 1024 bits RSA keys as not so strong. Do such implementations
> > become non-conformant?
> >
> >
> > Is it possible to lower those requirements from MUST to SHOULD?
>
> We need at least one "MUST to implement" authentication methods, so we
> know two complient implementations can talk to each other. Selecting
> Shared key authentication would put the limit too low. On the other
> hand I agree that full PKIX Certificates support puts the rquirement
> bit too high.
>
> On the other hand, does it really matter that your garage door opener
> is conformant to the RFC4306 / IKEv2bis. Shouldn't it be enough to say
> that your garage door opener is implementing enough IKEv2bis that it
> can talk to the conformant IKEv2bis server implementation?
>
> If we want to set one mandatory to implement authentication method I
> think the some type of RSA keys is the logical choice. This would not
> care whether the RSA keys are in form of RAW RSA keys or whether they
> are in form of PKIX Certificate. You can always take the PKIX
> Certificate having RSA key and extract the RSA key from there and
> configure it to the system which only supports RAW RSA keys. Also you
> can take RAW RSA key and make self-signed certificate it using
> generally available tools, and if you configure that self-signed
> certificate as trusted in your system with suitable ID data, then
> other end can use the raw rsa keys and you can use certificates.
>
> Anyways the certificates is mandatory to implement feature of RFC4306,
> and I think it should stay there, even when it makes some of those
> very minimal garage door openers not following the full spec as they
> might use raw rsa keys or even shared keys instead of certificates.
>
> For example section 3.6 also says:
>
> Implementations MUST be capable of being configured to send and
> accept up to four X.509 certificates in support of authentication,
> and also MUST be capable of being configured to send and accept the
> two Hash and URL formats (with HTTP URLs).
> --
> kivi...@iki.fi
> _______________________________________________
> 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
