Internet Draft                                   Editor: Paul Hoffman
draft-ietf-ipsec-revised-identity-00.txt               VPN Consortium
April 30, 2002
Expires in six months


               Revised Use of Identity in Successors to IKE

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.


Abstract

There is an opportunity in successor-to-IKE to fix 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. This proposal covers both
topics at once because it turns out that they are related.


. Introduction

The discussion in this document is for the successor-to-IKE proposals.
It does not use the certificate, certificate request, or ID payloads
from IKEv1 [IKEV1].

This proposal could work in either IKEv2 [IKEV2] or JFK [JFK]. In this
document, the message numbers refer to either the four-message version
of IKEv2 or JFK.

In this document, the key words "MAY", "MUST,  "MUST  NOT",  "SHOULD",
and  "SHOULD  NOT", are to be interpreted as described in [RFC2119].


. New payloads for messages 1 and 2

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.


. New payloads for messages 3 and 4

Messages 3 and 4 MUST include exactly one FullID payload. The payload's
format is an ID type followed by the content. The ID types are:

  PKIX certificate
A standalone PKIX certificate.

  Certificate bundle
A simple ASN.1 sequence of PKIX certificates. A bundle can have
end-entity certificates or certificate chains. 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
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
This is described in more detail below.

  PKIX keyIdentifier
Identifies a self-signed certificate that the receiver has already
pre-loaded. Note that this is only useful when using self-signed
certificates.

  IDForSharedSecret
This is only for use with shared secrets. It is an ASCII string (all
octets are 31 < x < 127) of any length.

3.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. Future versions of this document may add
requirements for how the named part looks. The URL can be to a
persistent repository, or it might be to the initiating machine (such as
in 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.

3.2 Using legacy authentication

FullID type 6 (IDForSharedSecret) indirectly supports non-certificate,
non-shared-secret authentication (commonly called "legacy
authentication") with IKEv2. The authentication system must create two
temporary tokens, one of which is used as the identity and the other is
used as the secret. The IKEv2 system must have some way of securely
querying the authentication system with the identity token and receiving
back the secret token.

As simple scenario is username-and-password. The IDForSharedSecret is
the username, and the key added to the HMAC is the password. When
receiving this message, the system looks up the password based on the
username, possibly using something like RADIUS.

A more complex scenario involves a hardware token that doesn't do public
key cryptography. Typically, the user does some challenge-response
exchange with the authenticating server and is then authenticated. At
that point, as long as the user has two pieces of authentication
information, they can use them in an HMAC. For systems that only return
one item (such as a long hash), there must be some agreement on how to
split that into two items, such as "80 bits for the IDForSharedSecret
and 80 bits for the secret". That can be done by the legacy
authentication vendor, possibly instantiated in an informational RFC.


. New error codes

The use of this proposal causes the need for additional error codes:

- Could not get your certificate through the URL you gave

- Could not get your certificate bundle through the URL you gave

- The certificate bundle was malformed

- Could not find the certificate that matches the keyIdentifier you gave

- Could not use your IDForSharedSecret


. 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.


. References

[IKEV1] "Internet Key Exchange (IKE)", RFC 2409

[IKEV2] "Proposal for the IKEv2 Protocol", draft-ietf-ipsec-ikev2

[JFK] "Just Fast Keying (JFK)", draft-ietf-ipsec-jfk

[PKIX] "Internet X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459

[RFC2119] "Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119


. Editor's Address

Paul Hoffman
VPN Consortium
 Segre Place
Santa Cruz, CA  95060 USA
paul.hoffman@vpnc.org