Subject: [IPsec] Issue #156: SHOULD generate and accept which types?

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 17:49:12 -0800

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

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 21:17:13 -0500

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: [email-masked] [mailto:[email-masked]] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 Jan 2010 19:48:27 -0800

>Which I think amounts to a SHOULD for certificate support.  Is there a

This interpretation is quite surprising to me (but I am surprised often these days...). What do others think?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 22 Jan 2010 09:56:12 +0300

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 22 Jan 2010 10:00:09 +0300

> Which I think amounts to a SHOULD for certificate support.  Is there a

It is already there :-) See section 4 (Conformance Requirements):

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 22 Jan 2010 11:54:07 +0200

Paul Hoffman writes:
> 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  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.
-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Fri, 22 Jan 2010 16:04:44 +0530

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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 22 Jan 2010 13:45:46 +0200

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

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

-- 
[email-masked]

---

From: Raj Singh <[email-masked]>
Date: Fri, 22 Jan 2010 18:44:42 +0530

> it just lists which ID types there are which of them needs to be

Agree. But it should mandate ID_DER_ASN1_DN which it doesn't.
> 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:
   ---------------

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 22 Jan 2010 17:05:01 +0300

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

---

From: <[email-masked]>
Date: Tue, 26 Jan 2010 11:27:49 +0100

> Isnt't it too strong requirement?
<snip>

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)

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 26 Jan 2010 15:38:17 +0300

Hi Pasi,

> garage door openers), I would propose *not* re-visiting this 

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.