Subject: Re: The CR payload still

From: Pekka Riikonen <[email-masked]>
Date: Mon, 3 Mar 2003 10:33:34 +0100 (CET)

On Wed, 26 Feb 2003, Pekka Riikonen wrote:

: : explicit specifications about when the CERT and CERTREQ packets much
: : be sent and how they should be handled, the addition of crypto suites,
: :
: I would still raise the issue of CR payload usage I mentioned a while
: back.  The ability for initiator to request 'any' cert from responder
: (regardless of the CA) would be in my opinion important to have.  The way
: specs seems to suggest implementation to work is that CERT is not sent if
: CERTREQ is not sent, if CERTREQ was sent but no such CA was found CERT is
: still not sent.  This means that you must know the CA before hand or you
: must have the cert cached for the exchange to ever succeed (since you
: won't have the public key to verify the AUTH).  Now, maybe in ideal world
: everyone always know who everyone else trusts or everybody trusts always
: the same CAs but I think in real world this won't be the case.
:
: The way in IKEv1 this was done was to unofficially agree between vendors
: (eg. in every bakeoff for past several years I've attended to) that empty
: CR payload means kind of "any" request.  IKEv2 does not allow this, but
: pki-profile provides a loophole for it anyway.  What I am suggesting is
: that empty CR payloads would be allowed in IKEv2 (explicitly), or by some
: other mechanism (eg. ANY cert encoding (but I don't like this very much)).
:
Ted, to your call for people to write the text for their ideas, I shall
reply to my own email with the text for this CERTREQ. :)

It says,

   Empty (zero length) CA names MUST NOT be generated and SHOULD be
   ignorred.

should be removed and later to say something like this,

   If empty CERTREQ payload is received the sender indicates that it does
   not require any specific certificate or certificate chain, but it may
   accept any certificate.  If so the processor SHOULD send its local
   certificate or certificate chain it is going to use in the negotiation.
   The sender of this payload will later decide whether it will trust the
   certificate (by perhaps prompting first a human operator).

or something like that...

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: [email-masked]
 SSH Communications Security Corp. | http://iki.fi/priikone/
 Tel. +358 (0)40 580 6673          | Snellmanninkatu 34 A 15, 70100 Kuopio
 PGP KeyID A924ED4F: http://iki.fi/~priikone/pubkey.asc

---

From: Brian Korver <[email-masked]>
Date: Mon, 03 Mar 2003 17:48:37 -0800

> or something like that...

Pekka,

I understand what you are advocating and I am sympathetic to
opportunistic IPsec, but I don't think the zero-length CERTREQ
payloads should be permitted in the non-opportunistic case
because they do not make sense in any other context.

- brian
[email-masked]

---

From: [email-masked]
Date: Tue, 4 Mar 2003 22:28:02 -0500

I think I'm hearing variations on the following proposal:

An empty CERTREQ payload is requesting any certificate or certificate chain
the other side has without giving any hints as to what certificates are
preferred.

A missing CERTREQ payload is requesting that the other side not bother
sending any certificates.

When would an IKE implementation want to express the second request? I had
assumed that if CERTREQ was missing that the other side should send
whatever certificate it has, so an empty CERTREQ would just be a less
efficient encoding of the same request. I get the impression from this
discussion that IKEv1 had the two versions of the request as above. Were
they both used?

If someone has a use for requesting no certificates, I think this is a fine
way to encode it. But I'm reluctant to add a feature unless someone thinks
they need it.

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Mar 2003 13:54:09 -0500

>>>>> "Charlie" == Charlie Kaufman <[email-masked]> writes:
    Charlie> An empty CERTREQ payload is requesting any certificate or
    Charlie> certificate chain the other side has without giving any hints as
    Charlie> to what certificates are preferred.

    Charlie> A missing CERTREQ payload is requesting that the other side not
    Charlie> bother sending any certificates.

    Charlie> When would an IKE implementation want to express the second
    Charlie> request? I had assumed that if CERTREQ was missing that the

  1) when it isn't using certificates
  2) when it already has, preconfigured the right things

    Charlie> If someone has a use for requesting no certificates, I think
    Charlie> this is a fine way to encode it. But I'm reluctant to add a
    Charlie> feature unless someone thinks they need it.

  Charlie, you seem to have fallen into the trap of making IKEv2 depend
way too heavily upon PKIX. 

  There is significant deployment of RSA keys that does not use that stuff.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Brian Korver <[email-masked]>
Date: Wed, 05 Mar 2003 11:07:04 -0800

> certainly don't reflect those of any other entity (legal or otherwise).

Carlie,

As you point out, no CERTREQ means "don't bother to send any CERTs",
but the question remains as to what an empty CERTREQ means.  ISAKMP
states that an empty CERTREQ means "send any CERTs you want, I don't
care".

Except for the case of opportunistic IPsec, I don't see the point
of telling your peer "I don't care".  Therefore, I agree that an empty
CERTREQ should be prohibited in IKEv2, especially because it creates an
interoperability rat hole.

- brian
[email-masked]

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 5 Mar 2003 13:31:48 -0800

At 11:07 AM -0800 3/5/03, Brian Korver wrote:
>of telling your peer "I don't care".

There are other meanings than "I don't care". We need to be able to 
say "send me a cert of type other than 4", namely types 11, 12, and 
13. Currently, we can't specify that.

>   Therefore, I agree that an empty

It won't do that if we scope it correctly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 5 Mar 2003 15:33:52 -0800

At 2:39 PM -0800 3/5/03, Brian Korver wrote:
>On 3/5/03 1:31 PM, "Paul Hoffman / VPNC" <[email-masked]> wrote:
>Paul,
>An empty CERTREQ still contains a cert type field.  The issue
>being discussed is the semantics of a missing CA field (in
>other words the CA's DN), not a missing cert type.

The document says:

    While intended to allow for future expansion, the only form of
    certificate request currently defined is X.509 signing certificate
    (4).

That's a pretty clear statement that other types are not covered by 
the CERTREQ.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 6 Mar 2003 11:42:50 +0300

> 13. Currently, we can't specify that.

Nor can we currently request a CRL(s). It's a pity, because either
it forces the other side to always send (probably huge) CRL(s), or leaves
us without critical revocation information in case we cannot get it from 
other sources.

> It won't do that if we scope it correctly.

Regards,
Valery Smyslov.

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 6 Mar 2003 11:00:06 +0100 (CET)

: At 11:07 AM -0800 3/5/03, Brian Korver wrote:
: >Except for the case of opportunistic IPsec, I don't see the point
: >of telling your peer "I don't care".
:
: There are other meanings than "I don't care". We need to be able to
: say "send me a cert of type other than 4", namely types 11, 12, and
: 13. Currently, we can't specify that.
:
If the IKEv2 document doesn't want to specify other usage for CERTREQ then
surely it is possible to write additional specifications for those other
types.

In fact, for an empty CERTREQ case whould there be any harm in saying:

   If empty CERTREQ payload is received the sender indicates that it does
   not require any specific certificate or certificate chain, but it may
   accept any certificate.  The Cert Encoding field indicates the type of
   certificate encoding sender is expecting.  If so the processor SHOULD
   send its local certificate or certificate chain of correct type it is
   going to use in the negotiation.  The sender of this payload will later
   decide whether it will trust the certificate (by perhaps prompting
   first a human operator).

By including multiple CERTREQs in exchange would allow request of multiple
different kind of certs and public keys.

	Pekka

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 6 Mar 2003 10:46:21 +0100 (CET)

: > Opinions expressed may not even be mine by the time you read them, and
: > certainly don't reflect those of any other entity (legal or otherwise).
:
: Carlie,
:
: As you point out, no CERTREQ means "don't bother to send any CERTs",
: but the question remains as to what an empty CERTREQ means.  ISAKMP
: states that an empty CERTREQ means "send any CERTs you want, I don't
: care".
:
: Except for the case of opportunistic IPsec, I don't see the point
: of telling your peer "I don't care".  Therefore, I agree that an empty
: CERTREQ should be prohibited in IKEv2, especially because it creates an
: interoperability rat hole.
:
I can respect that but I don't understand what is the interoperability
problem.  If it is stated explicitly there are no problems.  The current
one is bigger problem since pki-profile provides a loophole for this
(allowing empty CR's) and that will cause confusion unless that too is
fixed to include MUST NOT explicitly.

There is also other than "opportunistic crypto" cases.  You have to
remember that someone may not want to trust some CA just because it wants
to talk to you (it don't want to trust everybody).  Some implementation
may want to always use only self-signed certs and there are no CAs in this
case.  By not allowing "give me ANY cert you are using now" disallows the
use of self-signed certs in IKEv2, or rather you MAY receive it during
IKE, or may not.

	Pekka

---

From: Brian Korver <[email-masked]>
Date: Wed, 05 Mar 2003 14:39:18 -0800

Paul,

- brian
[email-masked]

---

From: Pekka Riikonen <[email-masked]>
Date: Thu, 6 Mar 2003 10:46:21 +0100 (CET)

Pekka

---

From: Francis Dupont <[email-masked]>
Date: Fri, 07 Mar 2003 15:11:21 +0100

In your previous mail you wrote:

=> I know cases where this (a way to request no certificate) is very useful
(i.e., it avoids fragmentation problems too) in the mobility context.
Today it is done by specific configuration but a standardized mechanism
is far better.

Thanks

[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Mon, 17 Mar 2003 10:02:58 -0800

Theodore Ts'o wrote:
> 
> Charlie Kaufman has released the next version of IKEv2
> (draft-ietf-ipsec-ikev2-05.txt) and we are slowly but surely getting
> closer to completion.  Many thanks to Charlie and those who
> contributed text, ideas, and bug fixes to this new version of the
> ikev2 I-D.
> 
> At the time when Charlie began his revisions to produce the 05 I-D,
> there were still a few open issues.  In the meantime, some additional
> issues have opened up, including the discussion between Tero, Francis,
> and Radia regarding address management and whether IKE v2 adequately
> handles NAT traversal (particularly in transport mode).  Furthermore,
> ikev2-05 has changed significantly and has much new material to
> address various concerns addressed by those on the list, including the
> addition of the agreed-upon handling of legacy authentication, more
> explicit specifications about when the CERT and CERTREQ packets much
> be sent and how they should be handled, the addition of crypto suites,
> and so on.
[snip]

Ted,

I have a couple of problems with the latest CERT and CERTREQ sections.

Sections 1.2 and 3.6:  "If multiple certificates are sent, the first
certificate MUST contain the public key used to sign the AUTH payload."
I've heard people ask for this from time to time, but as an implementor
I prefer the unordered "bucket of certificates" that we usually have.
What motivates this change from IKEv1?  Also, I worry that this new
rule means that it won't be possible to send 2 EE certificates, for
instance to handle expiration rollover.  

Section 3.7:  Why has the contents of the CERTREQ payload been changed
from sending the DN to the SHA-1 hash of public keys?  This wasn't broken
in IKEv1, so what motivates this change?  Yes, DNs are variable size, but
they're a lot more useful for debugging/diagnostics than SHA-1 hashes are.
I don't have any problem with adding an additional "hash" type, but let's
not remove our ability to requests certs by CA DN.

Section 3.7 (again):  We need to be able to request more than just
signature certificates, CRLs being the most obvious example.  This 
absolutely needs to be fixed.

-brian
[email-masked]