Subject: Re: IKEV2: Issue #4 Revised Identity

From: Pekka Riikonen <[email-masked]>
Date: Thu, 13 Feb 2003 08:31:59 +0100 (CET)

On Wed, 12 Feb 2003, Theodore Ts'o wrote:

: > The revised identity can solve the problem of defining what the ID
: > actually is and when not to send certificates.
:
: Well, the revised identity draft does solve the problem, essentially
: be eliminating the ID and CERT payloads altogether, conflating the
: IKEv1 concept of identity and certificate, and instead always
: requiring both sides to send a certificate, which *is* the identity.
:
The revised identity draft effectively creates same payloads but named
differently.  We already have those but only their definition has been
sloppy.  It would seem simple to just fix where we have gone wrong instead
of replacing them.  I know what I wrote is much the same pki-profile has,
except for the specific points I tried to make:

:    3.3.8.1. Specifying Certificate Authorities
:    Upon receipt of a CERTREQ where the Certificate Type is either "X.509
:    Certificate - Signature" or "X.509 Certificate - Key Exchange",
:    implementations MUST respond by sending each certificate in the chain
:    from the end entity certificate to the certificate whose Issuer Name
:    matches the name specified in the Certificate Authority field. Imple-
:    mentations MAY send other certificates from the chain.
:
: The IKEv1 interoperability problems arose because IKEv1 underspecified
: how the payloads should be used.
:
If the CA in CR is wrong, then it's probable that implementation will not
reply with any cert.  If you have never connected with remote, don't know
who it trusts, and only thing you want is to just probe (or connect
opportunisticly) to get the remote's cert so that you can make the
decision whether you trust it or not (say, ask it from user), would not
work since the IKEv2 (and pki-profile) says it's MUST NOT to send empty
CR.

For IKEv1 we agreed several times over the years that receiving empty CR
means sending all your local certs, or what ever your local policy happens
to dictate.  This is very good since it allows to get remote's certificate
regardless whether or not you know who it trusts, but the problem was that
it was never written down anywhere.  I'd like very much to see the MUST
NOT lifted from IKEv2 and specify that if empty CR is received the
receiver SHOULD send local cert(s).  The section 3.3.8.2 in pki-profile
"maybe or maybe not" allows this with "non-conformant"  implementations.
I think it should be either it's not allowed or it's allowed and it's
correct behavior.  Now it's like, "ok, you can't really do this, but, hey
if you do it work with it anyway"...

The second point was the ability to check whether cached cert is correct
or not.  This is very simple to do just by allowing the CR payload (by
adding new cert encoding type) to have the cert information (subject,
hash, what ever) in the CR data.  OTOH, same feature could work with
revised identity draft too (in either TrustedRoot or IDAccepted)...

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: [email-masked]
 SILC - http://silcnet.org/        | 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: Pekka Riikonen <[email-masked]>
Date: Fri, 14 Feb 2003 18:04:04 +0100 (CET)

: On 2/13/03 1:20 PM, "Pekka Riikonen" <[email-masked]> wrote:
: > One case is opportunistic IPSec, second is use of self-signed certs.
: > Assuming your friend has only a self-signed cert it would be nice to get
: > that cert in IKE so that you could cache it (and verify it, sign it, etc).
: >
: Ok, but could you be more specific about the self-signed cert
: (in the non-opportunistic case)?  Either I already know about
: your certificate and trust it, or I don't and never will.
: If I already trust it, I don't need it.  If I don't trust
: it and never will, then I'm not going to do IKE with you.
:
You cannot think like "I already trust you, or never will", if the ability
to create the trust depends on ability of getting the certificate you want
to trust.  Since certificates are sent in IKE it would seem the logical
place to get the remote's certificate, verify it (ask it from user
perhaps), cache it, sign it perhaps with your self-signed cert and then
use that from that point on.  But if you never get it, or you rely it on
getting it through some external means then it's not working really well
in my opinion.  Certs are not pre-shared-keys so there's no need to
pre-share them, we can get them in IKE.

There's at least three cases with self-signed cert and they don't have to
relate to opportunistic crypto.  a) you have self-signed cert, and you
don't trust any CA, ie. you want to get the remote's cert so that you can
sign it and create the trust by that, b) your friend has only self-signed
cert and you want to connect to your friend, you need her certificate, c)
both of you have only self-signed certs and in order to ever create the
very first connection you need to create trust to each other, and this
could be done by verifying each others certs you receive in IKE.

If the CR never allows on getting anything else except certs issued by the
specific CA you send, then use of self-signed certs is not possible, or
you leave it to the fact that you must know the issuer name (subject name)
of the self-signed cert which by the nature of self-signed certs (the
possibility that new cert is created easily) may be difficult.

The analogy is the SSH keys; when you connect to SSH server for the very
first time you verify and cache the server key.  From that point on you
don't need to do that anymore.  Self-signed certs in IPSEC can work the
same way; you get it for the first connection and don't worry about it
after that point on.

This is why I'd like to see the CR payload's MUST NOT for empty CR lifted
instead of leaving a loophole which is there now: if your implementation
is broken (the "non-conformant") others SHOULD work with you anyway,
although previous sentence says it's a MUST NOT.  The way to go in my
opinion is to either disallow it entirely or allow empty CR payloads.  The
"non-conformant" is a relic from IKEv1 where this issue was never written
down although it was agreed on between vendors.

	Pekka