From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6717.txt | 731 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 731 insertions(+) create mode 100644 doc/rfc/rfc6717.txt (limited to 'doc/rfc/rfc6717.txt') diff --git a/doc/rfc/rfc6717.txt b/doc/rfc/rfc6717.txt new file mode 100644 index 0000000..8bd72ff --- /dev/null +++ b/doc/rfc/rfc6717.txt @@ -0,0 +1,731 @@ + + + + + + +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 + +Abstract + + This 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. + + + +Hotz & Allbery Informational [Page 1] + +RFC 6717 kx509 August 2012 + + +Table of Contents + + 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 + +1. Introduction + + The two primary ways of providing cryptographically secure + identification on the Internet are Kerberos tickets [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]. + + + + + +Hotz & Allbery Informational [Page 2] + +RFC 6717 kx509 August 2012 + + + 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. + +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, respectively. + 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, and 0. + + Incompatible variations of this protocol MUST use a different major + version number. + +2.1. Request Packet + + The request consists of a version ID, followed by a DER-encoded ASN.1 + message containing a Kerberos AP-REQ, integrity check data on the + request, and 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. + + + + + + +Hotz & Allbery Informational [Page 3] + +RFC 6717 kx509 August 2012 + + + 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. + +2.2. Reply Packet + + The reply consists of a version ID, followed by a DER-encoded ASN.1 + message containing an error code, an optional authentication hash, + optional certificate, and optional error text. 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 independently optional + objects, the server MUST only generate replies with one of the + following allowed combinations. + + +------------+------+-------------+--------+ + | | hash | certificate | | + | error-code | hash | | e-text | + | error-code | | | e-text | + +------------+------+-------------+--------+ + + + + + + +Hotz & Allbery Informational [Page 4] + +RFC 6717 kx509 August 2012 + + + 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. + + + + + + + + +Hotz & Allbery Informational [Page 5] + +RFC 6717 kx509 August 2012 + + + 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 4.1.2.2 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. + + + + + + +Hotz & Allbery Informational [Page 6] + +RFC 6717 kx509 August 2012 + + + Other extensions MAY be added according to local policy. + + Appendix C shows an example reply packet. + +3. Protocol Operation + + Absent errors, the protocol consists of a single request, sent via + UDP, and a single reply, also sent via UDP. + + There is no special provision for requests or replies that exceed the + allowable size of a UDP packet. Also, some implementations have + imposed hard size limits that are smaller than a typical UDP MTU and + will limit the use of extensions and the supportable key size. Even + without hard limits, if the request or reply exceeds the MTU size of + a UDP packet for the infrastructure in use, then the reliability of + the exchange will decrease significantly. + + For "normal" Kerberos AP-REQ structures, and "normal" X.509 + certificates, this is unlikely unless the Kerberos service ticket + contains large amounts of authorization data. For this reason, it is + RECOMMENDED that service tickets for the KCA be issued without + authorization data. If the KCA performs authorization, it should do + so by other means. + + 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. + + 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. + + + +Hotz & Allbery Informational [Page 7] + +RFC 6717 kx509 August 2012 + + + 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. + +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, 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. + +5. IANA Considerations + + This service is conventionally run on UDP port 9878. IANA has + registered that port in the Service Name and Transport Port Number + Registry as follows: + + Service Name: kca-service + Transport Protocol: UDP + Assignee: IESG + Contact: IETF Chair + Description: The kx509 Kerberized Certificate Issuance + Protocol in Use in 2012 + Reference: RFC 6717 + Port Number: 9878 + Assignment Notes: Historically, this service has been referred to + as "kca_service", but this service name does + + + +Hotz & Allbery Informational [Page 8] + +RFC 6717 kx509 August 2012 + + + 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. + +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 public key in the request is sent in the clear and without any + guarantees that the requester actually possesses the corresponding + private key. Therefore, the only appropriate uses of the returned + certificate are those where the identity of the requester is + unimportant or the subsequent use independently guarantees that the + user possesses the private key. This issue is expected to be + addressed in a future version of this protocol. + + For example, if the kx509-issued certificate is used for a digital + signature in a way that does not independently demonstrate proof-of- + possession of the private key, then an eavesdropper could request + their own valid certificate via kx509 and claim to have originated + material signed by the legitimate, original requester. [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. + + + +Hotz & Allbery Informational [Page 9] + +RFC 6717 kx509 August 2012 + + + 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. + +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. + + [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. + +7.2. Informative References + + [GRID-prof] "Grid Certificate Profile", March 2008, + . + + [IGTF] "The International Grid Trust Federation", + . + + + + +Hotz & Allbery Informational [Page 10] + +RFC 6717 kx509 August 2012 + + + [KX509] Doster, W., Watts, M., and D. Hyde, "The KX.509 + Protocol", September 2001, . + + [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, + . + + [X.509] International Telecommunications Union, "Recommendation + X.509: The Directory: Public-key and attribute + certificate framework", November 2008. + + + + + + + + + + + + + + + + + + + + + + + + + +Hotz & Allbery Informational [Page 11] + +RFC 6717 kx509 August 2012 + + +Appendix A. Certificate Caching and Deployment Considerations + + As noted in the Security Considerations section, the functional + lifetime of the acquired X.509 certificate should usually match the + lifetime of its predecessor Kerberos ticket. Therefore, it is likely + that X.509 certificates issued with this protocol should be deleted + when the supporting Kerberos tickets are deleted. That makes the + Kerberos ticket cache a reasonable location to store the certificate + (and its private key). + + On the other hand, applications, such as web browsers, probably + expect certificates in different stores. + + A widely used solution to this dichotomy is to implement a PKCS11 + library that supports the kx509-acquired credentials. The + credentials remain stored in the Kerberos credentials cache, but full + PKI functionality is still available via a standard interface for PKI + credentials. + +Appendix B. Historic Extensions + + This appendix documents extensions to the kx509 protocol that are + either no longer in use or are expected to be dropped. + + A subjectAltName othername extension of type kcaAuthRealm (OID value + 1.3.6.1.4.1.250.42.1) is frequently used to include the client's + realm as an ASN.1 octet string. + + The Microsoft-defined userPrincipalName has frequently been used for + the same purpose as the id-pkinit-san. + + The historic implementations of this protocol included provisions for + DSA keys in place of RSA. DSA does not appear to be in use. A + future version of this protocol will use a standard certificate + request structure that will provide algorithm agility. + + The historic implementations of this protocol allowed an optional + client-version field (at the end of the request) of type + VisibleString. If present, the KCA copied it into the issued + certificate as an extension with the OID 1.3.6.1.4.1.250.42.2. This + feature does not appear to be in use. + +Appendix C. Example Exchange + + The request and reply are from the same exchange. The Ethernet, IP, + and UDP headers, and the 4-byte version string at the beginning of + the request and reply packets are all omitted. Only the ASN.1- + encoded portions are shown. + + + +Hotz & Allbery Informational [Page 12] + +RFC 6717 kx509 August 2012 + + + 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 + +Authors' Addresses + + Henry B. Hotz + Jet Propulsion Laboratory, California Institute of Technology + 4800 Oak Grove Dr. + Pasadena, CA 91109 + USA + + Phone: +01 818 354-4880 + EMail: hotz@jpl.nasa.gov + + + Russ Allbery + Stanford University + P.O. Box 20066 + Stanford, CA 94309 + USA + + EMail: rra@stanford.edu + URI: http://www.eyrie.org/~eagle/ + + + + + + + + + + + +Hotz & Allbery Informational [Page 13] + -- cgit v1.2.3