Client Certificate and Key Retrieval for IKE
draft-bellovin-ipsra-getcert-00

Document Type Expired Internet-Draft (individual)
Last updated 2000-02-16
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-bellovin-ipsra-getcert-00.txt

Abstract

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

Authors

Steven Bellovin (smb@cs.columbia.edu)
Robert Moskowitz (rgm@icsa.net)

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