idnits 2.17.1 draft-ietf-krb-wg-naming-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 299. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4120, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4120, updated by this document, for RFC5378 checks: 2002-02-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 12, 2008) is 5733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft Microsoft Corporation 4 Updates: 4120 (if approved) August 12, 2008 5 Intended status: Standards Track 6 Expires: February 13, 2009 8 Additional Kerberos Naming Constraints 9 draft-ietf-krb-wg-naming-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 13, 2009. 36 Abstract 38 This document defines new naming constraints for well-known Kerberos 39 principal name and well-known Kerberos realm names. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 45 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 3.1. Well-known Kerberos Principal Names . . . . . . . . . . . . 3 47 3.2. Well-known Kerberos Realm Names . . . . . . . . . . . . . . 4 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 49 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 51 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 52 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 53 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 Intellectual Property and Copyright Statements . . . . . . . . . . 8 57 1. Introduction 59 Occasionally protocol designers need to designate a Kerberos 60 principal name or a Kerberos realm name to have special meanings, 61 other than identifying a particular instance. An example is that the 62 the anonymous principal name and the anonymous realm name are defined 63 for the Kerberos anonymity support [ANON]. This anonymity name pair 64 conveys no more meaning than that the client's identity is not 65 disclosed. In the case of the anonymity support, it is critical that 66 deployed Kerberos implementations that do not support anonymity MUST 67 fail the authentication if the anonymity name pair is used, therefore 68 no access is granted accidentally to a principal who's name happens 69 to match with that of the anonymous identity. 71 However Kerberos as defined in [RFC4120] does not have such reserved 72 names. As such, protocol designers have resolved to use exceedingly- 73 unlikely-to-have-been-used names to avoid collision. Even if a 74 registry were setup to avoid collision for new implementations, there 75 is no guarantee for deployed implementations to prevent accidental 76 reuse of names that can lead to access being granted unexpectedly. 78 The Kerberos realm name in [RFC4120] has a reserved name space 79 although no specific name is defined and the criticality of unknown 80 reserved realm names is not specified. 82 This document is to remedy these issues by defining well-known 83 Kerberos names and the protocol behavior when a well-known name is 84 used but not supported. 86 2. Conventions Used in This Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. Definitions 94 In this section, well-known names are defined for both the Kerberos 95 principal name and the Kerberos realm name. 97 3.1. Well-known Kerberos Principal Names 99 A new name type KRB_NT_WELLKNOWN is defined for well-known principal 100 names. The Kerberos principal name is defined in Section 6.2 of 101 [RFC4120]. 103 KRB_NT_WELLKNOWN 11 105 A well-known principal name MUST have at least two or more 106 KerberosString components, and the first component must be the string 107 literal "WELLKNOWN". 109 If a well-known principal name is used as the client principal name 110 or the server principal name but not supported, the Authentication 111 Service (AS) [RFC4120] and the application server MUST reject the 112 authentication attempt. Similarly, the Ticket Granting Service (TGS) 113 [RFC4120] MAY reject the authentication attempt if a well-known 114 principal name is used as the client principal name but not 115 supported, and SHOULD reject the authentication attempt if a well- 116 known principal name is used as the server principal name but not 117 supported. These rules were designed to allow incremental updates 118 and ease migration. More specifically, if a well-known principal is 119 accepted in one realm, it is desirable to allow the cross-realm TGT 120 to work when not all of the realms in the cross-realm authentication 121 path are updated; if the server principal with an identically-named 122 well-known name was created before the KDC is updated, it might be 123 acceptable to allow authentication to work within a reasonably- 124 limited time window. However unless otherwise specified, if a well- 125 known principal name is used but not supported in any other places of 126 Kerberos messages, authentication MUST fail. The error code is 127 KRB_AP_ERR_PRINCIPAL_UNKNOWN, and there is no accompanying error data 128 defined in this document for this error. 130 KRB_AP_ERR_PRINCIPAL_UNKNOWN 82 131 -- A well-known Kerberos principal name is used but not 132 -- supported. 134 3.2. Well-known Kerberos Realm Names 136 Section 6.1 of [RFC4120] defines the "other" style realm name, a new 137 realm type WELLKNOWN is defined as a name of type "other", with the 138 NAMETYPE part filled in with the string literal "WELLKNOWN". 140 other: WELLKNOWN:realm-name 142 This name type is designated for well-known Kerberos realms. 144 The AS and the application server MUST reject the authentication 145 attempt if a well-known realm name is used as the client realm or the 146 server realm but not supported. The TGS [RFC4120] MAY reject the 147 authentication attempt if a well-known realm name is used as the 148 client realm but not supported, and SHOULD reject the authentication 149 attempt if a well-known realm name is used as the server realm but 150 not supported. Unless otherwise specified, if a well-known realm 151 name is used but not supported in any other places of Kerberos 152 messages, authentication MUST fail. The error code is 153 KRB_AP_ERR_REALM_UNKNOWN, and there is no accompanying error data 154 defined in this document for this error. 156 KRB_AP_ERR_REALM_UNKNOWN 83 157 -- A well-known Kerberos realm name is used but not 158 -- supported. 160 Unless otherwise specified, all principal names involving a well- 161 known realm name are reserved, and if a reserved principal name is 162 used but not supported, and if the authentication is rejected, the 163 error code MUST be KRB_AP_ERR_PRINCIPAL_RESERVED. 165 KRB_AP_ERR_PRINCIPAL_RESERVED 84 166 -- A reserved Kerberos principal name is used but not 167 -- supported. 169 There is no accompanying error data defined in this document for this 170 error. 172 According to Section 3.3.3.2 of [RFC4120], the TGS MUST add the name 173 of the previous realm into the transited field of the returned 174 ticket. Typically well-known realms are defined to carry special 175 meanings, and they are not used to refer to intermediate realms in 176 the client's authentication path. Consequently, unless otherwise 177 specified, the TGS MUST NOT encode a well-known Kerberos realm name 178 into the transited field [RFC4120] of a ticket, and parties checking 179 the transited realm path MUST reject a transited realm path that 180 includes a well known realm. In the case of KDCs checking the 181 transited realm path, this means that the TRANSITED-POLICY-CHECKED 182 flag MUST NOT be set in the resulting ticket. Aside from the 183 hierarchical meaning of a null subfield, the DOMAIN-X500-COMPRESS 184 encoding for transited realms [RFC4120] treats realm names as 185 strings, although it is optimized for domain style and X.500 realm 186 names, hence the DOMAIN-X500-COMPRESS encoding can be used when the 187 client realm or the server realm is reserved or when a reserved realm 188 is in the transited field. However, if the client's realm is a well- 189 known realm, the abbreviation forms [RFC4120] that build on the 190 preceding name cannot be used at the start of the transited encoding. 191 The null-subfield form (e.g., encoding ending with ",") [RFC4120] 192 could not be used next to a well-known realm, including potentially 193 at the beginning and end where the client and server realm names, 194 respectively, are filled in. 196 4. Security Considerations 198 It is possible to have name collision with well-known names because 199 Kerberos as defined in [RFC4120] does not reserve names that have 200 special meanings, consequently care MUST be taken to avoid accidental 201 reuse of names. If a well-known name is not supported, 202 authentication MUST fail as specified in Section 3. Otherwise, 203 access can be granted unintentionally, resulting in a security 204 weakness. Consider for example, a KDC that supports this 205 specification but not the anonymous authentication described in 206 [ANON]. Assume further that the KDC allows a principal to be created 207 named identically to the anonymous principal. If that principal were 208 created and given access to resources, then anonymous users might 209 inadvertently gain access to those resources if the KDC supports 210 anonymous authentication at some future time. Similar issues may 211 occur with other well-known names. By requiring KDCs reject 212 authentication with unknown well-known names, we minimize these 213 concerns. 215 If a well-known name was created before the KDC is updated to conform 216 to this specification, it SHOULD be renamed. The provisioning code 217 that manages account creation MUST be updated to disallow creation of 218 principals with unsupported well-known names. 220 5. Acknowledgements 222 The initial document was mostly based on the author's conversation 223 with Clifford Newman and Sam Hartman. 225 Jeffery Hutzelman, Ken Raeburn, and Stephen Hanna provided helpful 226 suggestions for improvements to early revisions of this document. 228 6. IANA Considerations 230 This document provides the framework for defining well-known Kerberos 231 names and Kerberos realms. A new IANA registry should be created to 232 contain well-known Kerberos names and Kerberos realms that are 233 defined based on this document. The evaluation policy is 234 "Specification Required". 236 7. References 237 7.1. Normative References 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 243 Kerberos Network Authentication Service (V5)", RFC 4120, 244 July 2005. 246 7.2. Informative References 248 [ANON] Zhu, L., Leach, P. and K. Jaganathan, "Kerberos Anonymity 249 Support", draft-ietf-krb-wg-anon, work in progress. 251 Author's Address 253 Larry Zhu 254 Microsoft Corporation 255 One Microsoft Way 256 Redmond, WA 98052 257 US 259 Email: lzhu@microsoft.com 261 Full Copyright Statement 263 Copyright (C) The IETF Trust (2008). 265 This document is subject to the rights, licenses and restrictions 266 contained in BCP 78, and except as set forth therein, the authors 267 retain all their rights. 269 This document and the information contained herein are provided on an 270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 272 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 273 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 274 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 277 Intellectual Property 279 The IETF takes no position regarding the validity or scope of any 280 Intellectual Property Rights or other rights that might be claimed to 281 pertain to the implementation or use of the technology described in 282 this document or the extent to which any license under such rights 283 might or might not be available; nor does it represent that it has 284 made any independent effort to identify any such rights. Information 285 on the procedures with respect to rights in RFC documents can be 286 found in BCP 78 and BCP 79. 288 Copies of IPR disclosures made to the IETF Secretariat and any 289 assurances of licenses to be made available, or the result of an 290 attempt made to obtain a general license or permission for the use of 291 such proprietary rights by implementers or users of this 292 specification can be obtained from the IETF on-line IPR repository at 293 http://www.ietf.org/ipr. 295 The IETF invites any interested party to bring to its attention any 296 copyrights, patents or patent applications, or other proprietary 297 rights that may cover technology that may be required to implement 298 this standard. Please address the information to the IETF at 299 ietf-ipr@ietf.org.