< draft-ietf-ipsec-cdp-00.txt   draft-ietf-ipsec-cdp-01.txt >
- 1 -
IPSEC Working Group Ashar Aziz IPSEC Working Group Ashar Aziz
INTERNET-DRAFT Tom Markson INTERNET-DRAFT Tom Markson
Hemma Prafullchandra Hemma Prafullchandra
Rich Skrenta
Sun Microsystems, Inc. Sun Microsystems, Inc.
Expires in six months December 21, 1995 Germano Caronni
Swiss Federal Institute of
Technology
Expires in six months June 6, 1996
Certificate Discovery Protocol Certificate Discovery Protocol
<draft-ietf-ipsec-cdp-00.txt> <draft-ietf-ipsec-cdp-01.txt>
Status of this Memo Status of this Memo
This document is a submission to the IETF Internet Protocol Security This document is a submission to the IETF Internet Protocol Security
(IPSEC) Working Group. Comments are solicited and should be addressed to (IPSEC) Working Group. Comments are solicited and should be addressed to
to the working group mailing list (ipsec@ans.net) or to the authors. to the working group mailing list (ipsec@ans.net) or to the authors.
This document is an Internet-Draft. Internet Drafts are working This document is an Internet-Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working Groups. Note that other groups may also distribute working its working Groups. Note that other groups may also distribute working
skipping to change at page 3, line 5 skipping to change at page 3, line 5
Use of Public key cryptography is becoming widespread on the Internet in Use of Public key cryptography is becoming widespread on the Internet in
such applications as electronic mail and IP Security (IPSEC). such applications as electronic mail and IP Security (IPSEC).
Currently, however, a common public key certificate infrastructure does Currently, however, a common public key certificate infrastructure does
not exist which is interoperable with other systems and ubiquitous. In 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 light of this, we describe a protocol which may be used to exchange or
retrieve certificates (essentially signed public keys) with or from retrieve certificates (essentially signed public keys) with or from
another entity. The protocol may be used to request certificates from a another entity. The protocol may be used to request certificates from a
directory/name server or from the entity who owns the certificate. 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 1. Overview
The distribution of authenticated public keys is a fundamental problem The distribution of authenticated public keys is a fundamental problem
which needs to be resolved with use of public key cryptography. Many which needs to be resolved with use of public key cryptography. Many
solutions exist for distributing authenticated public keys. Two of the solutions exist for distributing authenticated public keys. Two of the
more common distribution methods are the X.500 directory service [1] and more common distribution methods are the X.500 directory service [1] and
Secure Domain Name System (Secure-DNS) [2]. Each method has a different Secure Domain Name System (Secure-DNS) [2]. Each method has a different
encoding format for the entity identity and the public key that belongs 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 to it. It is expected that many distribution mechanisms will co-exist on
the Internet and hence many "certificate" formats. the Internet and hence many "certificate" formats.
skipping to change at page 3, line 70 skipping to change at page 3, line 31
allows the initiator to send requests to, say, an IP-node which is allows the initiator to send requests to, say, an IP-node which is
acting as a certificate server (and hence would have many certificates acting as a certificate server (and hence would have many certificates
stored in its local certificate database) or to a single IP-node which stored in its local certificate database) or to a single IP-node which
only has it's own certificate. only has it's own certificate.
As noted earlier, there are several different types of certificates in As noted earlier, there are several different types of certificates in
existence: X.509 certificates [11], PGP certificates [3], Secure DNS existence: X.509 certificates [11], PGP certificates [3], Secure DNS
resource records and hashed public keys [4]. This protocol is designed resource records and hashed public keys [4]. This protocol is designed
to support all of these and new ones as they emerge. to support all of these and new ones as they emerge.
All certificates have at least two properties: A Certificate has at least two properties:
(1) it provides for a cryptographic binding to a name/identity of an (1) it provides for a cryptographic binding to a name/identity of an
entity, and entity, and
(2) it provides integrity protection of a public key. (2) it provides integrity protection of a public key.
The name may be encoded in the certificate (for example, as in X.509 and 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., PGP certificates) or it may be implicit in the public key itself (i.e.,
the cryptographic hash of the public key). the cryptographic hash of the public key).
As with various certificate types, numerous naming conventions exist on As with various certificate types, numerous naming conventions exist on
skipping to change at page 4, line 7 skipping to change at page 4, line 7
DNS names and PGP user names. This protocol attempts to support all of DNS names and PGP user names. This protocol attempts to support all of
these and allows for other syntaxes. these and allows for other syntaxes.
Note, that a particular entity may have more than one certificate. An Note, that a particular entity may have more than one certificate. An
entity may have the same public value in different certificate formats, entity may have the same public value in different certificate formats,
or have multiple public values each in a separate certificate or have or have multiple public values each in a separate certificate or have
the same public value certified by different Certifying Authorities, and the same public value certified by different Certifying Authorities, and
so on. In all these possible certificates the identity of the entity so on. In all these possible certificates the identity of the entity
remains constant. remains constant.
2. The Certificate Discovery Protocol 2. Overview of the Certificate Discovery Protocol (CDP)
The Initiator is the entity which initiates Certificate Discovery. The The Certificate Discovery protocol is a request/response protcocol used
Responder is defined as the entity which receives the Certificate by two parties to transfer certificates. The Requester initiates
Discovery initiate message and (optionally) responds with certificates. Certificate Discovery. The Responder receives the Certificate Discovery
message and responds.
The Initiator requests certificates by Name. A Name is defined as a Name All certificate discovery protocol communication uses the User Datagram
Record consisting of a Name Type, a Name Length and the actual Name of Protocol (UDP) [8]. The requester binds to a random port and sends a
the entity who the certificate belongs to. The Name Type specifies the request to port cert-responder. The port assignment is described later.
type of name, for example, a PGP printable string or a SKIP [12] name. The responder has bound to port cert-responder and sends the response to
In the case where the Name Type is SKIP, the actual name consists of a the random port on which the requester sent the request.
Name Space Identifier (NSID) followed by the Master KeyID (MKID).
The Initiator may optionally include certificates in an initiate The CDP consists of two parts: a Certificate Discovery Header and zero
message. The Responder MUST process any certificate(s) the Initiator or more CDP records. The CDP header contains global status and the
has sent and respond with the requested certificates or an error (for number of CDP records present in the message. A CDP header MUST be
example, if the requested certificate does not exist or it had problems present in a CDP. One CDP record is present for each "question" or
processing the certificates it has received). "answer", if present.
Note that this protocol allows the initiator to not only request for all The simplest example of CDP is the requester asking for a particular
certificates for a particular "Name" but also send in the same message certificate from the responder. The responder replies with that
all the certificates of the Initiator. certificate. If the responder does not have the certificate the
requester asked for, it will set the error status and not return a
certificate. In this example, one CDP header and one CDP record would
be sent in both the request and the response.
Also, in a request, the initiator may simply give the responder A CDP message may be requests for multiple certificates. The requester
certificates without asking for any in return. If the responder accepts will produce one CDP record for each certificate being requested. The
these certificates, the response message will return a status of 'OK'. responder will reply with a set of CDP records containing certificates
If the responder does not accept all of these certificates, a bit will or errors. It is important to note that if one CDP question generated
be set indicating this error and an appropriate error status will be an error, the responder SHOULD still process all of the other CDP
returned. questions. Errors are generally handled in the CDP record per-
certificate level.
All certificate discovery protocol communication uses the User Datagram It is also important to note that questions and answers may not
Protocol (UDP) [8]. The client binds to port cert-initiator and sends a necessarily map one to one. For instance, the requester may ask the
certificate request to port cert-responder. Port number assignments are responder for a certificate and receive multiple certificates as a
described later. The responder binds to port cert-responder and sends response. The request might contain one CDP record, but the response
the response to port cert-initiator. would contain one CDP record for EACH certificate returned.
Two separate ports are used to allow for multiple certificate requests The use of the term requester is a bit confusing. Not only may the
to be made without waiting for the response to be received, (that means, requester request certificates from the responder, but it may also PUT
one port is used to simply send requests out and the other port is used certificates to the responder. A PUT is an unsolicited presentation of
to receive responses). certificates from requester to responder. The responder will reply
with a status indicating whether the PUT was successful.
The protocol supports a mixing of GETs and PUTs. The requester may
PUT it's certificate in the same CDP that he GETs the responders.
The responder MUST either indicate an error in the STATUS field of the
CDP header or generate at least one CDP record for each CDP record
present in a request. The response to each request CDP record MUST have
the same name fields (name type, name len, Name) as the request. The
response MAY simply be an error if the responder chooses not to 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 absence of an error in the header STATUS field, if the responder has
5 certificates to 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 2.1 Clogging Defense
The Certificate Discovery Protocol allows an Initiator to both make The Certificate Discovery Protocol allows a requester to both make
certificate discovery requests (i.e. fetch), as well present certificate discovery requests (i.e. GET), as well present certificates
certificates (i.e. push). This could lead to a situation where an (i.e. push). This could lead to a situation where a requester may
Initiator may attempt to clog a certificate server by flooding it with attempt to clog a certificate server by flooding it with bogus
bogus certificate pushes. The server, when presented with a set of certificate pushes. The server, when presented with a set of
certificates would at a minimum parse the request and check if it certificates would at a minimum parse the request and check if it
already has the presented certificates in its local database. It may already has the presented certificates in its local database. It may
also have to verify a signature using a (possibly) expensive public key also have to verify a signature using a (possibly) expensive public key
operation. Rather than discarding certificate pushes when it feels operation. Rather than discarding certificate pushes when it feels
clogged, the server may request that the Initiator use the optional clogged, the server may request that the requester use the optional
cookie exchange mechanism. With this approach, the server may continue cookie exchange mechanism. With this approach, the server may continue
to serve legitimate requests. to serve legitimate requests.
If the Responder requires a cookie, it will expect the Initiator to send If the Responder requires a cookie, it will expect the requester to send
the cookie with the expected value. If the Initiator does not send this the cookie with the expected value. If the requester does not send this
cookie, the Responder SHOULD send a message with the "Cookie Required" cookie, the Responder SHOULD send a message with the "Cookie Required"
status and the desired cookie in the cookie field. status and the desired cookie in the cookie field.
The protocol also supports a cookie the initiator may set. The The protocol also supports a cookie the initiator may set. The
responder MUST send this cookie back to the initiator in a response. 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 This cookie may be used for replay protection, clogging defense or as a
means for the client to associate responses with requests. means for the client to associate responses with requests.
If either the Initiator or the Responder is feeling clogged it SHOULD If either the requester or the Responder is feeling clogged it SHOULD
give preference in calculating the shared secrets (i.e. g^ij) give preference in calculating the shared secrets (i.e. g^ij)
computations to certificates sent to it with magic cookies. (For computations to certificates sent to it with cookies. (For example, it
example, it could precompute g^ij immediately upon receiving the could precompute g^ij immediately upon receiving the certificate and
certificate and after verifying it.) after verifying it.)
2.1.1 Cookie Generation 2.1.1 Cookie Generation
The cookie generation method is as recommended in the Photuris Internet The cookie generation method may be as recommended in the Photuris
Draft [9], i.e., an MD5 [10] hash is applied over the IP Source and IP Internet Draft [9], i.e., an MD5 [10] hash is applied over the IP Source
Destination Addresses, the UDP source and destination ports, and a and IP Destination Addresses, the UDP source and destination ports, and
locally generated secret random value. A subset of this hash is then a locally generated secret random value. A subset of this hash is then
used as a cookie. used as a cookie.
Note that this is an implementation detail in that the mechanism Note that this is an implementation detail in that the mechanism
employed is purely a local matter, two communicating entities do not employed is purely a local matter, two communicating entities do not
have to use the same mechanism. have to use the same mechanism.
3. Certificate Discovery Packet 3. Certificate Discovery Packet
The Certificate Discovery Protocol message consists of three parts: The Certificate Discovery Protocol message consists of two parts:
1) the certificate discovery header, 1) the certificate discovery Header (CDP header),
2) zero or more name record(s), and 2) zero or more CDP record(s).
3) zero or more certificate record(s).
3.1 Certificate Discovery Header 3.1 CDP Header
The following describes a certificate discovery header. All values The following describes a certificate discovery header. All values
are in network order. are in network order.
0 1 2 3 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 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 | | VERS | ACTION/STATUS | #-OF-RECS | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiator Cookie (if I bit is set) | | Requester Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Cookie (if R bit is set) | | Responder Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VERS indicates protocol version number, VERS = 1 for this protocol. 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). Action/Status indicates either a request or the status of a response.
R bit indicates if a 32 bit Responder Cookie is present (R=1) or not (R=0). It MUST be set to the value REQUEST by the initiator. The responder
MUST set the field to one of the values RESPONSE, COOKIE_REQUIRED
or REQUEST_TOO_LARGE.
ACT indicates the type of message. Possible values are: 0 (REQUEST) - This Certificate discovery packet is
1 (Initiate) - initiate either a request for certificate(s) or simply initiating CDP.
send certificates.
2 (Response) - response to a certificate Initiate.
P bit in a response indicates whether the responder has rejected 1 (RESPONSE) - This Certificate discovery packet is a
certificates presented in the initiate message. If the responder has response to a previous CDP initiate.
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
MUST be set to 0.
STATUS is used only in responses (i.e. ACTION = 2). It MUST be ignored 2 (COOKIE_REQUIRED) - Responder requires the initiator to resend this
by the responder. Possible values are: request with a non-zero responder cookie.
This cookie is present in the Responder Cookie
field.
0 (OK) - The responder has processed the certificates sent 3 (REQUEST_TOO_LARGE) - Request cannot be satisfied in one UDP packet
or has returned the requested certificates.
1 (Unknown Error) - An error has occurred.
2 (Unknown Name) - No certificates for the requested "Name" can
be found in the local certificate database or
the local domain name server.
3 (Unsupported Name Type) - Name Type in the certificate request is
unsupported.
4 (Unsupported CERT-Type) - CERT-Type in the certificate request is
unsupported.
5 (Cookie Required) - Responder requires the initiator to resend this
request with a non-zero cookie included.
6 (Request Too Large) - Request cannot be satisfied in one UDP packet
(64K). This may occur, for example, if the (64K). This may occur, for example, if the
initiator has too many names listed in the initiator has asked for too many certificates
certificate initiate message. If the initiator in a request. If the initiator receives this
receives this response then it SHOULD resend response then it SHOULD resend the request
the request with fewer names. The responder, with fewer queries. The responder,
however, SHOULD send as many certificates as however, SHOULD send as many certificates as
it can in the response. it can in the response.
#-OF-NAME-RECS - The number of Name Records present in the #-OF-RECS - The number of CDP Records present. If this
initiate message. This field is only meaningful value is 0 then no CDP Records are present in
in an initiate message. If the field is set to the message.
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. If this value is 0 then no
Certificate 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 field is zero in a
response, the R bit and the STATUS field
indicate the status of the previous request.
Initiator Cookie - This is an optional field and is not present
when the 'I' bit is set to zero.
In an initiate message, this contains the Reserved - This field is current reserved. It should be
value that the Responder should send back in set to zero by the sender and ignored by the
the response. receiver.
In a response message, this field contains the Requester Cookie - In a request message, this contains a
value that was sent by the initiator in this value that the Responder should send back
field in the initiate message. This field in the Requester Cookie field of the response.
should be present in a response message
(and the I bit set) if the initiate message
has the 'I' bit set to 1.
Responder Cookie - This is an optional field and is not present In a response message, this field MUST contain
when the 'R' bit set to zero. the value that was sent by the requester in this
field in the request.
In an initiate message, this contains the value Responder Cookie - In a request, this contains the value
that the Responder previously indicated should that the Responder previously indicated should
be sent in the request. In a response message, be sent in the request. In a response message,
if the "Cookie Required" status is set, this if the "Cookie Required" status is set, this
contains the value that should be sent in a contains the value that MUST be sent in a
new request. If the response message does new request. If the requester has not received
not have the "Cookie Required" status, this a cookie from the responder, the requester MUST
value SHOULD be not be present and the 'R' set this field to be zero.
bit should be set to 0.
3.2 Name Record 3.2 CDP Record
Following the Certificate Discovery header is one Name record for each Following the Certificate Discovery header is one CDP record for each
name included in the initiate message. A correctly formed Certificate name or certificate included in the request message. A correctly formed
Discovery message MUST contain as many name records as the #-OF-NAME- Certificate Discovery message MUST contain as many CDP records as the
RECS field in the Certificate Discovery header field specifies. #-OF-RECS field in the CDP header specifies.
0 1 2 3 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 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 ~ |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 Name Type - Identifies the type of the Name. The values of this
field will be assigned by the Internet Assigned Numbers field will be assigned by the Internet Assigned Numbers
Authority (IANA). Authority (IANA).
Name Length - The length of the name in bytes. Name Length - The length of the name in bytes.
Name - The name of the entity who owns the certificate for Name - The name of the entity who owns the certificate for
which the request is being made. which the request is being made. This field must be
the size as specified in Name Length.
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 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 the same as in a name record.
CERT-Type - specifies the certificate type of the certificate that Cert-Type - specifies the certificate type of the certificate that
is to follow. These values will be assigned by IANA. is to follow. If no certificate is present, this field
is set to zero. These values will be assigned by IANA.
CERT-Length - specifies the length of the certificate in bytes. 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. Certificate - the certificate. This field must be the size that is
specified in the Cert-Length field.
4. Assigned Numbers 4. Assigned Numbers
4.1 Port Number Assignments 4.1 Port Number Assignments
IANA has assigned UDP port 1639 to "cert-initiator". UDP port 1640 has IANA has assigned cert-responder UDP port 1640.
been assigned to "cert-responder".
4.2 Name Type Assignments 4.2 Name Type Assignments
Name Type Value Name Type Name Type Value Name Type
1 SKIP 1 SKIP
2 PGP Printable String 2 PGP Printable String
3 PGP KeyID 3 PGP KeyID
4 DNS name 4 DNS name
5 RFC 822 name 5 RFC 822 name
skipping to change at page 10, line 42 skipping to change at page 10, line 41
4.3 Certificate Type Assignments 4.3 Certificate Type Assignments
CERT-Type Value Certificate Type CERT-Type Value Certificate Type
1 X.509 [1] 1 X.509 [1]
2 PGP [3] 2 PGP [3]
3 Secure DNS [2] 3 Secure DNS [2]
4 MD5 of Unsigned DH Public Value [4] 4 MD5 of Unsigned DH Public Value [4]
5 MD5 of Unsigned Elliptic Curve Public Value 5 MD5 of Unsigned Elliptic Curve Public Value
6 MD5 of Unsigned RSA 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- 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 Type values 7 through 249 inclusive are reserved to IANA for future
allocation as Assigned Numbers. Such future allocation by IANA will allocation as Assigned Numbers. Such future allocation by IANA will
normally require that a public specification exist for the Certificate normally require that a public specification exist for the Certificate
Type obtaining such allocation. CERT-Types in the range 250 through 255 Type obtaining such allocation. CERT-Types in the range 250 through 255
inclusive are reserved for private use among consenting parties. CERT- inclusive are reserved for private use among consenting parties. CERT-
Types in the range 250 through 255 inclusive will hence only have local Types in the range 250 through 255 inclusive will hence only have local
uniqueness properties. 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 5. Security Considerations
A responder should use the cookie exchange mechanism when it feels A responder should use the cookie exchange mechanism when it feels
clogged. The Certificate Discovery Protocol uses two ports, we suggest clogged.
that these ports be treated as a "by-pass" channel for encryption (i.e.
non encrypted traffic is permitted to be sent on these ports). As only We suggest that the UDP ports used by the Certificate Discovery Protocol
certificates fetches/pushes are satisfied on these ports the window for be treated as a "by-pass" channel for encryption (i.e. non encrypted
vulnerability is limited. traffic is permitted to be sent on these ports). As only certificates
GETs/PUTs are satisfied on these ports the window for vulnerability is
limited.
Acknowledgements Acknowledgements
We would like to thank all of the people who helped make this draft We would like to thank all of the people who helped make this draft
possible. 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 Ran Atkinson suggested that this protocol should be independent of other
IPSEC drafts. IPSEC drafts.
Phil Karn and Bill Simpson for their work on the Cookie Exchange scheme Phil Karn and Bill Simpson for their work on the Cookie Exchange scheme
for the Photuris Session Key Management Protocol which influenced the for the Photuris Session Key Management Protocol which influenced the
addition of the Cookie field to this protocol. 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 References
[1] CCITT Recommendation X.500 (1988), "The Directory" [1] CCITT Recommendation X.500 (1988), "The Directory"
[2] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D [2] Eastlake, D., Kaufman, C., "Domain Name Security Extensions", (I-D
draft-ietf-dnssec-secext-04.txt), Work In Progress draft-ietf-dnssec-secext-04.txt), Work In Progress
[3] Atkins, D., Stallings, W., Zimmerman, P., "PGP Message Exchange [3] Atkins, D., Stallings, W., Zimmermann, P., "PGP Message Exchange
Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress Formats", (I-D draft-atkins-pgpformats-01.txt), Work In Progress
[4] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned [4] Aziz, A., Markson, T., Prafullchandra, H., "Encoding of an Unsigned
Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh- Diffie-Hellman Public Value", (I-D draft-ietf-ipsec-skip-udh-
00.txt), Work In Progress 00.txt), Work In Progress
[5] Postel, J., "Address Mappings", IEN 115, USC/Information Sciences [5] Postel, J., "Address Mappings", IEN 115, USC/Information Sciences
Institute, August 1979 Institute, August 1979
[6] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", [6] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture",
skipping to change at page 13, line 9 skipping to change at page 13, line 9
[12] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management [12] Aziz, A., Markson, T., Prafullchandra, H., "Simple Key-Management
for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work In for Internet Protocols", (I-D draft-ietf-ipsec-skip-06.txt), Work In
Progress Progress
Author's Address(es) Author's Address(es)
Ashar Aziz Ashar Aziz
Sun Microsystems, Inc. Sun Microsystems, Inc.
M/S PAL1-550 M/S PAL1-550
2550 Garcia Avenue 2550 Garcia Avenue
Mountain View, CA 94043 Mountain View, CA 94043
ashar.aziz@eng.sun.com
Email: ashar.aziz@eng.sun.com
Alternate email address: ashar@incog.com
Tom Markson Tom Markson
Sun Microsystems, Inc. Sun Microsystems, Inc.
M/S PAL1-550 M/S PAL1-550
2550 Garcia Avenue 2550 Garcia Avenue
Mountain View, CA 94043 Mountain View, CA 94043
markson@eng.sun.com
Email: markson@incog.com
Alternate email address: markson@eng.sun.com
Hemma Prafullchandra Hemma Prafullchandra
Sun Microsystems, Inc. Sun Microsystems, Inc.
M/S PAL1-550 M/S PAL1-550
2550 Garcia Avenue 2550 Garcia Avenue
Mountain View, CA 94043 Mountain View, CA 94043
hemma@eng.sun.com
Email: hemma@eng.sun.com Rich Skrenta
Alternate email address: hemma@incog.com 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
CONTENTS
Status of this Memo................................. 1
Abstract............................................ 2
1. Overview............................................ 3
2. Overview of the Certificate Discovery Protocol
(CDP)............................................... 4
2.1 Clogging Defense............................... 5
2.1.1 Cookie Generation 6
3. Certificate Discovery Packet........................ 6
3.1 CDP Header..................................... 7
3.2 CDP Record..................................... 8
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 -
 End of changes. 57 change blocks. 
220 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/