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 that is interoperable with other systems and ubiquitous. In light of this, we describe a protocol that 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 serve, or from the entity who owns the certificate.
The distribution of authenticated public keys is a fundamental problem that 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 co-exist on the Internet and hence many "certificate" formats.
A protocol that can be used to exchange certificates on the Internet is described. The protocol has the advantage that it does not require changes to existing services or deployment of large directory services to be used. The Certificate Discovery Protocol (CDP) allows certificate requests to be made to any arbitrary IP-node. This feature allows the initiator to send requests to, say, an IP-node that is acting as a certificate server (and hence has many certificates stored in its local certificate database) or to a single IP-node that only has its 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.
A certificate has at least two properties:
The name can be encoded in the certificate (for example, as in X.509 and PGP certificates) or it can be implicit in the public key itself (for example, 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.
The CDP is a request and response protocol used by two parties to transfer certificates. The requestor initiates CDP. The responder receives the CDP message and responds.
All CDP communication uses the User Datagram Protocol (UDP) [8]. The requestor binds to a random port and sends a request to port cert-responder. The port assignment is described later. The responder has bound to port cert-responder and sends the response to the random port on which the requestor sent the request.
The CDP consists of two parts: a Certificate Discovery Header and zero or more CDP records. The CDP header contains global status and the number of CDP records present in the message. A CDP header must be present in a CDP. One CDP record is present for each "question" or "answer," if present.
The simplest example of CDP is the requestor asking for a particular certificate from the responder. The responder replies with that certificate. If the responder does not have the certificate the requestor asked for, it sets the error status and does not return a certificate. In this example, one CDP header and one CDP record is sent in both the request and the response.
A CDP message may be requests for multiple certificates. The requestor produces one CDP record for each certificate being requested. The responder replies with a set of CDP records containing certificates or errors. It is important to note that if one CDP question generated an error, the responder should still process all of the other CDP questions. Errors are generally handled in the CDP record per-certificate level.
It is also important to note that questions and answers may not necessarily map one to one. For instance, the requestor may ask the responder for a certificate and receive multiple certificates as a response. The request might contain one CDP record, but the response contains one CDP record for each certificate returned.
The use of the term requestor is a bit confusing. Not only can the requestor request certificates from the responder, but it can also PUT certificates to the responder. A PUT is an unsolicited presentation of certificates from requestor to responder. The responder replies with a status indicating whether the PUT was successful.
The protocol supports a mixing of GETs and PUTs. The requestor can PUT its certificate in the same CDP as the GETs from 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 can simply be an error if the responder chooses not to process the request.
For example, if a requestor asks for five certificates from the responder, the request packet contains the CDP header and five CDP records. In the absence of an error in the header STATUS field, if the responder has five certificates to return, the response packet also contains five CDP packets. If the responder only had two of the five certificates, it still contains five CDP records. Three of the CDP records indicate an error.
The CDP allows a requestor to both make certificate discovery requests (for example, GET), as well as present certificates (for example, push ). This could lead to a situation where a requestor can attempt to clog a certificate server by flooding it with bogus certificate pushes. The server, when presented with a set of certificates, at a minimum, parses the request and checks if it already has the presented certificates in its local database. It can also verify a signature using a (possibly) expensive public key operation. Rather than discarding certificate pushes when it feels clogged, the server can request that the requestor use the optional cookie exchange mechanism. With this approach, the server can continue to serve legitimate requests.
If the responder requires a cookie, it expects the requestor to send the cookie with the expected value. If the requestor 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 can set. The responder must send this cookie back to the initiator in a response. This cookie can be used for replay protection, clogging defense, or as a means for the client to associate responses with requests.
If either the requestor or the responder is feeling clogged it should give preference in calculating the shared secrets (for example, gij) computations to certificates sent to it with cookies. (For example, it could precompute gij immediately upon receiving the certificate and after verifying it.)
The cookie generation method can be as recommended in the Photuris Internet Draft [9]; that is, 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.
The CDP message consists of two parts:
The following describes a certificate discovery header. All values are in network order
0 |
15 |
16 |
31 | ||||
Ver indicates protocol version number, VERS = 1 for this protocol.
Action/Status indicates either a request or the status of a response. 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.
0 (REQUEST) --This certificate discovery packet is initiating CDP.
1 (RESPONSE) --This certificate discovery packet is 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 is present in the Responder Cookie field.
3 (REQUEST_TOO_LARGE) --Request cannot be satisfied in one UDP packet (64K). This can occur, for example, if the initiator has asked for too many certificates in a request. If the initiator receives this response, then it should resend the request with fewer queries. The responder, however, should send as many certificates as it can in the response.
#-OF-RECS --The number of CDP records present. If this value is zero, then no CDP records are present in the message.
Reserved --This field is currently reserved. It must be set to zero by the sender and ignored by the receiver.
Requestor Cookie --In a request message, this contains a value that the responder must send back in the requestor Cookie field of the response.
In a response message, this field must contain the value sent by the requestor in this field in the request.
Responder Cookie --In 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 must be sent in a new request. If the requestor has not received a cookie from the responder, the requestor must set this field to be zero.
Following the Certificate Discovery header is one CDP record for each name or certificate included in the request message. A correctly formed Certificate Discovery message must contain as many CDP records as the #-OF-RECS field in the CDP header specifies.
0 |
15 |
16 |
31 | ||||
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 |
| GET SUCCEEDED | ||
| GET FAILED | ||
| PUT SUCCEEDED | ||
| PUT FAILED | ||
Name Type --Identifies the type of the Name.
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. This field must be the size as specified in 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.
Cert-Length --Specifies the length of the certificate in bytes. If no certificate is present, this field is set to zero.
Certificate --The certificate. This field must be the size that is specified in the Cert-Length field.
IANA has assigned cert-responder UDP port 1640.
Name Type and Certificate Type values are located in the assigned numbers document .A responder uses the cookie exchange mechanism when it feels clogged.
It is suggested that the UDP ports used by the CDP be treated as a "by-pass" channel for encryption (that is, non-encrypted traffic is permitted to be sent on these ports). As only the certificates GET and PUT are satisfied on these ports, of which the window for vulnerability is limited.
The authors would like to thank all of the people who helped make this report 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.
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.
[1] CCITT Recommendation X.500 (1988), The Directory
[2] Eastlake, D., Kaufman, C., Domain Name Security Extensions, Work in Progress
[3] Atkins, D., Stallings, W., Zimmermann, P., PGP Message Exchange Formats, Work in Progress
[4] Aziz, A., Markson, T., Prafullchandra, H., Encoding of an Unsigned Diffie-Hellman Public Value, October 1996
[5] Postel, J., Address Mappings, IEN 115, USC/Information Sciences Institute, August 1979
[6] Hinden, R., Deering, S., IP Version 6 Addressing Architecture, 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, 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, October 1996