One document matched: draft-ietf-krb-wg-naming-01.txt

Differences from draft-ietf-krb-wg-naming-00.txt

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                     Microsoft Corporation
Updates: 4120 (if approved)                             October 10, 2006
Intended status: Standards Track
Expires: April 13, 2007


                 Additional Kerberos Naming Constraits
                      draft-ietf-krb-wg-naming-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 April 13, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines new naming constraints for reserved Keberos
   names.  A reserved name can be either a Kerberos principal name or a
   Kerberos realm name.  All reserved names defined in this document are
   critical, so if a reserved name is unknown, authentication MUST fail.






Zhu                      Expires April 13, 2007                 [Page 1]

Internet-Draft               Kerberos Naming                October 2006


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
   3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Reserved Kerberos Principal Names . . . . . . . . . . . . . 3
     3.2.  Reserved Kerberos Realm Names . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 6






































Zhu                      Expires April 13, 2007                 [Page 2]

Internet-Draft               Kerberos Naming                October 2006


1.  Introduction

   Occasionally protocol designers need to designate a Kerberos
   principal name or a Kerberos realm name to have special meanings,
   other than identifying a particular instance.  An example is that the
   the anonymous principal name and the anonymous realm name are defined
   for the Kerberos anonymity support [ANON].  This anonymity name pair
   conveys no more meaning than that the client's identity is not
   disclosed.  In the case of the anonymity support, it is critical that
   deployed Kerberos implementations that do not support anonymity MUST
   fail the authentication if the anonymity name pair is used, therefore
   no access is granted accidentally to a principal who's name happens
   to match with that of the anonymous identity.

   However Kerberos as defined in [RFC4120] does not have such reserved
   names.  As such, protocol designers have resolved to use exceedingly-
   unlikely-to-have-been-used names to avoid collision.  Even if a
   registry were setup to avoid collision for new implementations, there
   is no guarantee for deployed implementations to prevent accidental
   reuse of names that can lead to access being grantedly unexpectedly.

   The Kerberos realm name in [RFC4120] has a reserved name space
   although no specific name is defined and the criticality of unknown
   reserved realm names is not specified.

   This document is to remedy these by defining reserved Kerberos names.
   All reserved names defined based on this specification are critical:
   Authentication MUST fail if an unknown reserved name is used by
   conforming implementations.


2.  Conventions Used in This Document

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


3.  Definitions

   In this section, reserved names are defined for both the kerberos
   principal name and the kerberos realm name.

3.1.  Reserved Kerberos Principal Names

   A new name type is defined for reserved principal names.  The
   Kerberos principal name is defined in Section 6.2 of [RFC4120].




Zhu                      Expires April 13, 2007                 [Page 3]

Internet-Draft               Kerberos Naming                October 2006


            KRB_NT_RESERVED                                TBA

   The reserved principal name MUST have at least two or more
   KerberosString components, and the first component must be the string
   literal "RESERVED".

   For implementations conforming with this specification,
   authentication MUST fail with
   KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN if an unknown reserved
   principal name is used.  There is no accompanying error data for this
   error.

            KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN     TBA
                 -- a reserved Kerberos principal name is unknown

3.2.  Reserved Kerberos Realm Names

   Section 6.1 of [RFC4120] defines the "other" style realm name, a new
   type RESERVED is defined as a name of type "other", with the NAMETYPE
   part filled in with the word "RESERVED".

            other: RESERVED:realm-name

   This name type is designated for reserved Kerberos realms.

   For implementations conforming with this specification,
   authentication MUST fail with KRB_AP_ERR_RESERVED_REALM_NAME_UNKNOWN
   if an unknown reserved realm name is used.  There is no accompanying
   error data for this error.

            KRB_AP_ERR_RESERVED_REALM_NAME_UNKNOWN         TBA
                 -- a reserved Kerberos realm name is unknown


4.  Security Considerations

   If a reserved name is unknown, authentication MUST fail.  Otherwise,
   access can be granted unintentionally, resulting in a security
   weakness.

   Care MUST be taken to avoid accidental reuse of names.


5.  Acknowledgements

   The initial document was mostly based on the author's conversation
   with Clifford Newman and Sam Hartman.




Zhu                      Expires April 13, 2007                 [Page 4]

Internet-Draft               Kerberos Naming                October 2006


6.  IANA Considerations

   This document provides the framework for defining reserved Kerberos
   names and Kerberos realms.  A new IANA registry should be created to
   contain reserved Kerberos names and Kerberos realms that are defined
   based on this document.


7.  Normative References

   [ANON]     Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 
              Support", draft-ietf-krb-wg-anon, work in progress.

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

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

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


Author's Address

   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: lzhu@microsoft.com



















Zhu                      Expires April 13, 2007                 [Page 5]

Internet-Draft               Kerberos Naming                October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

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





Zhu                      Expires April 13, 2007                 [Page 6]