[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding revised identities to IKEv2
paul.hoffman@vpnc.org (Paul Hoffman / VPNC) writes:
> Greetings again. draft-ietf-ipsec-ikev2-03 adds some new functionality
> to IKEv2, but doesn't cover better use of identities and certificates.
> This idea got some support on the list a while ago, but it might have
> been hard for people to see how it would affect IKEv2. I propose the
> following changes to draft-ietf-ipsec-ikev2-03; do others agree?
The changes seems quite ok, but I think they are too complicated.
> PKIX certificate 1
> A standalone PKIX certificate.
> Certificate bundle 2
> A simple ASN.1 sequence of PKIX certificates. A bundle can have
> end-entity certificates and/or certificates from a chain to a
> root. The first certificate in the bundle is the sender's
> preferred identity certificate, but beyond that there is no
> meaning to the ordering.
Is there any need to have both? Isn't the PKIX certificate just
certificate bundle with one entry? Also I don't think simple ASN.1
sequence of PKIX certificate is good way to transmit bundles, better
use something like 16-bit length of certificate, certificate date,
16-bit length of certificate, certificate data.... (16-bits is enough
as the maximum payload length is 16-bits).
> Hash-and-URL of PKIX certificate 3
> The first 20 octets are the SHA-1 hash of a certificate; the
> rest is a URL that resolves to the certificate. This is
> described in more detail below.
> URL to a PKIX certificate bundle 4
> This is described in more detail below.
Same here, why both bundle and single certiicate. Also I would thing
instead of SHA-1 hash of the certificate it would be better to use
SHA-1 hash of the public key as used already in the trustedroot
payload. The other end doesn't really need a certificate it needs a
public key and it needs it to be trusted somehow. If used hash of the
public key, then the same method can be used to identify raw public
keys (with minimal asn.1 code to encode the public key to same format
used in pkix key identifier).
Also there might be multiple certificates for the same public key (old
certificate and new certificate) thus the url would return similar
bundle of certificates as in first section in all cases (i.e the first
certificate in the bundle would be the preferred identity
certificate).
> PKIX keyIdentifier 5
> Identifies a self-signed certificate that the receiver has
> already pre-loaded. Note that this is only useful when using
> self-signed certificates.
This would be redundant and better to use the keyidentifier + url
format above, but leave the url empty.
> For FullID types 3 and 4, the URL scheme must be "http", although it can
> be on any port number. The URL can be to a persistent repository, or it
> might be to the initiating machine (such as for a remote access client).
There should propably be note, here saying that if the initiator is
behind NAT then it cannot really use the url pointing to itself, as
the connection from the responder will not get through to the
initiator.
> If a system that is using certificates knows that it cannot resolve URLs
> (for example, because it is not yet on the Internet), it SHOULD use
> FullID types 1 and 2 in its IDAccepted payload. If a system can resolve
> URLs, it SHOULD use type 3 and 4 unless it is sure that it does not have
> the certificate of the other side, such as if it has just recovered from
> a crash and its cache is empty. All systems should be able to handle
> certificate bundles because the other party might have multiple
> identities which have different certificates.
With those modifications we would only have two different types of
FullID types for certificates, use type 1 if not connected to network
and type 2 if you are connected to network and can fetch urls.
One thing missing that was in the IKEv1 is the transfering of the
CRLs, but when considering the size of them it is better to leave them
out.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/