wdiff draft-ietf-ipsec-cdp-00.txt draft-ietf-ipsec-cdp-01.txt

- 1 -

IPSEC Working Group Ashar Aziz
INTERNET-DRAFT Tom Markson
Hemma Prafullchandra
Rich Skrenta
Sun Microsystems, Inc.

Germano Caronni
Swiss Federal Institute of
Technology

Expires in six months December 21, 1995 June 6, 1996

Certificate Discovery Protocol
<draft-ietf-ipsec-cdp-00.txt>
<draft-ietf-ipsec-cdp-01.txt>

Status of this Memo

This document is a submission to the IETF Internet Protocol Security
(IPSEC) Working Group. Comments are solicited and should be addressed to
to the working group mailing list (ipsec@ans.net) or to the authors.

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

Internet-Drafts draft documents are valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate 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 (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this memo is unlimited.

Abstract

Use of Public key cryptography is becoming widespread on the Internet in
such applications as electronic mail and IP Security (IPSEC).
Currently, however, a common public key certificate infrastructure does
not exist which is interoperable with other systems and ubiquitous. In
light of this, we describe a protocol which may be used to exchange or
retrieve certificates (essentially signed public keys) with or from
another entity. The protocol may be used to request certificates from a
directory/name server or from the entity who owns the certificate.

CONTENTS

Status of this Memo................................. 1

Abstract............................................ 2

1. Overview............................................ 3

2. The Certificate Discovery Protocol.................. 4

2.1 Clogging Defense............................... 5

2.1.1 Cookie Generation 5

3. Certificate Discovery Packet........................ 6

3.1 Certificate Discovery Header................... 6

3.2 Name Record.................................... 8

3.3 Certificate Record............................. 9

4. Assigned Numbers.................................... 10

4.1 Port Number Assignments........................ 10

4.2 Name Type Assignments.......................... 10

4.3 Certificate Type Assignments................... 10

5. Security Considerations............................. 11

Acknowledgements.................................... 11

References.......................................... 11

Author's Address(es)................................ 12

- i -

1. Overview

The distribution of authenticated public keys is a fundamental problem
which needs to be resolved with use of public key cryptography. Many
solutions exist for distributing authenticated public keys. Two of the
more common distribution methods are the X.500 directory service [1] and
Secure Domain Name System (Secure-DNS) [2]. Each method has a different
encoding format for the entity identity and the public key that belongs
to it. It is expected that many distribution mechanisms will co-exist on
the Internet and hence many "certificate" formats.

We describe a protocol which may be used to exchange certificates on the
Internet. The protocol has the advantage that it does not require
changes to existing services or deployment of large directory services
in order to be used. The Certificate Discovery Protocol allows
certificate requests to be made to any arbitrary IP-node. This feature
allows the initiator to send requests to, say, an IP-node which is
acting as a certificate server (and hence would have many certificates
stored in its local certificate database) or to a single IP-node which
only has it's own certificate.

As noted earlier, there are several different types of certificates in
existence: X.509 certificates [11], PGP certificates [3], Secure DNS
resource records and hashed public keys [4]. This protocol is designed
to support all of these and new ones as they emerge.

All certificates have

A Certificate has at least two properties:

(1) it provides for a cryptographic binding to a name/identity of an
entity, and
(2) it provides integrity protection of a public key.

The name may be encoded in the certificate (for example, as in X.509 and
PGP certificates) or it may be implicit in the public key itself (i.e.,
the cryptographic hash of the public key).

As with various certificate types, numerous naming conventions exist on
the Internet, for example, IP addresses [5],[6], RFC 822 addresses [7],
DNS names and PGP user names. This protocol attempts to support all of
these and allows for other syntaxes.

Note, that a particular entity may have more than one certificate. An
entity may have the same public value in different certificate formats,
or have multiple public values each in a separate certificate or have
the same public value certified by different Certifying Authorities, and
so on. In all these possible certificates the identity of the entity
remains constant.

2. The Overview of the Certificate Discovery Protocol (CDP)

The Initiator Certificate Discovery protocol is the entity which a request/response protcocol used
by two parties to transfer certificates. The Requester initiates
Certificate Discovery. The Responder is defined as the entity which receives the Certificate Discovery initiate
message and (optionally) responds with certificates. responds.

All certificate discovery protocol communication uses the User Datagram
Protocol (UDP) [8]. The Initiator requests certificates by Name. A Name is defined as a Name
Record consisting of requester binds to a Name Type, random port and sends a Name Length
request to port cert-responder. The port assignment is described later.
The responder has bound to port cert-responder and sends the actual Name of response to
the entity who random port on which the certificate belongs to. The Name Type specifies requester sent the
type request.

The CDP consists of name, for example, two parts: a PGP printable string Certificate Discovery Header and zero
or a SKIP [12] name.
In the case where the Name Type is SKIP, more CDP records. The CDP header contains global status and the actual name consists
number of a
Name Space Identifier (NSID) followed by the Master KeyID (MKID).

The Initiator may optionally include certificates CDP records present in an initiate the message. The Responder A CDP header MUST process any certificate(s) the Initiator
has sent and respond with the requested certificates be
present in a CDP. One CDP record is present for each "question" or an error (for
example,
"answer", if present.

The simplest example of CDP is the requested requester asking for a particular
certificate from the responder. The responder replies with that
certificate. If the responder does not exist or it had problems
processing have the certificates certificate the
requester asked for, it has received).

Note that this protocol allows will set the initiator to error status and not only return a
certificate. In this example, one CDP header and one CDP record would
be sent in both the request and the response.

A CDP message may be requests for all
certificates multiple certificates. The requester
will produce one CDP record for each certificate being requested. The
responder will reply with a particular "Name" but also send in set of CDP records containing certificates
or errors. It is important to note that if one CDP question generated
an error, the same message responder SHOULD still process all the certificates of the Initiator.

Also, other CDP
questions. Errors are generally handled in a request, the initiator CDP record per-
certificate level.

It is also important to note that questions and answers may simply give not
necessarily map one to one. For instance, the responder
certificates without asking for any in return. If requester may ask the
responder accepts
these certificates, for a certificate and receive multiple certificates as a
response. The request might contain one CDP record, but the response message will return a status
would contain one CDP record for EACH certificate returned.

The use of 'OK'.
If the responder does not accept all of these certificates, term requester is a bit will
be set indicating this error and confusing. Not only may the
requester request certificates from the responder, but it may also PUT
certificates to the responder. A PUT is an appropriate error status unsolicited presentation of
certificates from requester to responder. The responder will be
returned.

All certificate discovery protocol communication uses reply
with a status indicating whether the User Datagram
Protocol (UDP) [8]. PUT was successful.

The client binds to port cert-initiator and sends protocol supports a mixing of GETs and PUTs. The requester may
PUT it's certificate request to port cert-responder. Port number assignments are
described later. in the same CDP that he GETs the responders.

The responder binds to port cert-responder and sends MUST either indicate an error in the response to port cert-initiator.

Two separate ports are used to allow STATUS field of the
CDP header or generate at least one CDP record for multiple certificate requests each CDP record
present in a request. The response to be made without waiting for each request CDP record MUST have
the same name fields (name type, name len, Name) as the request. The
response to MAY simply be received, (that means,
one port is used an error if the responder chooses not to simply send requests out process
the request.

For example, if a requester asks for 5 certificates from the responder,
the request packet will contain the CDP header and 5 CDP records. In
the other port is used absence of an error in the header STATUS field, if the responder has
5 certificates to receive responses). return, the response packet will also contain 5 CDP
packets. If the responder only had 2 of the 5 certificates, it would
still contain 5 CDP records. Three of the CDP records would indicate an
error.

2.1 Clogging Defense

The Certificate Discovery Protocol allows an Initiator a requester to both make
certificate discovery requests (i.e. fetch), GET), as well present certificates
(i.e. push). This could lead to a situation where an
Initiator a requester may
attempt to clog a certificate server by flooding it with bogus
certificate pushes. The server, when presented with a set of
certificates would at a minimum parse the request and check if it
already has the presented certificates in its local database. It may
also have to verify a signature using a (possibly) expensive public key
operation. Rather than discarding certificate pushes when it feels
clogged, the server may request that the Initiator requester use the optional
cookie exchange mechanism. With this approach, the server may continue
to serve legitimate requests.

If the Responder requires a cookie, it will expect the Initiator requester to send
the cookie with the expected value. If the Initiator requester does not send this
cookie, the Responder SHOULD send a message with the "Cookie Required"
status and the desired cookie in the cookie field.

The protocol also supports a cookie the initiator may set. The
responder MUST send this cookie back to the initiator in a response.
This cookie may be used for replay protection, clogging defense or as a
means for the client to associate responses with requests.

If either the Initiator requester or the Responder is feeling clogged it SHOULD
give preference in calculating the shared secrets (i.e. g^ij)
computations to certificates sent to it with magic cookies. (For example, it
could precompute g^ij immediately upon receiving the certificate and
after verifying it.)

2.1.1 Cookie Generation

The cookie generation method is may be as recommended in the Photuris
Internet Draft [9], i.e., an MD5 [10] hash is applied over the IP Source
and IP Destination Addresses, the UDP source and destination ports, and
a locally generated secret random value. A subset of this hash is then
used as a cookie.

Note that this is an implementation detail in that the mechanism
employed is purely a local matter, two communicating entities do not
have to use the same mechanism.

3. Certificate Discovery Packet

The Certificate Discovery Protocol message consists of three two parts:

1) the certificate discovery header, Header (CDP header),
2) zero or more name record(s), and
3) zero or more certificate CDP record(s).

3.1 Certificate Discovery CDP Header

The following describes a certificate discovery header. All values
are in network order.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VERS |I|R|ACT|P| STATUS |#-OF-NAME-RECS |#-OF-CERT-RECS | ACTION/STATUS | #-OF-RECS | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Requester Cookie (if I bit is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Cookie (if R bit is set) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VERS indicates protocol version number, VERS = 1 for this protocol.

I bit indicates if a 32 bit Initiator Cookie is present (I=1) or not (I=0).
R bit indicates if a 32 bit Responder Cookie is present (R=1) or not (R=0).

ACT

Action/Status indicates the type of message. Possible values are:
1 (Initiate) - initiate either a request for certificate(s) or simply
send certificates.
2 (Response) - response to a certificate Initiate.

P bit in a response indicates whether the responder has rejected
certificates presented in the initiate message. If the responder has
accepted the certificates or if no certificates were present in the
initiate message, the responder MUST set the P bit to 0. If the responder has
NOT accepted ALL of the certificates present in the initiate message, the P bit
is set to 1 and the status field should indicate the reason for failure.
If the responder has rejected certificates in the initiator's request,
no certificates should be returned to the initiator and #-OF-CERT-RECS of a response.
It MUST be set to 0.

STATUS is used only in responses (i.e. ACTION = 2). It MUST be ignored the value REQUEST by the responder. Possible values are:

0 (OK) - initiator. The responder has processed the certificates sent
or has returned the requested certificates.
1 (Unknown Error) - An error has occurred.
2 (Unknown Name) - No certificates for
MUST set the requested "Name" can
be found in field to one of the local certificate database values RESPONSE, COOKIE_REQUIRED
or
the local domain name server.
3 (Unsupported Name Type) REQUEST_TOO_LARGE.

0 (REQUEST) - Name Type in the certificate request This Certificate discovery packet is
unsupported.
4 (Unsupported CERT-Type)
initiating CDP.

1 (RESPONSE) - CERT-Type in the certificate request This Certificate discovery packet is
unsupported.
5 (Cookie Required) a
response to a previous CDP initiate.

2 (COOKIE_REQUIRED) - Responder requires the initiator to resend this
request with a non-zero responder cookie.
This cookie included.
6 (Request Too Large) is present in the Responder Cookie
field.

3 (REQUEST_TOO_LARGE) - Request cannot be satisfied in one UDP packet
(64K). This may occur, for example, if the
initiator has asked for too many names listed certificates
in the
certificate initiate message. a request. If the initiator receives this
response then it SHOULD resend the request
with fewer names. queries. The responder,
however, SHOULD send as many certificates as
it can in the response.

#-OF-NAME-RECS

#-OF-RECS - The number of Name CDP Records present in the
initiate message. This field is only meaningful
in an initiate message. If the field is set to
0 in an initiation, the protocol functions
as a way of "pushing" certificates to a
remote host. A response should not have
any explicit Name Records, they should be a
part of the Certificate Record(s) and hence
#-OF-NAME-RECS should be set to 0.

#-OF-CERT-RECS - The number of Certificate Records present in the
initiate or response. present. If this
value is 0 then no
Certificate CDP Records are present in
the message.
If this field is zero in an initiate message, the
initiator is requesting certificates without
presenting any. If the

Reserved - This field is current reserved. It should be
set to zero in a
response, by the R bit sender and ignored by the STATUS field
indicate the status of the previous request.

Initiator
receiver.

Requester Cookie - This is an optional field and is not present
when the 'I' bit is set to zero. In an initiate a request message, this contains the a
value that the Responder should send back
in the Requester Cookie field of the response.

In a response message, this field contains MUST contain
the value that was sent by the initiator requester in this
field in the initiate message. This field
should be present in a response message
(and the I bit set) if the initiate message
has the 'I' bit set to 1. request.

Responder Cookie - This is an optional field and is not present
when the 'R' bit set to zero. In an initiate message, a request, this contains the value
that the Responder previously indicated should
be sent in the request. In a response message,
if the "Cookie Required" status is set, this
contains the value that should MUST be sent in a
new request. If the response message does requester has not have received
a cookie from the "Cookie Required" status, this
value SHOULD be not be present and responder, the 'R'
bit should be requester MUST
set this field to 0. be zero.

3.2 Name CDP Record

Following the Certificate Discovery header is one Name CDP record for each
name or certificate included in the initiate request message. A correctly formed
Certificate Discovery message MUST contain as many name CDP records as the #-OF-NAME-
RECS
#-OF-RECS field in the Certificate Discovery CDP header field specifies.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Action/Status | Name Type | Name Length | Name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERT-Type | CERT-Length | Certificate ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Action/Status - is used to indicate either the action that is requested
in a particular CDP record or the status of a response.
The initiator MUST treat this field as an action field.
The responder MUST treat this field as a status field.

Actions values are as follows:
1 GET
2 PUT

Status values are as follows:
100 GET SUCCEEDED
101 GET FAILED
102 PUT SUCCEEDED
103 PUT FAILED

Name Type - Identifies the type of the Name. The values of this
field will be assigned by the Internet Assigned Numbers
Authority (IANA).

Name Length - The length of the name in bytes.

Name - The name of the entity who owns the certificate for
which the request is being made.

3.3 Certificate Record

Following the Name Record(s) is one certificate record for each
certificate included in the protocol. A correctly formed Certificate
Discovery message MUST contain as many certificate records as the #-OF-
CERT-RECS field in the Certificate Discovery header This field specifies.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name Type | Name Length | Name ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CERT-Type | CERT-Length | Certificate ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Name Type, Name Length and Name are must be
the same size as specified in a name record.

CERT-Type Name Length.

Cert-Type - specifies the certificate type of the certificate that
is to follow. If no certificate is present, this field
is set to zero. These values will be assigned by IANA.

CERT-Length

Cert-Length - specifies the length of the certificate in bytes. If no
certificate is present, this field is set to 0.

Certificate - the actual certificate. This field must be the size that is
specified in the Cert-Length field.

4. Assigned Numbers

4.1 Port Number Assignments

IANA has assigned cert-responder UDP port 1639 to "cert-initiator". UDP port 1640 has
been assigned to "cert-responder". 1640.

4.2 Name Type Assignments

Name Type Value Name Type

1 SKIP
2 PGP Printable String
3 PGP KeyID
4 DNS name
5 RFC 822 name
6 X.509 Distinguished Name

Name Type values 1 through 6 are assigned as is described above. Name
Type values 7 through 249 inclusive are reserved to IANA for future
allocation as Assigned Numbers. Such future allocation by IANA will
normally require that a public specification exist for the Name Type
obtaining such allocation. Name Types in the range 250 through 255
inclusive are reserved for private use among consenting parties. Name
Types in the range 250 through 255 inclusive will hence only have local
uniqueness properties.

4.3 Certificate Type Assignments

CERT-Type Value Certificate Type

1 X.509 [1]
2 PGP [3]
3 Secure DNS [2]
4 MD5 of Unsigned DH Public Value [4]
5 MD5 of Unsigned Elliptic Curve Public Value
6 MD5 of Unsigned RSA Public Value
7 X509 Certificate Revocation List

CERT-Type values 1 through 6 are assigned as is described above. CERT-
Type values 7 through 249 inclusive are reserved to IANA for future
allocation as Assigned Numbers. Such future allocation by IANA will
normally require that a public specification exist for the Certificate
Type obtaining such allocation. CERT-Types in the range 250 through 255
inclusive are reserved for private use among consenting parties. CERT-
Types in the range 250 through 255 inclusive will hence only have local
uniqueness properties.

The Certificate Discovery Protocol uses two UDP ports to exchange
certificates. A request has been submitted to IANA for these port
assignments.

5. Security Considerations

A responder should use the cookie exchange mechanism when it feels
clogged. The Certificate Discovery Protocol uses two ports, we

We suggest that these the UDP ports used by the Certificate Discovery Protocol
be treated as a "by-pass" channel for encryption (i.e. non encrypted
traffic is permitted to be sent on these ports). As only certificates fetches/pushes
GETs/PUTs are satisfied on these ports the window for vulnerability is
limited.

Acknowledgements

We would like to thank all of the people who helped make this draft
possible.

Bill Danielson, Marc Dye and Ben Stoltz for reviewing this draft and
providing constructive suggestions.

Special thanks to Colin Plumb for his valuable suggestions and
contributions to this protocol.

Ran Atkinson suggested that this protocol should be independent of other
IPSEC drafts.

Phil Karn and Bill Simpson for their work on the Cookie Exchange scheme
for the Photuris Session Key Management Protocol which influenced the
addition of the Cookie field to this protocol.

Bill Danielson, Marc Dye, Colin Plumb, Rich Skrenta and Ben Stoltz for
reviewing this draft and providing constructive suggestions.

References

[1] CCITT Recommendation X.500 (1988), "The Directory"

[2] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D
draft-ietf-dnssec-secext-04.txt), Work In Progress

[3] Atkins, D., Stallings, W., Zimmerman, Zimmermann, P., "PGP Message Exchange
Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress

[4] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned
Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh-
00.txt), Work In Progress

[5] Postel, J., "Address Mappings", IEN 115, USC/Information Sciences
Institute, August 1979

[6] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture",
(I-D draft-ietf-ipngwg-addr-arch-03.txt), Work In Progress

[7] Crocker, D., "Standard for the format of ARPA Internet text
messages", RFC 822

[8] Postel, J., "User Datagram Protocol", RFC 768

[9] Karn, P., Simpson, W. A., "The Photuris Session Key Management
Protocol", (I-D draft-ietf-ipsec-photuris-08.txt), Work In Progress

[10] R. Rivest, "The MD5 Message Digest Algorithm", RFC 1321, April 1992

[11] CCITT Recommendation X.509 (1988), "The Directory - Authentication
Framework"

[12] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management
for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work In
Progress

Author's Address(es)
Ashar Aziz
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043

Email:
ashar.aziz@eng.sun.com
Alternate email address: ashar@incog.com

Tom Markson
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043

Email: markson@incog.com
Alternate email address:
markson@eng.sun.com

Hemma Prafullchandra
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043

Email:
hemma@eng.sun.com
Alternate email address: hemma@incog.com

Rich Skrenta
Sun Microsystems, Inc.
M/S PAL1-550
2550 Garcia Avenue
Mountain View, CA 94043
skrenta@eng.sun.com

Germano Caronni
Computer Engineering and Networks Laboratory
Swiss Federal Institute of Technology (ETH)
ETH Zentrum
CH-8092 Zurich
caronni@tik.ee.ethz.ch