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

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                     Microsoft Corporation
Updates: 4120 (if approved)                                 June 2, 2006
Expires: December 4, 2006


                 Additional Kerberos Naming Constraits
                      draft-ietf-krb-wg-naming-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 December 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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






Zhu                     Expires December 4, 2006                [Page 1]

Internet-Draft               Kerberos Naming                   June 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  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7






































Zhu                     Expires December 4, 2006                [Page 2]

Internet-Draft               Kerberos Naming                   June 2006


1.  Introduction

   Occasionally protocol designers need to designate a Kerberos
   principal name name or a Kerberos realm name to have special
   meanings, other than identifying a particular instance.  An example
   is that the protocol designers for the Kerberos anonymity support
   [ANON] need to define the Kerberos anonymous principal name and the
   Kerberos anonymous realm name, such that the anonymous name pair
   conveys no more meaning than that the client's identity is not
   revealed.  In that case, it is critical that deployed Kerberos
   implementations MUST fail the authentication so that no access can be
   accidentally granted 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
   name spaces.  As such, protocol designers have resolved to use
   exceedingly-unlikely-to-have-been-used names to avoid collision.
   Even if a registry can be setup to avoid collision for new
   implementations, there is no collision-free guarantee for deployed
   implementations.  Accidental reuse of names can result in a security
   weakness.

   The Kerberos realm name has a reserved name space but none is defined
   and the criticality of unknown reserved realm names is not
   sufficiently specified.

   This document is to remedy that by defining the reserved name spaces
   for Kerberos names and these names are critical so that
   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 the reserved principal name as defined
   in Section 6.2 of [RFC4120].



Zhu                     Expires December 4, 2006                [Page 3]

Internet-Draft               Kerberos Naming                   June 2006


            KRB_NT_RESRVED                                 16

   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     82
                 -- a reserved Kerberos principal name is unknown

3.2.  Reserved Kerberos Realm Names

   A new reserved realm name type is defined.  This new name type is
   defined as the "other" style of the realm names as defined in Section
   6.1 of [RFC4120].

            other: RESERVED:real-name

   Namely the reserved realm names start with the literal "RESERVED:"

   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         83
                 -- 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 December 4, 2006                [Page 4]

Internet-Draft               Kerberos Naming                   June 2006


6.  IANA Considerations

   No IANA actions are required for 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.


































Zhu                     Expires December 4, 2006                [Page 5]

Internet-Draft               Kerberos Naming                   June 2006


Author's Address

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

   Email: lzhu@microsoft.com










































Zhu                     Expires December 4, 2006                [Page 6]

Internet-Draft               Kerberos Naming                   June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Zhu                     Expires December 4, 2006                [Page 7]