- 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 June 6, 1996 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-01.txt [Page 1] INTERNET-DRAFT CDP June 12, 1996 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-01.txt [Page 2] INTERNET-DRAFT CDP June 12, 1996 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. 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 draft-ietf-ipsec-cdp-01.txt [Page 3] INTERNET-DRAFT CDP June 12, 1996 so on. In all these possible certificates the identity of the entity remains constant. 2. Overview of the Certificate Discovery Protocol (CDP) The Certificate Discovery protocol is a request/response protcocol used by two parties to transfer certificates. The Requester initiates Certificate Discovery. The Responder receives the Certificate Discovery message and responds. All certificate discovery protocol communication uses the User Datagram Protocol (UDP) [8]. The requester 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 requester 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 requester asking for a particular certificate from the responder. The responder replies with that 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. A CDP message may be requests for multiple certificates. The requester will produce one CDP record for each certificate being requested. The responder will reply 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 requester may ask the responder for a certificate and receive multiple certificates as a response. The request might contain one CDP record, but the response would contain one CDP record for EACH certificate returned. draft-ietf-ipsec-cdp-01.txt [Page 4] INTERNET-DRAFT CDP June 12, 1996 The use of the term requester is a bit confusing. Not only may the requester request certificates from the responder, but it may also PUT certificates to the responder. A PUT is an unsolicited presentation of 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 The Certificate Discovery Protocol allows a requester to both make certificate discovery requests (i.e. GET), as well present certificates (i.e. push). This could lead to a situation where 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 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 requester to send the cookie with the expected value. If the 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. draft-ietf-ipsec-cdp-01.txt [Page 5] INTERNET-DRAFT CDP June 12, 1996 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 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 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 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 two parts: 1) the certificate discovery Header (CDP header), 2) zero or more CDP record(s). draft-ietf-ipsec-cdp-01.txt [Page 6] INTERNET-DRAFT CDP June 12, 1996 3.1 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 | ACTION/STATUS | #-OF-RECS | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Requester Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Responder Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ VERS 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 may 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 0 then no CDP Records are present in the message. draft-ietf-ipsec-cdp-01.txt [Page 7] INTERNET-DRAFT CDP June 12, 1996 Reserved - This field is current reserved. It should be set to zero by the sender and ignored by the receiver. Requester Cookie - In a request message, this contains a value that the Responder should send back in the Requester Cookie field of the response. In a response message, this field MUST contain the value that was sent by the requester 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 requester has not received a cookie from the responder, the requester MUST set this field to be zero. 3.2 CDP Record 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. draft-ietf-ipsec-cdp-01.txt [Page 8] INTERNET-DRAFT CDP June 12, 1996 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. 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. These values will be assigned by IANA. Cert-Length - specifies the length of the certificate in bytes. If no certificate is present, this field is set to 0. Certificate - the certificate. This field must be the size that is specified in the Cert-Length field. draft-ietf-ipsec-cdp-01.txt [Page 9] INTERNET-DRAFT CDP June 12, 1996 4. Assigned Numbers 4.1 Port Number Assignments IANA has assigned cert-responder UDP port 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 draft-ietf-ipsec-cdp-01.txt [Page 10] INTERNET-DRAFT CDP June 12, 1996 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. 5. Security Considerations A responder should use the cookie exchange mechanism when it feels clogged. We suggest that 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 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. 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., Zimmermann, P., "PGP Message Exchange draft-ietf-ipsec-cdp-01.txt [Page 11] INTERNET-DRAFT CDP June 12, 1996 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-01.txt [Page 12] INTERNET-DRAFT CDP June 12, 1996 Ashar Aziz Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Avenue Mountain View, CA 94043 ashar.aziz@eng.sun.com Tom Markson Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Avenue Mountain View, CA 94043 markson@eng.sun.com Hemma Prafullchandra Sun Microsystems, Inc. M/S PAL1-550 2550 Garcia Avenue Mountain View, CA 94043 hemma@eng.sun.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 draft-ietf-ipsec-cdp-01.txt [Page 13] 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 -