Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

kx509 Kerberized Certificate Issuance Protocol in Use in 2012
RFC 6717

Document	Type	RFC - Informational (August 2012) Was draft-hotz-kx509 (individual)
	Authors	Henry Hotz , Russ Allbery
	Last updated	2018-12-20
	RFC stream	Independent Submission
	Formats	txt html pdf htmlized bibtex
IESG	Responsible AD	Stephen Farrell
	Send notices to	(None)

Email authors IPR References Referenced by Search Lists

RFC 6717

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.

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", lt;------| Itf. | Interest | NACK |
| V V |
| |
+-----------------------------------------------------------------+

Figure 1: ICN forwarder structure

Given the above forwarding properties for Interests, it should be
clear that while an Interest is outstanding and ultimately arrives at

Oran & Kutscher Expires 4 October 2020 [Page 7]
Internet-Draft ICN Reflexive Forwarding April 2020

a producer who can respond to it, there is sufficient state in the
chain of forwarders to route not just a returning Data message, but
potentially another Interest directed through the inverse path to the
unique consumer who issued the original Interest. (Section 8.1.3
describes how Interest aggregation interacts with this scheme.) The
key question therefore is how to access this state in a way that it
can be used to forward Interests.

In order to achieve this _Reflexive Interest_ forwarding on the
inverse path recorded in the PIT of each forwarder, we need a few
critical design elements. These are as follows:

1. The Reflexive Interest needs to have a Name. This name is what
the originating consumer will use to match against the Data
object (or objects - more on this later) it wishes the producer
to fetch by issuing the Reflexive Interest. This cannot be just
any name, but needs to essentially name the state already
recorded in the PIT and not allow the consumer to manufacture an
arbitrary name and mount a reflection attack as pointed out in
Section 1.2, Paragraph 2, Item 2.

2. There has to be a FIB entry at each forwarder for this name
prefix so that when the reflexive interest arrives, the forwarder
can forward it downstream toward the originating consumer. This
FIB entry points directly to the incoming interface on which the
corresponding original Interest arrived. The FIB entry needs to
be created as part of the forwarding of the original Interest so
that it is available in time to catch any reflexive Interest
issued by the producer. It usually makes sense to destroy this
FIB entry when the Data message satisfying the original Interest
arrives since this avoids any dangling stale state. Given the
deign details documented later in this specification, stale FIB
state does not represent a correctness hazard and hence can be
done lazily if desired in an implementation. See Section 5 for
more details on FIB operation considerations.

3. There has to be coupling of the state between the originating
Interest-Data exchange and the enclosed Reflexive Interest-Data
exchange at both the consumer and the producer. In our design,
this accomplished by the way reflexive interest names are chosen.

The following sections provide the normative details on each of these
design elements. The overall interaction flow for reflexive
forwarding is illustrated below in Figure 2.

Oran & Kutscher Expires 4 October 2020 [Page 8]
Internet-Draft ICN Reflexive Forwarding April 2020

+-----------+ +-----------+ +-----------+
| Consumer | | Forwarder | | Producer |
+-----------+ +-----------+ +-----------+
| | |
| I1 | |
|--------------->| |
|--------------\ | |
|| Install RNP |-| |
|| in FIB | | |
||-------------| | |
| | |
| | I1 |
| |----------------------------->|
| | | -----------\
| | |-| Create |
| | | | RI state |
| | | |----------|
| | |
| | RI |
| |<-----------------------------|
| | --------------------\ |
| |-| lookup RNP in FIB | |
| | |-------------------| |
| | |
| RI | |
|<---------------| |
| | |
| D2 | |
|--------------->| |
| | |
| | D2 |
| |----------------------------->|
| | | ------------\
| | |-| answer I1 |
| | | |-----------|
| | |
| | D1 |
| |<-----------------------------|
| | -----------------------\ |
| |-| remove RNP FIB entry | |
| | |----------------------| |
| | |
| D1 | |
|<---------------| |
| | |

Oran & Kutscher Expires 4 October 2020 [Page 9]
Internet-Draft ICN Reflexive Forwarding April 2020

Legend:
I1: Interest #1 containing the Reflexive Name Prefix TLV
RI: Reflexive Interest with Reflexive Name Prefix Component
RNP: Reflexive Name Prefix
D1: Data message, answering initiating I1 Interest
D2: Data message, answering RI

Figure 2: Message Flow Overview

4. Naming of Reflexive Interests

A consumer may have one or more objects for the producer to fetch,
and therefore needs to communicate enough information in their
initial Interest to allow the producer to construct properly formed
reflexive Interest names. For some applications the set of _full
names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, for
example through compile time bindings of arguments in interface
definitions or by the architectural definition of a simple sensor
reading. In other cases the full names of the individual objects
must be communicated in the original Interest message. In all cases
enough state must be provided by the consumer for the forwarders to
construct a FIB entry (as noted in Section 3, Paragraph 6, Item 2).
This is accomplished through the following naming construct.

We define a new typed name component, identified by a registered name
component type in the IANA registry for [RFC8569]. We call this the
_Reflexive Interest Name Component type_. It MUST be the first (i.e.
high order) name component of any Reflexive Interest issued by a
producer. Its value is a random 64 bit number, assigned by the
consumer, which provides the entropy required to uniquely identify
the issuing consumer for the duration of any outstanding Interest-
Data exchange. The consumer SHOULD choose a different random value
for each Interest message it constructs, for two reasons:

1. If stale FIB sate is present, the randomness prevents potential
mis-routing of reflexive interests (see Section 8.1.1 below for
more details), and

2. Re-use of the same reflexive interest name over multiple
interactions might reveal linkability information that could be
used by surveillance adversaries for tracking purposes.

This initial name component is either communicated by itself through
a _Reflexive Name Prefix TLV_ in the originating Interest, or
prepended to any object names the consumer wishes the producer to
fetch explicitly where there is more than one object needed by the
producer for the current Interest-Data interaction. There are four
cases to consider:

Oran & Kutscher Expires 4 October 2020 [Page 10]
Internet-Draft ICN Reflexive Forwarding April 2020

1. The reflexive _fullname_ of a single object to fetch.

2. A single reflexive name prefix out of which the producer can (by
application-specific means) construct a number of _fullnames_ of
the objects it may want to fetch,

3. The reflexive _fullname_ of a FLIC Manifest [I-D.irtf-icnrg-flic]
enumerating the suffixes that may be used by the producer to
construct the necessary names,

4. Multiple reflexive name TLVs MAY be included in the Interest
message if none of the above 3 options covers the desired use
case.

The last of the four options above, while not explicitly outlawed,
SHOULD NOT be used. This is because it results in a longer Interest
message and requires extra FIB resources. Hence, it is more likely a
forwarder will reject the Interest for lack of resources. A
forwarder MAY optimize for the case of a single Reflexive Name TLV at
the expense of those with more than one.

A producer, upon receiving an Interest with one or more Reflexive
Name TLVs, may decide it needs the pull the associated data
object(s). It therefore can issue one or more Reflexive Interests by
appending the necessary name components needed to form valid full
names of the associated objects present at the originating consumer.
These in fact comprise conventional Interest-Data exchanges, with no
alteration of the usual semantics with regard to signatures, caching,
expiration, etc. When the producer has retrieved the required
objects to complete the original Interest-Data exchange, it can issue
its Data response, which unwinds all the established state at the
producer, the consumer, and the intermediate forwarders.

5. Forwarder operation for Reflexive Interests

The forwarder operation for CCNx and/or NDN is changed in three
respects when supporting Reflexive Interests.

1. The forwarder MUST create short-lifetime FIB entries for any
Reflexive Interest Name prefixes communicated in an Interest
message. If the forwarder does not have sufficient resources to
do so, it MUST reject the Interest with the T_RETURN_NO_RESOURCES
error - the same error used if the forwarder were lacking
sufficient PIT resources to process the Interest message.

2. Those FIB entries MUST be queried whenever an Interest message
arrives whose first name component is of the type _Reflexive
Interest Name Component_

Oran & Kutscher Expires 4 October 2020 [Page 11]
Internet-Draft ICN Reflexive Forwarding April 2020

3. The FIB entry MUST be removed eventually, after the corresponding
Data message has been forwarded. One option would be to remove
the FIB directly after the Data message has been forwarded.
However, the forwarder MAY do lazy cleanup.

The PIT entry for the Reflexive Interest is consumed per regular
Interest/Data message forwarding requirements. The PIT entry for the
originating Interest (that communicated the Reflexive Interest Name)
is also consumed by a final Data message from the producer to the
original consumer.

6. State coupling between producer and consumer

A consumer that wishes to use this scheme MUST utilize one of the
reflexive naming options defined in Section 4 and include it in the
corresponding Interest message. The Reflexive Name TLV _and_ the
full name of the requested data object (that identifies the producer)
identify the common state shared by the consumer and the producer.
When the producer responds by sending Interests with the Reflexive
Name Prefix, the original consumer therefore has sufficient
information to map these Interests to the ongoing Interest-Data
exchange.

The exchange is finished when the producer who received the original
Interest message responds with a Data message (or an Interest Return
message in the case of error) answering the original Interest. After
sending this Data message, the producer SHOULD destroy the
corresponding shared state. It MAY decide to use a timer that will
trigger a later state destruction. After receiving this Data
message, the originating consumer MUST destroy the corresponding
Interest-Data exchange state.

7. Use cases for Reflexive Interests

7.1. Achieving Remote Method Invocation with Reflexive Interests

RICE (Remote Method Invocation in ICN) [Krol2018] uses the Reflexive
Interest Forwarding scheme that inspired the design specified in this
document.

In RICE, the original Interest denotes the remote method (plus
potential parameters) to be invoked at a producer (server). Before
committing any computating resources, the server can then request
authentication credentials and (optional) parameters using reflexive
Interest-Data exchanges.

When the server has obtained the necessary credentials and input
parameters, it can decide to commit computing resources, starts the

"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.

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:

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 <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>
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,
<http://www.ogf.org/documents/GFD.125.pdf>.

[IGTF] "The International Grid Trust Federation",
<http://www.igtf.net/>.

Hotz & Allbery Informational [Page 10]
RFC 6717 kx509 August 2012

[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.

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]

kx509 Kerberized Certificate Issuance Protocol in Use in 2012 RFC 6717

kx509 Kerberized Certificate Issuance Protocol in Use in 2012
RFC 6717