IPSEC Working Group Ashar Aziz INTERNET-DRAFT Tom Markson Hemma Prafullchandra Sun Microsystems, Inc. Expires in six months December 21, 1995 Certificate Discovery Protocol 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. draft-ietf-ipsec-cdp-00.txt [Page 1] INTERNET-DRAFT CDP December 21, 1995 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. draft-ietf-ipsec-cdp-00.txt [Page 2] 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 - INTERNET-DRAFT CDP December 21, 1995 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 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 draft-ietf-ipsec-cdp-00.txt [Page 3] INTERNET-DRAFT CDP December 21, 1995 so on. In all these possible certificates the identity of the entity remains constant. 2. The Certificate Discovery Protocol The Initiator is the entity which initiates Certificate Discovery. The Responder is defined as the entity which receives the Certificate Discovery initiate message and (optionally) responds with certificates. The Initiator requests certificates by Name. A Name is defined as a Name Record consisting of a Name Type, a Name Length and the actual Name of the entity who the certificate belongs to. The Name Type specifies the type of name, for example, a PGP printable string or a SKIP [12] name. In the case where the Name Type is SKIP, the actual name consists of a Name Space Identifier (NSID) followed by the Master KeyID (MKID). The Initiator may optionally include certificates in an initiate message. The Responder MUST process any certificate(s) the Initiator has sent and respond with the requested certificates or an error (for example, if the requested certificate does not exist or it had problems processing the certificates it has received). Note that this protocol allows the initiator to not only request for all certificates for a particular "Name" but also send in the same message all the certificates of the Initiator. Also, in a request, the initiator may simply give the responder certificates without asking for any in return. If the responder accepts these certificates, the response message will return a status of 'OK'. If the responder does not accept all of these certificates, a bit will be set indicating this error and an appropriate error status will be returned. All certificate discovery protocol communication uses the User Datagram Protocol (UDP) [8]. The client binds to port cert-initiator and sends a certificate request to port cert-responder. Port number assignments are described later. The responder binds to port cert-responder and sends the response to port cert-initiator. Two separate ports are used to allow for multiple certificate requests to be made without waiting for the response to be received, (that means, one port is used to simply send requests out and the other port is used to receive responses). draft-ietf-ipsec-cdp-00.txt [Page 4] INTERNET-DRAFT CDP December 21, 1995 2.1 Clogging Defense The Certificate Discovery Protocol allows an Initiator to both make certificate discovery requests (i.e. fetch), as well present certificates (i.e. push). This could lead to a situation where an Initiator 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 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 to send the cookie with the expected value. If the Initiator 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 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 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. draft-ietf-ipsec-cdp-00.txt [Page 5] INTERNET-DRAFT CDP December 21, 1995 3. Certificate Discovery Packet The Certificate Discovery Protocol message consists of three parts: 1) the certificate discovery header, 2) zero or more name record(s), and 3) zero or more certificate record(s). 3.1 Certificate Discovery 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Initiator 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 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 MUST be set to 0. STATUS is used only in responses (i.e. ACTION = 2). It MUST be ignored by the responder. Possible values are: draft-ietf-ipsec-cdp-00.txt [Page 6] INTERNET-DRAFT CDP December 21, 1995 0 (OK) - 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 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 initiator has too many names listed in the certificate initiate message. If the initiator receives this response then it SHOULD resend the request with fewer names. The responder, however, SHOULD send as many certificates as it can in the response. #-OF-NAME-RECS - The number of Name 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. 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 value that the Responder should send back in draft-ietf-ipsec-cdp-00.txt [Page 7] INTERNET-DRAFT CDP December 21, 1995 the response. In a response message, this field contains the value that was sent by the initiator 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. Responder Cookie - This is an optional field and is not present when the 'R' bit set to zero. In an initiate message, 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 be sent in a new request. If the response message does not have the "Cookie Required" status, this value SHOULD be not be present and the 'R' bit should be set to 0. 3.2 Name Record Following the Certificate Discovery header is one Name record for each name included in the initiate message. A correctly formed Certificate Discovery message MUST contain as many name records as the #-OF-NAME- RECS field in the Certificate Discovery header field specifies. draft-ietf-ipsec-cdp-00.txt [Page 8] INTERNET-DRAFT CDP December 21, 1995 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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 is to follow. These values will be assigned by IANA. CERT-Length - specifies the length of the certificate in bytes. Certificate - the actual certificate. draft-ietf-ipsec-cdp-00.txt [Page 9] INTERNET-DRAFT CDP December 21, 1995 4. Assigned Numbers 4.1 Port Number Assignments IANA has assigned UDP port 1639 to "cert-initiator". UDP port 1640 has been assigned to "cert-responder". 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 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 draft-ietf-ipsec-cdp-00.txt [Page 10] INTERNET-DRAFT CDP December 21, 1995 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 suggest 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 certificates fetches/pushes 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. 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, P., "PGP Message Exchange draft-ietf-ipsec-cdp-00.txt [Page 11] INTERNET-DRAFT CDP December 21, 1995 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) draft-ietf-ipsec-cdp-00.txt [Page 12] INTERNET-DRAFT CDP December 21, 1995 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 draft-ietf-ipsec-cdp-00.txt [Page 13]