HEIMDAL: move code from source4/heimdal* to third_party/heimdal*

[samba.git] / third_party / heimdal / doc / standardisation / draft-lha-krb-wg-ticket-extensions-00.txt

Network Working Group                               L. Hornquist Astrand
Internet-Draft                                                Apple, Inc
Intended status: Standards Track                         August 13, 2008
Expires: February 14, 2009


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

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 14, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).














Hornquist Astrand       Expires February 14, 2009               [Page 1]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


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  . . . . . . . . . . . . . . . . . . . .  3
   2.  Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  How to request a new assignment for a ticket extension . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Ticket-extensions ASN.1 Module  . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13



























Hornquist Astrand       Expires February 14, 2009               [Page 2]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


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














































Hornquist Astrand       Expires February 14, 2009               [Page 3]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


2.  Protocol

   The ticket and enc-part as defined by [RFC4120] 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 extensions types (te-type) is private extensions and



Hornquist Astrand       Expires February 14, 2009               [Page 4]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


   MUST only be used for experimentation.

   The te-type field is specificing 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 (usually the session
   key of the ticket) and the key usage number.

   The KDC MUST only return this extension in the AS-REQ if all other
   KDCs for the same realm also supports this extension.

   The KDC MUST only return this extension in the TGS-REQ to server the
   KDC knows supports these extension.  This includes both cross realm
   tickets and service tickets.

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
































Hornquist Astrand       Expires February 14, 2009               [Page 5]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


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.





























Hornquist Astrand       Expires February 14, 2009               [Page 6]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


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.












































Hornquist Astrand       Expires February 14, 2009               [Page 7]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


5.  Acknowledgements

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















































Hornquist Astrand       Expires February 14, 2009               [Page 8]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


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

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




































Hornquist Astrand       Expires February 14, 2009               [Page 9]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


7.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.







































Hornquist Astrand       Expires February 14, 2009              [Page 10]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


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] krb5int32,
        te-data [1] OCTET STRING
        te-csum [2] Checksum
}

END


















Hornquist Astrand       Expires February 14, 2009              [Page 11]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


Author's Address

   Love Hornquist Astrand
   Apple, Inc
   Cupertino
   USA

   Email: lha@apple.com











































Hornquist Astrand       Expires February 14, 2009              [Page 12]
\f
Internet-Draft         Kerberos ticket extensions            August 2008


Full Copyright Statement

   Copyright (C) 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Hornquist Astrand       Expires February 14, 2009              [Page 13]
\f