Kerberos ticket extensions
draft-lha-krb-wg-ticket-extensions-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on February 19, 2009.

Abstract

The Kerberos protocol does not allow ticket extensions. This make it harder to deploy features like referrals and PKCROSS.

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.

Table of Contents

1.  Requirements Notation
2.  Protocol
3.  How to request a new assignment for a ticket extension
4.  Security Considerations
5.  Acknowledgements
6.  IANA Considerations
7.  Normative References
Appendix A.  Ticket-extensions ASN.1 Module
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Requirements Notation

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Protocol

The ticket and enc-part as defined by [RFC4120] (Neuman, C., Yu, T., Hartman, S., and K. Raeburn, “The Kerberos Network Authentication Service (V5),” July 2005.) is defined as follow:

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
}

This document uses the special encryption type etype-TBETicket to signal that enc-part.cipher contains the DER-encoded TBETicket structure, instead of an encrypted EncTicketPart.

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

}

TicketExtension ::= SEQUENCE {
        te-type [0] krb5int32,
        te-data [1] OCTET STRING
        te-csum [2] Checksum OPTIONAL
}

The content of cipher data and encryption type fields is moved inside TBETicket.

Negative ticket extension types (te-type) is private extensions and MUST only be used for experimentation or private use.

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.

The te-csum field is optional for the type, when in use by type type specifed in te-type, the key have to be specifed and the key usage number. 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 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.

The KDC MAY return extended tickets to servers supporting ticket extensions even if the extended ticket does not contain any extensions.

3.  How to request a new assignment for a ticket extension

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:

      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

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.

When reviewing the document, the reviewer should take sure to check that if te-csum is used, the siging key and key usage is specifed.

4.  Security Considerations

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.

Some of the issues that the exensions need to protect themself from are: MITM downgrade to normal ticket, add or remove extentions, cut and paste extensions between requests, retransmission of requqests to a diffrent KDC.

5.  Acknowledgements

Thanks to Leif Johansson, Kamada Ken'ichi, and Ken Raeburn for reviewing the document and provided suggestions for improvements.

6.  IANA Considerations

There are currently no ticket extensions. Future ticket extensions will be published at:

      http://www.iana.org/assignments/NNNNNNNN
      -- IANA: please name registry, proposal: krb5-ticket-extensions

IANA is requested to maintain this registry for future assignments. New assignments can only be made via Specification Required as described in [RFC2434] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.).

IANA will assign the number as part of the RFC publication process.

7. Normative References

Appendix A.  Ticket-extensions ASN.1 Module

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) }


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

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.