Kerberos Working Group H. Hotz
Internet-Draft Jet Propulsion Laboratory,
Intended status: Informational California Institute of
Expires: May 12, 2011 Technology
November 8, 2010
KX509 Kerberized Certificate Issuance Protocol
draft-hotz-kx509-01.txt
Abstract
This rfc describes a protocol, called kx509, for using Kerberos
tickets to acquire X.509 certificates.
While not (previously) standardized, this protocol is already in use
at several large organizations, and certificates issued with this
protocol are recognized by TAGPMA (The Americas Grid Policy
Management Authority).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 12, 2011.
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
to this document. Code Components extracted from this document must
Hotz Expires May 12, 2011 [Page 1]
Internet-Draft KX509 November 2010
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 Simplified 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 . . . . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Certificate Cacheing and Deployment Considerations . 9
Appendix B. Known Issues with This Draft . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Hotz Expires May 12, 2011 [Page 2]
Internet-Draft KX509 November 2010
1. Introduction
The two primary ways of providing cryptographically secure
identification on the Internet are Kerberos tickets [RFC4120], and
X.509 [RFC5280] 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 May 12, 2011 [Page 3]
Internet-Draft KX509 November 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.
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 stored in this octet string in the request.
Use of other public-key types is not defined.
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.
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.
Hotz Expires May 12, 2011 [Page 4]
Internet-Draft KX509 November 2010
+-------------+--------+------+
| certificate | | hash |
| error-code | e-text | hash |
| error-code | e-text | |
+-------------+--------+------+
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] Section A, page 116.
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 4-byte
version ID at the beginning of the packet, the error-code (if
present), and all other optional fields which are present except the
hash itself. In other words, the hash is computed on the fields
which 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 NOT send a zero error-code. The
client MUST treat a missing error-code as if it were zero.
+------------+-----------------------------+------------------------+
| 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 | |
Hotz Expires May 12, 2011 [Page 5]
Internet-Draft KX509 November 2010
| 4 | Permanent problem with the | Internal |
| | server | misconfiguration |
| 5 | Temporary problem with the | Server overloaded |
| | server | |
+------------+-----------------------------+------------------------+
If error-code 1 or 2 is returned, the client SHOULD NOT retry the
request unless some remedial action is first taken. If error-code 3
is returned, the client MAY retry with any or all known 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. If all
known servers have returned server errors, the client MAY retry with
servers that returned an error-code of 5 before giving up.
Since all KCAs serving a Kerberos realm are intended to be
equivalent, in accordance with [RFC5280] Section 4.1.2.2, the
certificates returned from different KCAs serving the same Kerberos
realm MUST NOT contain duplicate serial numbers.
The returned certificate SHOULD identify the Kerberos client
principal from the ap-req in the original KX509Request in the subject
of the cert, or in a subjectAltName extension. It is RECOMMENDED
that the extension be 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. For example
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, and the Microsoft userPrincipalName
has sometimes been used for the same purpose as the id-pkinit-san.
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 provision for requests or replies which exceed the
allowable size of a UDP packet. Furthermore, 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
Hotz Expires May 12, 2011 [Page 6]
Internet-Draft KX509 November 2010
RECOMMENDED that service tickets for the KCA be issued without
authorization data, and that the KCA perform authorization 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 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:
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.
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.
While developing this document I received important corrections and
comments from Jeffrey Altman, and Love Hornquist Astrand. I also
Hotz Expires May 12, 2011 [Page 7]
Internet-Draft KX509 November 2010
received many helpful comments and corrections from Doug Engert,
Jeffrey Hutzelman, Sam Hartman, and Timothy J. Miller. Example
network traffic was provided by Doug Engert, Marcus Watts, and Matt
Crawford from their deployments, and was extremely useful to verify
the reality of this specification.
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 public key in the request is sent in the clear, and without any
guarantees that the requestor actually possesses the corresponding
private key. Therefore the only appropriate uses of the returned
certificate are those where the subsequent use independently
guarantees that the user possesses the private key. In particular
digitalSignature MUST NOT be an allowed key usage.
Some information, such as the public key and certificate, is
transmitted in the clear but (as the name implies) were designed to
be publicly available. However their visibility could still 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.
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. Since a PKINIT request must
be signed and digitalSignature is not an allowed usage for the issued
certificate, this loop should not occur.
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[RFC4556] Section 3.2.3.1 REQUIRES that the
lifetime of an issued ticket not exceed the lifetime of the
predecessor certificate. By analogy it is RECOMMENDED that the
Hotz Expires May 12, 2011 [Page 8]
Internet-Draft KX509 November 2010
lifetime of an issued certificate not exceed the lifetime of the
predecessor Kerberos ticket.
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.
[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.
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[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
[KX509] Doster, W., Watts, M., and D. Hyde, "The KX509 Protocol",
September 2001, <http://www.citi.umich.edu/techreports/
reports/citi-tr-01-2.pdf>.
[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 functional
lifetime of the acquired X.509 certificate should match the lifetime
of its predecessor Kerberos ticket. Therefore, it is likely that
X.509 certificates issued with this protocol should be deleted when
Hotz Expires May 12, 2011 [Page 9]
Internet-Draft KX509 November 2010
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 which supports the KX509-acquired credentials.
Appendix B. Known Issues with This Draft
1. This draft only describes the existing in-the-wild protocol,
which has some warts. We need an updated, standards-track
protocol.
2. Should IANA registration of a service port be requested?
3. Is there anything that should be added to clarify how Windows
might interact with this service? (e.g. more detail on SRV
records in section 3?)
4. Should timeouts be more fully specified? Should retry behavior
be less specified? Any other issues with error-handling?
5. Several people suggested more information be given on UDP size
restrictions and their effect on reliability. Is the text in
section 3 sufficient?
6. The original code has provisions for DSA private keys in addition
to RSA. Nobody seems to use DSA. Everyone seems to use RSA.
Should we specify DSA as an allowed alternative?
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 May 12, 2011 [Page 10]