Kerberos Working Group H. Hotz Internet-Draft Jet Propulsion Laboratory, Intended status: Standards Track California Institute of Expires: November 14, 2010 Technology May 13, 2010 KX509 Kerberized Certificate Issuance Protocol draft-hotz-kx509-00.txt Abstract This rfc describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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 are draft documents 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 14, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Hotz Expires November 14, 2010 [Page 1] Internet-Draft KX509 May 2010 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Protocol Data . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Request Packet . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Reply Packet . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Certificate Cacheing and Deployment Considerations . . 7 Appendix B. Known Issues with This Draft . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Hotz Expires November 14, 2010 [Page 2] Internet-Draft KX509 May 2010 1. Introduction The two primary ways of providing cryptographically secure identification on the Internet are Kerberos tickets [RFC4120], and X.509 [RFC3280] and [X.509] certificates. In practical IT infrastructure where both are in use, it's highly desirable to deploy their support in a way which guarantees they both authoritatively refer to the same entities. There is already a widely-adopted standard for using X.509 certificates to acquire corresponding Kerberos tickets called PKINIT [RFC4556]. This rfc describes the kx509 protocol for supporting the symmetric operation of acquiring X.509 certificates using Kerberos tickets. In normal operation kx509 can be used after a Kerberos ticket- granting-ticket (TGT) is acquired, which is most likely during user login. First, the client generates a RSA public/private key-pair. Next, using the Kerberos ticket-granting-ticket, it acquires a Kerberos service ticket for the KCA (Kerberized Certificate Authority), and uses this to send the public half of its key-pair. The KCA will decrypt the service ticket, verify the integrity of the incoming packet, determine the identity of the user, and use the session key to send back a corresponding X.509 certificate. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Protocol Data The protocol consists of a single request/reply exchange using UDP. Both the request and the reply packet begin with four bytes of version ID information, followed by a DER encoded ASN.1 message. The first two bytes of the version ID are reserved. They MUST be set to zero when sent, and SHOULD be ignored when received. The third and fourth bytes are the major and minor version numbers. The version of the protocol described in this document is designated 2.0, so the first four bytes of the packet are 0, 0, 2, 0. Incompatible variations of this protocol MUST use a different major version number. Hotz Expires November 14, 2010 [Page 3] Internet-Draft KX509 May 2010 2.1. Request Packet The request consists of a version ID, a Kerberos AP_REQ, integrity check data on the request, and a public key generated by the client. The ASN.1 encoding is: KX509Request ::= SEQUENCE { ap-req OCTET STRING, pk-hash OCTET STRING, pk-key OCTET STRING } The ap-req is as described in [RFC4120] Section 5.5.1. The pk-hash is HMAC using SHA-1 as the underlying hash. All 160 bits are sent. The key used is the Kerberos session key. The data is the 4-byte version ID and the octet string for pk-key. The pk-key contains a public key. This key and its corresponding private key are generated by the client before contacting the server. The key is DER encoded and then stored in this octet string in the request. 2.2. Reply Packet The reply consists of a version ID, an error code, and an optional authentication hash, optional certificate, and optional error text string. The service SHOULD return replies of the same version as the request where possible. KX509Response ::= SEQUENCE { error-code[0] INTEGER DEFAULT 0, hash[1] OCTET STRING OPTIONAL, certificate[2] OCTET STRING OPTIONAL, e-text[3] VisibleString OPTIONAL } Although the format of the reply contains optional objects, the server MUST only generate replies with one of the following allowed combinations. +-------------+---------------+------+ | certificate | | hash | | error-code | error-message | hash | | error-code | error-message | | +-------------+---------------+------+ The first case is returned when the server successfully generates a certificate for the user. Hotz Expires November 14, 2010 [Page 4] Internet-Draft KX509 May 2010 The second case is returned when the server successfully authenticates the user and their key, but is unable for some other reason to generate a certificate. The third case MAY be returned if the server is unable to successfully authenticate the user and intends to return some unauthenticated information to the client. The hash on a response is computed using SHA-1 HMAC as for the request. The data that is hashed consists of the 4-byte version ID at the beginning of the packet, the error-code, and all other optional fields except the hash itself. The error-message MAY be translated into other character sets for display purposes, but the hash is computed on the error-message in its VisibleString representation. If the error-message contains NUL characters, the client MAY ignore any part of the error message after the first NUL character for display purposes. As implied by the above table, if the reply does not contain a certificate it MUST contain an error message and a non-zero error code. Conversely, if a certificate is returned then the error code MUST be zero. The server SHOULD NOT send a zero error-code. The client MUST treat a missing error-code as if it were zero. 3. Protocol Operation Absent errors, the protocol consists of a single request, sent via UDP, and a single reply, also sent via UDP. Before constructing the request, the client must know the canonical name(s) and port(s) of the server(s) to contact. It MAY determine them by looking up the service's SRV record as described in[RFC2782]. The entry to be used is _kca._udp._realm_, where _realm_ is the Kerberos realm, used as part of the DNS name. (KCA stands for Kerberized Certificate Authority.) The client must then acquire a service ticket in order to construct the ap-req for the service. The Kerberos service principal name to use for this service has a first component of "kca_service". The second component and the realm of the principal follow normal Kerberos conventions. When the server receives a request, it MUST make sanity checks including at least the following: Hotz Expires November 14, 2010 [Page 5] Internet-Draft KX509 May 2010 o The AP-REQ can be decoded and is not expired. o The request's hash is valid. The server SHOULD make other sanity checks, such as a minimum public key length, to the extent feasible. The server MAY decline to respond to an erroneous request. If it does not receive a response a client MAY retry its request, but the client SHOULD wait at least one second before doing so. The client MUST verify any hash in the reply, and MUST NOT use any certificate in a reply whose hash does not verify. The client MAY display an error-message if the hash is absent or does not verify, but SHOULD indicate the message is not authenticated. 4. Acknowledgements The original version of kx509 was implemented using Kerberos 4 at the University of Michigan, and was nicely documented in [KX509]. Many thanks to them for their original work. 5. IANA Considerations This service is conventionally run on UDP port 9878, but this memo includes no request to IANA. 6. Security Considerations The only encrypted information in the protocol is that used by Kerberos itself. The considerations for any Kerberized service apply here. The other information, such as the public key and certificate, are transmitted in the clear but (as the name implies) were designed to be publicly available. However their visibility could raise privacy concerns. The hash is used to protect their integrity. The policies for issuing Kerberos tickets and X.509 certificates are usually expressed very differently. An implementation of this protocol should not provide a mechanism for bypassing ticket or certificate policies. Furthermore, if the issued certificate can be used with PKINIT, this authentication loop should not bypass policy limits for either X.509 certificates or Kerberos tickets. Hotz Expires November 14, 2010 [Page 6] Internet-Draft KX509 May 2010 X.509 certificates are usually issued with considerably longer validity times than Kerberos tickets. If an implementation of this protocol does not limit the validity time of the issued certificates to the Kerberos ticket lifetime, then care should be taken that the issued certificate is not valid for longer than the intended policy should allow. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. 7.2. Informative References [KX509] Doster, W., Watts, M., and D. Hyde, "The KX509 Protocol", September 2001, . [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [X.509] International Telecommunications Union, "Recommendation X.509: The Directory: Public-key and attribute certificate framework", November 2008. Appendix A. Certificate Cacheing and Deployment Considerations As noted in the Security Considerations section, the function lifetime of the acquired X.509 certificate should probably match the lifetime of its predecessor Kerberos ticket. It is also likely that X.509 certificates issued with this protocol should be deleted when Hotz Expires November 14, 2010 [Page 7] Internet-Draft KX509 May 2010 the supporting Kerberos tickets are deleted. That makes the Kerberos ticket cache a reasonable location to store the certificate. On the other hand applications, such as web browsers, probably expect certificates in different stores. A widely used solution to this problem is to implement the KX509 client within a PKCS11 library. Appendix B. Known Issues with This Draft 1. The hashing should be better described. 2. Should there be provision for SHA-2 or some other hash? 3. Should there be provision for DSA keys? 4. Should there be IANA registration of a service port requested? 5. Is there a better way to specify how to find the service that allows for how Windows/AD does it? (section 3) 6. Should timeouts, etc. be more fully specified? Author's Address Henry B. Hotz Jet Propulsion Laboratory, California Institute of Technology 4800 Oak Grove Dr. Pasadena, CA 91109 US Phone: +01 818 354-4880 Email: hotz@jpl.nasa.gov Hotz Expires November 14, 2010 [Page 8]