90 likes | 199 Vues
The IPSRA GETCERT initiative aims to establish a standardized mechanism for human user authentication to IPSec devices running IKE using existing legacy authentication methods. The Working Group prioritizes mechanisms that do not alter AH, ESP, or IKE protocols. The approach involves leveraging SSL/TLS with existing HTTP/HTML authentication syntax, enabling client-side key pair generation. Using the SCEP protocol, clients can efficiently request and obtain certificates from a CA while ensuring authorization through legacy back-end servers like RADIUS. This framework is designed for seamless integration with existing web technologies.
E N D
IPSRA GET CERT Dec 12, 2000 Robert Moskowitz rgm@icsa.net Steve Bellovin smb@research.att.com
IPSRA Goals • to define a standard mechanism to accomplish human user authentication to an IPSec device running IKE, using legacy authentication mechanisms • “The WG strongly prefers mechanisms that require no changes to AH, ESP or IKE protocols.” • --The IPSRA Charter
GETCERT Goals • To accomplish our objectives without touching or using IKE. • To build on existing tools and protocols. • Almost identical to part of a full-scale certificate-issuing service, so we decided to steal one. • Client-side key pair generation. • To produce a standards-track RFC. • Previous Internet-Draft introduce concept.
APPROACH • Use SSL/TLS • Use existing HTTP and HTML authentication syntax. • AUTHORIZATION LINE • Legacy back-end authorization servers • RADIUS • SCEP certificate request syntax • PKCS 10 (with PKCS 9.14) and PKCS 7 • Thus could be done with • A web browser with plugin or java applet • APACHE server with CGI program
PROCESS FLOW • The client establishes a TLS secured HTTP connection to the CA service. • The client authenticates the server certificate. The subject is the desired server. • The client provides its authentication over this connection. • The client requests via SCEP the CA root certificate. • Note: The server certificate might be a commercial SSL certificate. This way the client might be expected to have that certificate's signing certificate for validation.
PROCESS FLOW Cont. • The client requests a certificate via SCEP. • The server sends the certificate via SCEP after validating the request against the RADIUS database information. • The client uses the issued certificate in its IKE negotiation with a gateway.
ISSUES • SCEP is not Standards track in PKIX • Full copy of appropriate SCEP syntax • GETCERT ver 2 can use CMP ir or corresponding CMC transaction • SCEP has serious limitations • Do not apply in the limited GETCERT framework • No need for revocation or rekeying • TLS pathway provides implicit trust of root cert • Lots of round trips • TLS, AUTHORIZATION, CA and CERT REQUEST • Web users barely notice this sort of overhead in typical surfing
Why SCEP and not CMP or CMC • CMP and CMC standards track in PKIX • CMP interoperability established (use IR) • CMC code to emerge shortly (use pKIRequest) • But SCEP deployed • Reference code? • Simple PKCS 10 and 7 in client • Open SSL and Cryptlib can provide CGI code • SCEP well bounded with GETCERT • Certs short-lived • Typically no CRLs