[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Adding revised identities to IKEv2
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?
----------
In section 3, change the format of the four messages.
Change message 1 from:
HDR, SAi1, KEi, Ni
to:
HDR, SAi1, KEi, Ni, IDAccepted [, TrustedRoot]
Change message 2 from:
HDR, SAr1, KEr, Nr, [CERTREQ]
to:
HDR, SAr1, KEr, Nr, IDAccepted [, TrustedRoot]
Change message 3 from:
HDR, SAi1, KEi, Ni, Nr,
SK {IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, SAi2, TSi, TSr}
to:
HDR, SAi1, KEi, Ni, Nr,
SK {FullID, IDAccepted, [IDr,]
AUTH, SAi2, TSi, TSr}
Change message 4 from:
HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
to:
HDR, SK {FullID, IDAccepted, AUTH,
SAr2, TSi, TSr}
----------
At the end of section 3.1, add:
In order to prevent a downgrade attack (where the attacker elides
identity types from an IDAccepted payload that the attacker cannot
spoof), messages 3 contains an exact copy of the IDAccepted payload from
message 2, and Message 4 contains an exact copy of the IDAccepted
payload from message 1. The IDAccepted payload in message 3 MUST be an
exact copy of the IDAceepted payload from message 2. The IDAccepted
payload in message 4 MUST be an exact copy of the IDAceepted payload
from message 1.
----------
In section 4.15 (Authentication of the IKE-SA), remove the first
sentence of the third paragraph ("Optionally, message 3...").
----------
Add a new section 4.16, and bump the numbers of the rest of the
subsections in section 4.
4.16 Identities and certificates
IKEv2 fixes two major problems that have plagued IKEv1: a
misunderstanding about what is identity, and having to send certificates
every time because you don't know if the other party already has your
certificate. The fix covers both topics at once because they are
related. In doing so, it removes the certificate, certificate request,
or ID payloads from IKEv1 and replaces them with the TrustedRoot,
IDAccepted, and FullID payloads, which have very different semantics.
Messages 1 and 2 MAY include a TrustedRoot payload. The TrustedRoot
payload includes a series of one or more PKIX [PKIX] keyIdentifiers of
roots trusted by the sender. This payload is completely optional and is
used only to inform the recipient of what capabilities the sender has.
Messages 1 and 2 MUST include exactly one IDAccepted payload. The
payload holds a series of one or more fields indicating the FullID types
that the sender will accept. The receiver MUST NOT send any FullID
payloads in messages 3 or 4 that are not listed in the sender's
IDAccepted payload. Messages 3 and 4 MUST include exactly one FullID
payload.
----------
Replace 5.5 (Identification Payload), 5.6 (Certificate Payload), and
5.7 (Certificate Request Payload) with the following three sections.
5.5 FullID Payload
The FullID Payload, denoted FullID in this memo, allows peers to
identify themselves to each other. 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Identification Data ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: FullID Payload Format
o ID Type (1 octet) - Specifies the type of Identification being
used.
o RESERVED - MUST be sent as zero; MUST be ignored.
o Identification Data (variable length) - Value, as indicated by
the Identification Type. The length of the Identification Data
is computed from the size in the ID payload header.
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.
5.5.1 Using URLs and caching certificates
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).
If a recipient uses FullID type 3, it might cache the certificate with
the hash as an index, or the certificate can be retrieved from the URL.
Of course, retrieving a certificate from a URL means many more round
trips before the key exchange protocol can finish. On the other hand, if
the certificate has been cached, no additional processing is needed and
the certificate does not need to be sent in the UDP-based protocol.
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.
5.6 IDAccepted Payload
The IDAccepted Payload, denoted IDAccepted in this memo, specifies
the FullID types that the sender allows the recipient to use.
The IDAccepted Payload is defined 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of IDs ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ < ID types > ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: IDAccepted Payload Format
o Number of IDs (1 octet) - This field indicates the number
of ID types in the payload.
o RESERVED - MUST be sent as zero; MUST be ignored.
Each additional octet is a unique FullID Type expressed as a single
octet.
The payload type for the Identification Payload is XXXX. ****This
should not be 6; that is, we should not re-use the payload number
from IKEv1's Certificate payload.*****
5.7 TrustedRoot Payload
The TrustedRoot Payload, denoted TrustedRoot in this memo,
provides a means to specify the root certificates that the sender
implicitly trusts.
The TrustedRoot Payload is defined 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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Num of keyIDs ! RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ <keyIdentifiers of roots> ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TrustedRoot Payload Format
o Number of keyIDs (1 octet) - This field indicates the number
of keyIdentifiers in the payload.
o RESERVED - MUST be sent as zero; MUST be ignored.
The rest of the payload is the
o keyIdentifiers (variable length) - Contains an keyIdentifiers
of certificates, concatenated. keyIdentifiers are SHA-1 hashes,
so each keyIdentifier is always 20 octets long. The structure and
semantics of keyIdentifiers are defined in [PKIX].
The payload type for the TrustedRoot Payload is XXXX. ****This
should not be 7; that is, we should not re-use the payload number
from IKEv1's Certificate Request payload.*****
----------
Additional notify messages for section 5.10.1:
CERT-NOT-FOUND-AT-URL 36
Could not get the certificate through the URL that was given in the
FullID type 3 payload. This could be due to connectivity problems,
an error from the HTTP server, a malformed URL, or a host of other
reasons.
CERT-BUNDLE-NOT-FOUND-AT-URL 37
Could not get the certificate bundle through the URL that was given
in the FullID type 4 payload. This could be due to connectivity
problems, an error from the HTTP server, a malformed URL, or a host
of other reasons.
MALFORMED-CERT-BUNDLE 38
The certificate bundle was malformed.
NO-CERT-MATCHES-KEYID 39
Could not find the certificate that matches the keyIdentifier in the
FullID type 5 payload.
ID-FOR-SHARED-SECRET-NOT-USABLE 40
Could not use the IDForSharedSecret in the FullID type 6 payload.
This could be due to the ID not being recognized, or it being
recognized but it resulted in an failed signature validation.
----------
Add the following to section 7 (Security Considerations):
Sending a TrustedRoot payload exposes information about the sender of
the payload to a passive attack. The attacker can determine
information about the sender, such as which roots the sender trusts.
For users in a corporate environment, the TrustedRoot payload may
reveal who the sender's employer.
An attacker snooping on a receiver can learn the identity of the
senders who use certificates that are not cached by the receiver by
watching the HTTP traffic generated from the receiver.
----------
Add the following to section 10 (References)
[PKIX] Housley, R., et. al., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3280, April 2002.
----------
--Paul Hoffman, Director
--VPN Consortium