Client Certificate and Key Retrieval for IKE
draft-ietf-ipsra-getcert-00
Document | Type |
Expired Internet-Draft
(ipsra WG)
Expired & archived
|
|
---|---|---|---|
Authors | Steven M. Bellovin , Robert Moskowitz | ||
Last updated | 2000-11-16 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Expired | |
Consensus boilerplate | Unknown | ||
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:
Abstract
IKE was designed for use with certificates. In a remote access scenario, that implies that clients must possess their own certificates. We leverage off of work already done to fast-start certificate use with IPsec via the Simple Certificate Enrollment Protocol [SCEP]. We use only parts of SCEP over a client authenticated TLS/HTTP connection to a CA. By using TLS, the client can trust a CA root certificate it receives, without an out-of-band verification and the CA can perform automatic enrollment. We replace the out-of-band client identification process for a certificate enrollment with a legacy authentication, like RADIUS. Further, since the certificates issued here are short-lived, there is no need to support client-based revocation or rekeying. Also, there is typically no need for CRL support.
Authors
Steven M. Bellovin
Robert Moskowitz
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)