Subject: [IPsec] IKEv2-bis, conformance requirements

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 26 Jan 2010 10:53:31 +0300

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.  

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.

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?

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 26 Jan 2010 11:15:44 +0200

Valery Smyslov writes:
> 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:
> 

This change looks good to me.

> seem just to repeat what is said in previous paragraph. I suggest to

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. 

> 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?
> 
> 

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).  
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 26 Jan 2010 12:13:34 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tero Kivinen
> Sent: Tuesday, January 26, 2010 11:16
> To: Valery Smyslov
> Cc: [email-masked]
> Subject: [IPsec] IKEv2-bis, conformance requirements
> 
> Valery Smyslov writes:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 26 Jan 2010 14:55:50 +0300

Hi Tero, 

> a bit) what are the minimal requirements. 

Then, probably similar paragraphs about minimal IPv6 initiator
and responder behaviour should be added? Otherwise it looks a bit 
out of logic to me: either remove this paragraphs or treat IPv4 and IPv6 equally
and describe IPv6 implementation behaviour to the same extent.

Regards,
Valery Smyslov.