draft-ietf-ipsec-spicy-manual-pki-00.txt

[Greg Carter <[e-mail]>]

I was asked to post this...


Network Working Group                                      Geek Spice,
Bitter Spice
INTERNET-DRAFT                                             SpiceWorld
Systems
draft-ietf-ipsec-spicy-manual-pki-00.txt                April 1, 1998


      The Simple Public Key Infrastructure And Certificate Exchange
                  <draft-ietf-ipsec-spicy-manual-pki-00.txt>

Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and working groups.  Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inapproporiate to use Internet Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Australia), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited. This draft will expire six
   months prior  to date of issue.


1. Abstract

   IPSEC mandates the use of manual keying for ESP and AH.  However with
the introduction of the scaleable key exchange mechanism, IKE
[Hawkins98], it has become necessary to define a scaleable process to
issue and manage certificates used by IPSEC devices during the IKE
exchange.  In keeping with the design goals of manual keying this
document outlines a minimum set of requirements for IPSEC devices which
wish to use X.509 certificates during IKE exchanges.  However current
'state of the art' will be ignored, as well as any work done in other
IETF working groups, specifically PKIX.  Instead we will focus on 1993
technology, specifically PKCS#10.

2. Introduction

Before an IPSEC device can acquire a certificate it must establish trust
in the Certification Authority.  To do this all IPSEC devices will hard
code the root public key of a well known CA.  We believe this to be a
Veri, Veri good idea.  This will enable implicit trust throughout the
Internet, interoperability will be greatly improved, and users will not
have to worry about things like where the points of trust are in their
network.

Roll over of  the root key will take place in 4 year increments, with
each update occurring in a leap year on the date of April 1.  In order
to make this transparent to end users, IPSEC vendors are required to
release new versions of their OS's on theses dates.  Embedded in the OS
will be the root key.  This way the roll over occurs without the
knowledge of the end users and looks like any other OS update.  Hence
automated key roll over is supported.  Root key compromise is not
addressed in this document.
Since IKE allows us to do away with manual keying at the IPSEC layer we
have decided that the PKI used with IKE MUST support manual certificate
management.  We see this as the best solution, since we avoid the
hassles of automated protocols and scaleable architectures, at the same
time we can satisfy the needs of those who originally opted for manual
keying infrastructures for IPSEC.  They will be excited to know that
they can continue to manually manage their public keys instead of their
session keys.  If an automated system were in place we would predict a
10% decrease in IT positions, now using manual public key
infrastructures we expect an increase of 5%!.  LDAP is not used, instead
CRLs are moved by floppy to the IPSEC devices at 1 hour time intervals,
key  updates are not automated, instead the process outlined in this
document is repeated.  However this process maybe covered by patent.


Unlike other IETF specification, this document does not specify any
'over the wire' protocol.  Instead the manual process is considered to
occur all out of band.  The protocol maybe operated over transport
protocols, however end to end integrity is not provided, since PKCS10
only specifies how to format a request, not how to securely transport
that request to a CA (or how to establish trust in that CA).  Although
some have suggested that IPSEC be used to secure this transaction, we
think this is an excellent idea! We can bootstrap IPSEC by using IPSEC!

To summarize all IPSEC compliant CA's MUST support PKCS#10 requests
received from IPSEC devices by some out of band means.  All IPSEC
devices MUST support a common root key so that a single point of trust
is available throughout the Internet. However IPSEC devices MUST support
multiple root keys, this has the excellent security feature of allowing
end entities to pick and choose who they trust, instead of the trust
being administered from a centrally managed entity (such as an
organization's CA).  This has many benefits in the corporate world where
organizations are always looking for new ways to decentralize management
of users.

Acknowledgments

Unfortunately much of this document was written without the knowledge of
Bitter Spice.  However it includes many of the design ideals originally
expressed by Bitter Spice to me over shoots of tequila.   Bitter Spice
has moved on, with the recent conviction of the Montana Freedom Fighters
Bitter has packed up his computer and arsenal of assault rifles and
headed to foot hills of Montana to continue the fight.  One of his first
projects is to modify the existing Free SWAN code to support the SPICE
protocol.  Bitter Spice, the first crypto warrior!  

The slack is being picked up by Extranet Spice who has left his role as
Marketing Technologist to work in the  IETF standards group. 

Security Considerations

This document specifies a means to obtain certificates, by definition
there are not security considerations.

Geek & Bitter Spice                     Expired 6 months  Ago
[Page 1]

INTERNET DRAFT                 SPICE              April 1, 1998

----
Greg Carter, Entrust Technologies
[e-mail]