diff options
Diffstat (limited to 'source4/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt')
-rw-r--r-- | source4/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt | 728 |
1 files changed, 728 insertions, 0 deletions
diff --git a/source4/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt b/source4/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt new file mode 100644 index 00000000000..e43aadee30e --- /dev/null +++ b/source4/heimdal/doc/standardisation/draft-lha-krb-wg-ticket-extensions-00.txt @@ -0,0 +1,728 @@ + + + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + +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] + |