[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-spicy-manual-pki-00.txt
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
greg.carter@entrust.com