[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEV2: Issue #4 Revised Identity (fwd)



Hmm.. looks like my email never made it to the list, so let's resend with
better luck.

---------- Forwarded message ----------
Date: Wed, 12 Feb 2003 14:36:51 +0100 (CET)
From: Pekka Riikonen <priikone@xxxxxx>
To: Theodore Ts'o <tytso@xxxxxxx>
Cc: ipsec@xxxxxxxxxxxxxxxxx
Subject: Re: IKEV2: Issue #4 Revised Identity


The revised identity can solve the problem of defining what the ID
actually is and when not to send certificates.  However, having read the
draft it is in my opinion clear that same features can be accomplished
without introducing new payloads, but using the Certificate Request (CR)
payload, and revising the specification for this payload.  The name
Certificate Request payload already implies or could be made to imply that
if sent, a certificate is requested, otherwise not.

Some scenarios (-> initiator, <- responder):

- I don't have remote cert
	-> send CR with the CA
	<- send cert

- I don't have remote cert and I don't know the CA (or don't care, ie.
  I just want to get your cert)
	-> send empty CR, indicating send all certs, any cert,
	   or what ever cert you are about to use with me
	<- send all, any or local policy dictated cert

- I have a cert for remote
	-> do not send CR at all
	<- do not send cert

It would be nice to be able to say that "I have _this_ cert cached, is
that ok?".  This could be done with CR payload as well, if it is revised
so that it can include the subject (or hash) of an end entity cert (by
adding new encoding type).  If it matches no cert is sent back, otherwise
local policy can rule, which then tells that cert cache must be updated.

What is nice about revised identity draft (as opposed to pki-profile) is
that it allows the use of URL to tell where the cert is available.  This
too could be done by revising the Certificate payload by adding new
encoding types (like URL) if this feature is really needed.

All this would require revising the specs for CR payload handling, and
addition of new Certificate Encoding types.  The benefits is that no new
payloads are introduced, the use of CR payload is made explicit, new
encoding types are easy to add, and the verification of whether the cached
cert is correct or not can be done.  Whether or not changing/adding this
sort of thing would be acceptable, I don't know. :)

	Pekka
___________________________________________________________________________
 Pekka Riikonen                    | Email: priikone@xxxxxx
 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