Re: IKEV2: Issue #4 Revised Identity

[Pekka Riikonen <priikone@iki.fi>]

: On 2/13/03 1:20 PM, "Pekka Riikonen" <priikone@iki.fi> 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
___________________________________________________________________________
 Pekka Riikonen                    | Email: priikone@iki.fi
 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