idnits 2.17.1 draft-ietf-kitten-kerberos-iana-registries-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 15, 2012) is 4209 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) == Missing Reference: 'RFC2253' is mentioned on line 175, but not defined ** Obsolete undefined reference: RFC 2253 (Obsoleted by RFC 4510, RFC 4514) == Unused Reference: 'RFC3961' is defined on line 240, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 253, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Yu 3 Internet-Draft MIT Kerberos Consortium 4 Updates: rfc4120 (if approved) October 15, 2012 5 Intended status: Standards Track 6 Expires: April 18, 2013 8 Move Kerberos protocol parameter registries to IANA 9 draft-ietf-kitten-kerberos-iana-registries-00 11 Abstract 13 The Keberos 5 network authentication protocol has several numeric 14 protocol parameters. Most of these parameters are not currently 15 under IANA maintenance. This document requests that IANA take over 16 the maintenance of the remainder of these Kerberos parameters. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 18, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 1. Introduction 52 The Keberos 5 network authentication protocol has several numeric 53 protocol parameters. This document requests that IANA take over the 54 maintenance of the Kerberos protocol parameters that are not 55 currently under IANA maintenance. Several instances of number 56 conflicts in Kerberos implementations could have been prevented by 57 having IANA registries for those numbers. 59 2. General registry format 61 Unless otherwise specified, each Kerberos protocol number registry 62 will have the following fields: "number", "name", "reference", and 63 "comments". 65 The name must begin with a lowercase letter, and must consist of 66 ASCII letters, digits, and hyphens. Two or more hyphens must not 67 appear directly adjacent to each other. A hyphen must not appear at 68 the end of a name. It is preferred that words in a name be separated 69 by hyphens, and that all of the letters be lowercase. 71 (These rules are consistent with the lexical rules for an ASN.1 72 valuereference or identifier. Where the constraints are stricter 73 than the ASN.1 lexical rules, they make it easier to systematically 74 translate the names for use in implementation languages.) 76 Names for numeric parameter values have no inherent meaning in the 77 Kerberos protocol, but they can guide choices for internal 78 implementation symbol names and for user-visible non-numeric 79 representations. When written in English prose in specifications, or 80 when used as symbolic constants in implementation languages (e.g., C 81 preprocessor macros), it is common to transform the name into all 82 uppercase letters, and possibly to replace hyphens with underscores. 84 3. General registration procedure 86 This document requests that the IESG establish a pool of Kerberos 87 experts who will manage the Kerberos registries using these 88 guidelines. The IESG may wish to consider including the set of 89 designated IANA experts for existing Kerberos IANA registries as 90 candidates for this pool. 92 IANA will select an expert from this pool for each registration 93 request. The expert will review the registration request and may 94 approve the registration, decline the registration with comments, or 95 recommend that the registration request should follow a specific 96 alternative process. The alternative processes that the expert may 97 recommend are the IETF review process and the standards action 98 process. 100 Initially, the experts reviewers will use a permissive process, 101 generally approving registrations that are architecturally consistent 102 with Kerberos and the protocol parameter in question. Over time, 103 with input from the community, the experts may refine the 104 requirements that registrations are expected to meet. The experts 105 will maintain a current version of these guidelines in a manner that 106 is generally accessible to the entire community. As the guidelines 107 evolve, experts may consider the technical quality of specifications, 108 security impacts of the registrations, architectural consistency, and 109 interoperability impact. Experts may require a publicly available 110 specification in order to make certain registrations. 112 [ For the individual registries, include "Registrations in this 113 registry are managed by the expert review process [RFC5226] or in 114 exceptional cases by IESG approval. See section x for guidelines for 115 the experts to be used with this registry." ] 117 4. Integer assignments 119 Names for integer assignments must be unique across all Kerberos 120 integer parameter registries. This is normally accomplished by 121 including a name prefix that identifies the registry. 123 Assignments for integers parameters will follow the general 124 registration procedure outlined above, except as otherwise noted in 125 the section that contains the description of the parameter. Kerberos 126 integer parameters take on signed 32-bit values (-2147483648 to 127 2147483647). Negative values are for private or local use. 129 4.1. Address types 131 Address types historically align with numeric constants used in the 132 Berkeley sockets API. Future address type assignments should conform 133 to this historical practice when possible. The name prefix for 134 address types is "addrtype-". 136 4.2. Authorization data types 138 The name prefix for authorization data types is "ad-". 140 4.3. Error codes 142 Assignments for error codes require standards action due to their 143 scarcity: assigning error codes greater than 127 could require 144 significant changes to certain implementations. The name prefixes 145 for error codes are "kdc-err-", "krb-err", or "krb-ap-err". 147 4.4. Key usages 149 Key usages are unsigned 32-bit integers (0 to 4294967295). Zero is 150 reserved and may not be assigned. 152 The name prefix for key usages is "ku-". 154 4.5. Name types 156 The name prefix for name types is "nt-". 158 +--------+-------------------+-----------+--------------------------+ 159 | number | name | reference | comment | 160 +--------+-------------------+-----------+--------------------------+ 161 | 0 | nt-unknown | RFC4120 | Name type not known | 162 | 1 | nt-principal | RFC4120 | Just the name of the | 163 | | | | principal as in DCE, or | 164 | | | | for users | 165 | 2 | nt-srv-inst | RFC4120 | Service and other unique | 166 | | | | instance (krbtgt) | 167 | 3 | nt-srv-hst | RFC4120 | Service with host name | 168 | | | | as instance (telnet, | 169 | | | | rcommands) | 170 | 4 | nt-srv-xhst | RFC4120 | Service with host as | 171 | | | | remaining components | 172 | 5 | nt-uid | RFC4120 | Unique ID | 173 | 6 | nt-x500-principal | RFC4120 | Encoded X.509 | 174 | | | | Distinguished name | 175 | | | | [RFC2253] | 176 | 7 | nt-smtp-name | RFC4120 | Name in form of SMTP | 177 | | | | email name (e.g., | 178 | | | | user@example.com) | 179 | 10 | nt-enterprise | RFC4120 | Enterprise name - may be | 180 | | | | mapped to principal name | 181 | 11 | nt-wellknown | RFC6111 | Well-known principal | 182 | | | | name | 183 | 12 | nt-srv-hst-domain | RFC5179 | Domain-based names | 184 +--------+-------------------+-----------+--------------------------+ 186 4.6. Pre-authentication and typed data 188 The name prefix for pre-authentication type numbers is "pa-". The 189 name prefix for typed data numbers is "td-". Pre-authentication and 190 typed data numbers are in the same registry, but a pre-authentication 191 number may be also be assigned to a related typed data number. 193 5. Named bit assignments 195 Assignments for named bits require standards action, due to their 196 scarcity: assigning bit numbers greater than 31 could require 197 significant changes to implementations. Names for named bit 198 assignments must be unique within a given named bit registry, and 199 typically do not have name prefixes that identify which registry they 200 belong to. 202 5.1. AP-REQ options 204 5.2. KDC-REQ options 206 5.3. Ticket flags 208 6. Contributors 210 Sam Hartman proposed the text of the expert review guidelines. Love 211 Hornquist Astrand wrote a previous document 212 (draft-lha-krb-wg-some-numbers-to-iana-00) with the same goals as 213 this document. 215 7. Security Considerations 217 Assignments of new Keberos protocol parameter values can have 218 security implications. In cases where the assignment policy calls 219 for expert review, the reviewer is responsible for evaluating whether 220 adequate documentation exists concerning the security considerations 221 for the requested assignment. For assignments that require IETF 222 review or standards action, the normal IETF processes ensure adequate 223 treatment of security considerations. 225 8. IANA Considerations 227 This document requests that IANA create several registries for 228 Kebreros protocol parameters. This document also requests that IANA 229 modify several existing registries of Kerberos protocol parameters. 231 This document requests that IANA modify the existing "Pre- 232 authentication data and typed data" registry to contain an additional 233 reference to this document, and to transform existing names in that 234 registry to the lowercase-and-hyphens style. 236 9. References 238 9.1. Normative References 240 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 241 Kerberos 5", RFC 3961, February 2005. 243 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 244 Kerberos Network Authentication Service (V5)", RFC 4120, 245 July 2005. 247 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 248 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 249 May 2008. 251 9.2. Informative References 253 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 254 Authentication Service (V5)", RFC 1510, September 1993. 256 Author's Address 258 Tom Yu 259 MIT Kerberos Consortium 260 77 Massachusetts Ave 261 Cambridge, Massachusetts 262 USA 264 Email: tlyu@mit.edu