Skip to main content

Client Certificate and Key Retrieval for IKE

Document Type Expired Internet-Draft (individual)
Expired & archived
Authors Steven M. Bellovin , Robert Moskowitz
Last updated 2000-02-16
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


(Insert justification, possibly copied wholesale from section 1.1 and maybe 2.1/2.2 of draft-kelly-ipsra-userauth-00.txt) We consider inadvisable to change IKE [RFC2409] to meet these needs. IKE is a complex protocol; adding more features to it is a bad idea. Instead, we propose a layered approach: use standard IKE, with certificates, but provide a simple mechanism to provide clients with keys and certificates. A number of objections have been raised to using certificates. The most important is that we lack a public key infrastructure (PKI). We do not agree that this is an obstacle. Our proposal provides a simple mechanism for certificate generation and retrieval, while still relying on legacy authentication infrastructures. Furthermore, we provide for an easy migration path to certificate use once organizational PKIs are deployed. Our purpose at this point is not to present a firm protocol. Rather, we sketch several ideas for what such a protocol could look like. Final details can be determined if and when the working group opts for this path. In the interests of simplicity, we have chosen to reuse standard protocols and components. In particular, we use HTTP [RFC2616] for transport, HTML [RFC1866] as a data representation and TLS [RFC2246] for confidentiality. However, we do not mandate (or even necessarily encourage) use of a actual Web browser for certificate retrieval. As an alternative, we present a transient shared secret generation mechanism for IKE.


Steven M. Bellovin
Robert Moskowitz

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)