[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Adding revised identities to IKEv2
-----BEGIN PGP SIGNED MESSAGE-----
{I'm sorry to take so long to reply to this thread. I have read the entire
thread, which has been on my todo for a long time}
I would like to amend the 5.5 section as follows. The goal here is to make
sure that the initiator can indicate to the responder which identity the
initiator thinks it is connecting to. This does not have a lot of relevance
to a typical VPN usage, but becomes critical when the responder is a multiuser
system, or a multi-identiy system. Any system that practices key rollover
where a new key may get published in advance of retiring the old key may
experience the problems of multi-identity.
I will preface this with two comments:
a) it might be that is makes sense to have two FullID-type payloads,
with differing type codes, but otherwise identical structure.
One for "Me", the other for "You"
b) we have explicitely included the public key used for signing
in the payload, in addition to either a certificate, or reference
to something that would authenticate the public key. This is so
that IKEv2 processing can continue *in parallel* with key
verification.
This is the "Me-Tarzan/You-Jane" (vs "Me-Tarzan/You-Sybil") proposal several
of us have been talking about.
Finally, if the key is not verified, but just accepted (according to some
policy that would permit this in certain situations), one has a form of
anonymous encryption that is possible. This may in fact be useful for use
by legacy authentication systems - in this context one would use the legacy
auth to authenticate the public keys rather than the DH exponents. This may
be easier to do - certainly, it is easier to *CACHE*, and therefore may make
rekeying of SAs that were established using a legacy auth more clear.
=====
5.5 FullID Payload
The FullID Payload, denoted FullID in this memo, allows peers to
identify themselves, and to indicate to whom they believe they are
speaking. The FullID Payload appears in messages 3 and 4, and names the
identity associated with the AUTH payload.
The FullID Payload consists of the IKE generic header followed by
identification fields as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! me-ID Type ! You-ID Type ! me-public key length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! me-ID length ! you-public key length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! algorithm ! !
+-+-+-+-+-+-+-+-+ +
~ Me-public key (RFC 3110/2536 format) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Me-Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! algorithm ! !
+-+-+-+-+-+-+-+-+ +
! !
~ You-public key (RFC 3110/2536 format) ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ You-Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FullID Payload Format
o Me/You ID Type (1 octet) - Specifies the type of Identification being
used.
o RESERVED - MUST be sent as zero; MUST be ignored.
o Me-public key length - the length in bytes of my public key section,
including the algorithm byte.
o Me-ID length - the length of the Me-Identification section.
o You-public key length - the length in bytes of the public key I expect
you to use, zero, if the initiator doesn't not know. The length
includes the algorithm byte.
o algorithm - as per section 3.2 of RFC2525 (or its successor)
o Me/You-public key. An RSA or DSA key, in RFC3110 or RFC2536 format.
(i.e. 1 byte for exponent size, that many bytes of exponent, and the
rest is modulus).
o Me/You-Identification Data (variable length) - Value, as indicated by
the Identification Type. The length of the You-Identification Data
is computed from the size in the ID payload header, subtracting the
other three field sizes.
The payload type for the Identification Payload is XXXX. ****This
should not be 5; that is, we should not re-use the payload number
from IKEv1's Identity payload.*****
The following table lists the assigned values for the FullID
Type field, followed by a description of the Identification Data
which follows:
The payload's format is an ID type followed by the content. The ID types are:
ID Type Value
------- -----
RESERVED 0
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.
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.
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.
IDForSharedSecret 6
This is only for use with shared secrets. It is an ASCII
string (all octets are 31 < x < 127) of any length.
DNS name 7
A fully qualified DNS name at which an IPSECKEY record will be
found. DNSSEC will authenticate the data. If the length of this
field is zero, then the value found in the Identity payload is used
if appropriate. (i.e. it must be ID_FQDN, ID_RFC822_ADDR,
ID_IPV4_ADDR, or ID_IPV6_ADDR. ID_RFC822_ADDR is converted to a
domain by converting the @ to a period)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBPgzuC4qHRg3pndX9AQEH7gP/Z3fnJF57atzcaKA6pR1lorRdLYximzrT
fzXYDOeZmdUIs18F4etzZQc7TAPVXgBQo56G2kXyQknUdVROrSIa8kjo35iPXJGo
l4j75yEFMpbVtdgltCPl9v3gxmselCAdtJn2q0zlUGNV3kmjnBHdGIL1uxq8TZaN
PS4ASYtEM1Q=
=Nifj
-----END PGP SIGNATURE-----