1 / 9

IPSRA GET CERT

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

leola
Download Presentation

IPSRA GET CERT

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPSRA GET CERT Dec 12, 2000 Robert Moskowitz rgm@icsa.net Steve Bellovin smb@research.att.com

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

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

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

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

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

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

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

  9. THANK YOU!

More Related