One document matched: draft-ietf-krb-wg-ticket-extensions-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2434 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml'>
<!ENTITY rfc4120 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
]>
<rfc category="std" ipr="full3978" docName="draft-ietf-krb-wg-ticket-extensions-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<front>
<title>Kerberos ticket extensions</title>
<author initials='L' surname="Hornquist Astrand" fullname='Love Hornquist Astrand'>
<organization>Apple, Inc</organization>
<address>
<postal>
<street/>
<city>Cupertino</city> <code/>
<country>USA</country>
</postal>
<email>lha@apple.com</email>
</address>
</author>
<date month="November" year="2008"/>
<abstract>
<t>
The Kerberos protocol does not allow ticket extensions. This
make it harder to deploy features like PKCROSS.
</t>
<t>
Since the Kerberos protocol did not specified extensibility
for the Ticket structure and the current implementations are
aware of the contents of tickets, the extension protocol
cannot simply extend the Ticket ASN.1 structure. Instead, the
extension data needs to be hidden inside the ticket.
</t>
<t>
This protocol defines two methods to add extend the
tickets. The first method requires updated clients and is more
in line with the future development of Kerberos. The second
way does not require update client. To take advantage of this
protocol the server (KDC or application server) need to update
a well. The two methods are equivalent and there is a 1-1
mapping between them.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Notation">
<t>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 <xref target="RFC2119"/>.</t>
</section>
<section title="Background">
<t>
The ticket and enc-part as defined by <xref target="RFC4120"/>
is defined as follow:
<figure>
<artwork>
<![CDATA[
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno [0] INTEGER (5),
realm [1] Realm,
sname [2] PrincipalName,
enc-part [3] EncryptedData -- EncTicketPart
}
EncryptedData ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
kvno [1] UInt32 OPTIONAL,
cipher [2] OCTET STRING -- ciphertext
}
]]>
</artwork>
</figure>
The reason that the ticket can't be extended is that Kerberos
clients parses the returned ticket and any additions field
will not be preserved.
</t>
</section>
<section title="Extending the ticket">
<t>
This document describe two methods to extend tickets in
<xref target="extendingticket"/> and
<xref target="backwardcompat"/>. The two methods are
equivalent and there is a 1-1 mapping between them, copy the
fields into the respetive fields. Anyone that creates
protocols that uses ticket extentions MUST support the
<xref target="backwardcompat"/> and SHOULD support both, ie,
not depend on the encoding of the Ticket structure itself.
</t>
<section title="Update Kerberos 5 ticket" anchor="extendingticket">
<t>
The first method to extend the ticket is add a new field,
ext-data that extends the ticket with an array of type-value
ticket extensions.
<figure>
<artwork>
<![CDATA[
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno[0] Int32,
realm[1] Realm,
sname[2] PrincipalName,
enc-part[3] EncryptedData
ext-data[4] SEQUENCE OF TicketExtension OPTIONAL
}
]]>
</artwork>
</figure>
</t>
<t>
The client signals support by sending the PA-DATA type
pa-data-Client-Extensions setting the bit
Client-Extensions-support-et-ticket (the zero bit) to 1.
</t>
<t>
XXX write IANA registration for pa-data-Client-Extensions.
Require standard action, private/experimental gets to use
their define their own pa data.
</t>
<t>
If the KDC implement any protocols that uses Ticket
extentions, it MUST implement this method. Clients MAY
support it. Servers MUST support if they told the KDC they
support the extended keys via an administative command.
</t>
</section>
<section title="Backward compatible format" anchor="backwardcompat">
<t>
The second method is the backward compatible ticket that
doesn't change the format of the Ticket structure uses hides
the extension data inside the enc-part of the ticket.
</t>
<t>
It does this by using a special encryption type
etype-TBETicket to signal that enc-part.cipher contains the
DER-encoded TBETicket structure, instead of an encrypted
EncTicketPart.
</t>
<t>
<figure>
<artwork>
<![CDATA[
etype-TBETicket INTEGER ::= 4711 -- TBA XXX --
krb5int32 ::= INTEGER (-2147483648..2147483647)
TBETicket ::= SEQUENCE {
etype [0] krb5int32 -- EncryptionType --,
cipher [1] OCTET STRING
extensions [2] SEQUENCE OF TicketExtension OPTIONAL
}
]]>
</artwork>
</figure>
</t>
<t>
The content of cipher data and encryption type fields is moved
inside TBETicket. The kvno field is not moved and have the
same mening as before.
</t>
<t>
If the KDC implement this protocol, it MUST support this
method, Clients MAY support it. Servers MUST support if they
told the KDC they support the extended keys via an
administative command.
</t>
</section>
</section>
<section title="Ticket extentions">
<t>
Ticket extentions are for communicating between the KDC and
the service/KDC the ticket is for. Clients and 4th parties can
read the data, but should do no attempt to modify, remove or
add extentions.
</t>
<t>
The ticket extentions them self is defined as follows:
<figure>
<artwork>
<![CDATA[
TicketExtension ::= SEQUENCE {
te-type [0] krb5int32,
te-data [1] OCTET STRING
te-csum [2] Checksum OPTIONAL,
te-kvno [3] krb5int32 OPTIONAL
}
]]>
</artwork>
</figure>
</t>
<t>
Negative ticket extension types (te-type) is private
extensions and MUST only be used for experimentation or
private use.
</t>
<t>
The te-type field specifies the type of the content in
te-data. Unknown te-types MUST be ignored both by the client
and the server.
</t>
<t>
The te-csum field is optional for the type, specified by each
ticket extension type. The ticket extension type have to be
specified and the key usage number to use for the check
sum. The key is usually the session key of the ticket, but
doesn't have to be, an extension could specify an new session
key used for the ticket. The data that is signed is also
specifed specific type.
</t>
<t>
The (te-kvno) field is to allow changing keys if they keys is
some unrelated key.
</t>
<t>
The KDC MUST NOT use extended ticket in an AS or TGS reply
unless it is known that all instances of the service in
question support it. In particular, a (local or cross-realm)
TGT MUST NOT use extended tickets unless all of the KDCs to
which it may be sent are known to support it.
</t>
<t>
The KDC MAY return extended tickets to servers supporting
ticket extensions even if the extended ticket does not contain
any extensions.
</t>
</section>
<section title="How to request a new assignment for a ticket extension">
<t>
When anyone is writing a Internet-draft for which a new
assignment for te-type is needed/wanted under the ticket
extension, then the proper way to do so is as follows:
<figure>
<artwork>
<![CDATA[
EXAMPLE-MODULE DEFINITIONS ::= BEGIN
krb5-ticket-extension-Name ::= INTEGER nnn
-- IANA: please assign nnn
-- RFC-Editor: replace nnn with IANA-assigned
-- number and remove this note
END
]]>
</artwork>
</figure>
IANA: Don't do note above, its an example, remove this note
RFC-Editor: Don't do note above, its an example, remove this note
IANA will assign the number as part of the RFC publication process.
</t>
<t>
When reviewing the document, the reviewer should take sure to
check that if te-csum is used, the signing key and key usage
is specified. The data that is signed also needs to be specified.
</t>
</section>
<section title="Security Considerations">
<t>
This document describes how to extend Kerberos tickets to
include additional data in the ticket. This does have a
security implications since the extension data in the
TBETicket is only optionally signed, not encrypted and is not
replay protected. It is up to the consumers of this interface
to make sure its used safely.
</t>
<t>
Some of the issues that the extensions need to protect them self
from are: MITM downgrade to normal ticket, add or remove
extensions, cut and paste extensions between requests,
retransmission of requests to a different KDC. The data is
sent in clear text, so can should be taken to not send private data.
</t>
<t>
The ticket extension is mainly to communicate information from
the KDC to the server. The information can either be protected
by the session key, or the key of the server. If its protected
by the session key they both the client and the server can
modify the data, and if its protected the servers key is can
modified by the server. Any extension using Kerberos extension
needs to define what the data is needs protection from.
</t>
</section>
<section title="Acknowledgements">
<t>
Thanks to Leif Johansson, Kamada Ken'ichi, and Ken Raeburn for
reviewing the document and provided suggestions for
improvements.
</t>
</section>
<section title="IANA Considerations">
<t>
There are currently no ticket extensions. Future ticket extensions will be published at:
<figure>
<artwork>
<![CDATA[
http://www.iana.org/assignments/NNNNNNNN
-- IANA: please name registry, proposal: krb5-ticket-extensions
]]>
</artwork>
</figure>
IANA is requested to maintain this registry for future assignments.
New assignments can only be made via Specification Required as described in
<xref target="RFC2434"/>.
</t>
<t>
IANA will assign the number as part of the RFC publication process.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2434;
&rfc4120;
</references>
<section title="Ticket-extensions ASN.1 Module">
<t>
<figure>
<artwork>
<![CDATA[
KerberosV5-TicketExtensions {
iso(1) identified-organization(3) dod(6) internet(1)
security(5) kerberosV5(2) modules(4) ticket-extensions(TBA)
--- XXX who is the registerar for this number ?
} DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS
-- as defined in RFC 4120
Int32, Checksum
FROM KerberosV5Spec2 { iso(1) identified-organization(3)
dod(6) internet(1) security(5) kerberosV5(2)
modules(4) krb5spec2(2) }
pa-data-Client-Extensions INTEGER ::= 4710 -- XXX TBA --
PA-DATA-CLIENT-EXTENSIONS ::= BIT STRING
Client-Extensions-support-et-ticket INTEGER ::= 1
Ticket ::= [APPLICATION 1] SEQUENCE {
tkt-vno[0] Int32,
realm[1] Realm,
sname[2] PrincipalName,
enc-part[3] EncryptedData
ext-data[4] SEQUENCE OF TicketExtension OPTIONAL
}
etype-TBETicket INTEGER ::= 4711 -- XXX TBA --
TBETicket ::= SEQUENCE {
etype [0] Int32 -- EncryptionType --,
cipher [1] OCTET STRING
extensions [2] SEQUENCE OF TicketExtension OPTIONAL
}
TicketExtension ::= SEQUENCE {
te-type [0] Int32,
te-data [1] OCTET STRING
te-csum [2] Checksum
}
END
]]>
</artwork>
</figure>
</t>
</section>
<section title="Changes">
<t>
RFC-EDITOR: please remove this section.
</t>
<t>
<list style="symbols">
<t>
Version lha-krb-wg-ticket-extensions-00 - initial version,
after review of Leif Johansson, Kamada Ken'ichi
</t>
<t>
Version lha-krb-wg-ticket-extensions-01 - comments from Ken
Raeburn: experimentation or private use, attack types,
asn1. nits.
</t>
<t>
Version lha-krb-wg-ticket-extensions-02 - comments from Ken
Raeburn: new format for the Ticket PDU message. protocol neg
from the client via pa-data. kvno is Ticket.enc-data, added
kvno for te-csum field. Clearifed between what parties the
messages are for.
</t>
<t>
Version ietf-krb-wg-ticket-extensions-00 - make the Backward
compatible format default and MUST support. KDC must always
support both. Comment from Sam Hartman.
</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:36:22 |