Independent Submission H. Hotz Request for Comments: 6717 Jet Propulsion Lab, Caltech Category: Informational R. Allbery ISSN: 2070-1721 Stanford University August 2012 kx509 Kerberized Certificate Issuance Protocol in Use in 2012
AbstractThis document describes a protocol, called kx509, for using Kerberos tickets to acquire X.509 certificates. These certificates may be used for many of the same purposes as X.509 certificates acquired by other means, but if a Kerberos infrastructure already exists, then the overhead of using kx509 may be much less. While not standardized, this protocol is already in use at several large organizations, and certificates issued with this protocol are recognized by the International Grid Trust Federation. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6717. Copyright Notice Copyright (c) 2012 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 to this document.
1. Introduction ....................................................2 1.1. Requirements Language ......................................3 2. Protocol Data ...................................................3 2.1. Request Packet .............................................3 2.2. Reply Packet ...............................................4 3. Protocol Operation ..............................................7 4. Acknowledgements ................................................8 5. IANA Considerations .............................................8 6. Security Considerations .........................................9 7. References .....................................................10 7.1. Normative References ......................................10 7.2. Informative References ....................................10 Appendix A. Certificate Caching and Deployment Considerations ....12 Appendix B. Historic Extensions ..................................12 Appendix C. Example Exchange .....................................12 RFC4120] and X.509 [RFC5280] [X.509] certificates. In practical IT infrastructure where both are in use, it's highly desirable to deploy their support in a way that 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 Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556]. This document describes the kx509 protocol for supporting the symmetric operation of acquiring X.509 certificates using Kerberos tickets. Preparing and reviewing this document exposed a number of issues that are discussed in the security considerations. Unfortunately, some of them can only be addressed with an incompatible upgrade to this protocol. The IETF's Kerberos working group has an expected work item to address these issues. The International Grid Trust Federation [IGTF] supports the use of Short Lived Credential Services [SLCS] as a means to authenticate for resource usage based on other, native identity stores that an organization maintains. X.509 certificates issued using the kx509 protocol based on a Kerberos identity is one of the recognized credential services. The certificate profile for that use is outside the scope of this RFC but is described in [GRID-prof].
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 an 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. RFC2119]. RFC4120], Section 5.5.1.
The pk-hash is Hashed Message Authentication Code (HMAC) using SHA-1 as the underlying hash. All 160 bits are sent. The key used is the Kerberos session key. The data to be hashed is the concatenation of the following: o 4-byte version ID at the beginning of the packet. o OCTET STRING of the AP-REQ. o OCTET STRING of the 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. Implementations of this protocol MUST support RSA keys, in which case the key is a DER-encoded RSAPublicKey as defined in [RFC3447], Section A.1.1, and then it is stored in this octet string in the request. Its encoding as an OCTET STRING starts with the 0x30 byte sequence at the beginning of a DER-encoded RSAPublicKey. Use of other public-key types is not defined. Appendix C shows an example request packet.
The first case is returned when the server successfully generates a certificate for the user. The certificate is a DER-encoded certificate as defined in [RFC5280], Appendix A, page 116. Its encoding as an OCTET STRING starts with the 0x30 byte sequence that is at the beginning of a DER-encoded certificate. 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 is the concatenation of the following things: o 4-byte version ID at the beginning of the packet. o DER representation of the error-code exclusive of the tag and length, if it is present. o OCTET STRING of the certificate, if it is present. o VisibleString representation of the e-text exclusive of the tag and length, if it is present. In other words, the hash is computed on the data in the fields that are present, exclusive of the overall ASN.1 wrapping. The e-text MAY be translated into other character sets for display purposes, but the hash is computed on the e-text in its VisibleString representation. If the e-text 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 use the DEFAULT encoding for a zero error-code value by omitting any explicit error-code from the reply.
The defined values for error-code are as follows: +------------+-----------------------------+------------------------+ | error-code | Condition | Example | +------------+-----------------------------+------------------------+ | 1 | Permanent problem with | Incompatible version | | | client request | | | 2 | Solvable problem with | Expired Kerberos | | | client request | credentials | | 3 | Temporary problem with | Packet loss | | | client request | | | 4 | Permanent problem with the | Internal | | | server | misconfiguration | | 5 | Temporary problem with the | Server overloaded | | | server | | +------------+-----------------------------+------------------------+ If a client error is returned, the client SHOULD NOT retry the request unless some remedial action is first taken, although if error-code 3 is returned, the client MAY retry with other servers before giving up. If a server error is returned, it is RECOMMENDED that the client retry the request with a different server if one is known. Since all KCAs serving a Kerberos realm are intended to be equivalent, in accordance with Section 184.108.40.206 of [RFC5280], the certificates returned from different KCAs serving the same Kerberos realm MUST NOT contain duplicate serial numbers. This protocol and document do not address certificate verification or path construction. There are no provisions for returning any additional certificates that might be needed. Any application using a returned certificate must be configured independently to address these issues. An incompatible upgrade to this protocol will provide options to address this issue. The returned certificate MUST identify the Kerberos client principal from the AP-REQ in the original KX509Request in the subject of the certificate or in a subjectAltName extension. The identification MUST be unique within the organization's deployed infrastructure. It is RECOMMENDED that a subjectAltName extension be included of type id-pkinit-san as described in [RFC4556], Section 3.2.2. Note that the id-pkinit-san is simply a standard representation of a Kerberos principal and has no other implications with respect to PKINIT.
Other extensions MAY be added according to local policy. Appendix C shows an example reply packet. RFC2782]. The entry to be used is _kca._udp._realm_, where _realm_ is the Kerberos realm, used as part of the DNS name. The client has to acquire a service ticket in order to construct the AP-REQ for the service. Conventionally, the Kerberos service principal name to use for this service has a first component of "kca_service". Absent local configuration or other external knowledge of the correct principal to use, the second and final component is conventionally the canonical name of the KCA server being contacted, and the realm of the principal is determined following normal Kerberos domain-to-realm mapping conventions, as discussed in [RFC4120], Section 1.3. When the server receives a request, it MUST verify the following properties of the request before issuing a certificate: o The AP-REQ can be decoded and is not expired. o If the request uses cross-realm authentication, then it satisfies the requirements of local policy and [RFC4120], Sections 1.2 and 2.7.
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 the e-text if the hash is absent or does not verify but SHOULD indicate the message is not authenticated. KX509]. Many thanks to them for their original work, as well as the subsequent updates. While developing this document, important corrections and comments were provided by Jeffrey Altman and Love Hornquist Astrand. The following people also provided many helpful comments and corrections: Doug Engert, Jeffrey Hutzelman, Sam Hartman, Timothy J. Miller, Chaskiel Grundman, and Jim Schaad. Alan Sill provided the references to the International Grid Trust Federation and its acceptable credential services. Example network traffic was provided by Doug Engert, Marcus Watts, Matt Crawford, and Chaskiel Grundman from their deployments and was extremely useful for verifying the reality of this specification.
not meet the registry requirements. The Generic Security Service Application Program Interface (GSS-API) / Kerberos / Simple Authentication and Security Layer (SASL) service name currently in use for this protocol is "kca_service". This does not meet the naming requirements for IANA's GSS-API/Kerberos/SASL service name registry, so no registration has been requested. The conflict between the conventional service name and the registry rules is expected to be addressed in a future version of this protocol. Appropriate registrations will be requested at that time. RFC4211], Appendix C, contains a more detailed discussion of why proof-of- possession is important. An example that should be safe is initial client authentication with Transport Layer Security (TLS) [RFC5246] connections. If a client certificate is used, then a Certificate Verify message (Section 7.4.8 of [RFC5246]) is added to the handshake exchange. It includes a signature of the handshake messages to that point. Those messages depend on data known only to the client and server ends of the specific connection, so computing the signature proves possession of the private key. This application was the original intended use case for kx509. Some information, such as the public key and certificate, is transmitted in the clear but (as the name implies) is generally intended to be publicly available. However, its visibility could still raise privacy concerns. The hash is used to protect the integrity of this information.
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. In particular, 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. X.509 certificates are usually issued with considerably longer validity times than Kerberos tickets. Care should be taken that the issued certificate is not valid for longer than the intended policy should allow. Note that Section 3.2.3 of [RFC4556] REQUIRES that the lifetime of an issued ticket not exceed the lifetime of the predecessor certificate. By analogy, it is RECOMMENDED that the lifetime of an issued certificate not exceed the lifetime of the predecessor Kerberos ticket unless the implications with respect to local policy and supporting infrastructure are clearly understood and allow it. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [GRID-prof] "Grid Certificate Profile", March 2008, <http://www.ogf.org/documents/GFD.125.pdf>. [IGTF] "The International Grid Trust Federation", <http://www.igtf.net/>.
[KX509] Doster, W., Watts, M., and D. Hyde, "The KX.509 Protocol", September 2001, <http://www.citi.umich.edu/ techreports/reports/citi-tr-01-2.pdf>. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [SLCS] "Short Lived Credential Services", February 2009, <http://tagpma.org/authn_profiles/slcs>. [X.509] International Telecommunications Union, "Recommendation X.509: The Directory: Public-key and attribute certificate framework", November 2008.
0:d=0 hl=4 l= 678 cons: SEQUENCE 4:d=1 hl=4 l= 509 prim: OCTET STRING [HEX DUMP]:6E8201F9308201F5A003... (AP-REQ) 517:d=1 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:ECFF1C922300D0E9DD02... (pk-hash) 539:d=1 hl=3 l= 140 prim: OCTET STRING [HEX DUMP]:30818902818100B70F46... (pk-key) Request Packet ASN.1 Decode 0:d=0 hl=4 l= 870 cons: SEQUENCE 4:d=1 hl=2 l= 22 cons: cont [ 1 ] 6:d=2 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:F3A844834C26D843B6FD... (hash) 28:d=1 hl=4 l= 842 cons: cont [ 2 ] 32:d=2 hl=4 l= 838 prim: OCTET STRING [HEX DUMP]:308203423082022AA003... (certificate) Reply Packet ASN.1 Decode http://www.eyrie.org/~eagle/