idnits 2.17.1 draft-melnikov-ldap-krb-authzid-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 238. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages -- Found 7 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (November 2006) is 6372 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: 'LDAP' is mentioned on line 52, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Possible downref: Non-RFC (?) normative reference: ref. 'UTF-8' ** Obsolete normative reference: RFC 3454 (Obsoleted by RFC 7564) ** Obsolete normative reference: RFC 4013 (ref. 'SASLPrep') (Obsoleted by RFC 7613) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet Draft Isode Limited 4 Document: draft-melnikov-ldap-krb-authzid-01.txt November 2006 5 Expires in six months 7 Additional authorization identity syntax for Kerberos-aware Directories 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 A revised version of this draft document will be submitted to the RFC 33 editor as a Draft Standard for the Internet Community. Discussion 34 and suggestions for improvement are requested. Distribution of this 35 draft is unlimited. 37 Internet DRAFT Kerberos Authorization Id for LDAP 20 November 2006 39 Abstract 41 This document defines new LDAP authorization identity syntax for 42 Kerberos-aware Directories. 44 1. Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119. [KEYWORDS] 50 2. Authorization Identity Syntax for Kerberos 52 This document defines a new LDAP [LDAP] authorization identity syntax 53 for Directories that support Kerberos V5 [KERBEROS]. For example, an 54 LDAP server that implements SASL GSSAPI [SASL-GSSAPI] mechanism may 55 also support the new syntax defined below. 57 The following syntax specification uses the augmented Backus-Naur 58 Form (BNF) notation as specified in [ABNF]. Non-terminals referenced 59 but not defined below are as defined by [AUTHMECH], [KERBEROS] and 60 [UTF-8]. 62 authzId =/ krbAuthzId 64 KRBCOLON = %x6B %x72 %x62 %x3a ; "krb:" 66 krbAuthzId = KRBCOLON krbPrincipal 67 ; kerberos-principal-name-based 68 ; authorization id. 70 krbRealmDelimiter = %x40 71 ; '@' 73 krbComponentDelimiter = %x2F 74 ; '/' 76 krbPrincipal = krbNameComponents 77 [krbRealmDelimiter krbRealm] 79 krbNameComponents = krbNameComponent 80 *(krbComponentDelimiter krbNameComponent) 82 krbNameComponent = KerberosString ; *UTF8 83 ; This corresponds to individual 85 Internet DRAFT Kerberos Authorization Id for LDAP 20 November 2006 87 ; "name-string" of "PrincipalName" as defined 88 ; in [KERBEROS]. 89 ; 90 ; '/', '\' and '@' characters must be escaped 91 ; by prefixing with \, i.e. "\@" 93 krbRealm = KerberosString ; *UTF8 94 ; This corresponds to "Realm" as defined in 95 ; [KERBEROS]. The syntax is constrained as 96 ; described in section 6 of [KERBEROS]. 97 ; 98 ; '/', '\' and '@' characters must be escaped 99 ; by prefixing with \, i.e. "\@" 101 The krbAuthzId choice allows a client to assert an authorization 102 identity of a Kerberos principal when the client doesn't know a 103 corresponding distinguished name for the asserted identity. A 104 krbAuthzId is prefixed with a unique prefix "krb:" which is followed 105 by a Kerberos principal (krbPrincipal). krbPrincipal consists of one 106 or more components (components of "name-string" [KERBEROS]) that form 107 a principal name followed by an optional Kerberos realm (krbRealm). 108 <> Before constructing a krbPrincipal each principal 109 name component and the realm MUST be prepared using the "SASLPrep" 110 profile [SASLPrep] of the "stringprep" algorithm [RFC3454]. 112 <> 114 All the krbNameComponent elements are delimited by the '/' character. 115 The principal name components are separated from the realm by the '@' 116 character. Because of the special meaning of the '/' and the '@' as 117 the delimiters, they are not allowed to be unescaped if used inside 118 of krbNameComponent (see Section 6.2 of [KERBEROS] for an example) or 119 krbRealm. The '\' character is used as the escape character. The '\' 120 itself has to be escaped. 122 Note that it is a typical for Kerberos/GSSAPI implementations to use 123 '/' and '@' as the delimiters. 125 <> 139 <> 146 Note, that name-type element of PrincipalName [KERBEROS] is not being 147 used in krbPrincipal. 149 This document doesn't mandate how an LDAP server performs internal 150 mapping of a krbPrincipal to the corresponding distinguished name. 151 For example, an implementation may choose to do an algorithmic 152 mapping ("user1@EXAMPLE.COM" ==> "cn=user1, dc=EXAMPLE, dc=COM"), or 153 perform a search based mapping. The client may use LDAP "Who am I?" 154 Extended Operation [WHO-AM-I] to discover the resulting distinguished 155 name. 157 3. Security considerations 159 <> 161 4. References 163 4.1. Normative References 165 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 166 Requirement Levels", RFC 2119, March 1997 168 [KERBEROS] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The 169 Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. 171 [AUTHMECH] Harrison, R. (Editor), "Lightweight Directory Access 172 Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 173 4513, June 2006. 175 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 176 Specifications: ABNF", RFC 4234, October 2005. 178 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 180 Internet DRAFT Kerberos Authorization Id for LDAP 20 November 2006 182 RFC 3629, STD 63, November 2003. 184 [RFC3454] P. Hoffman, M. Blanchet, "Preparation of Internationalized 185 Strings ("stringprep")," RFC 3454, December 2002. 187 [SASLPrep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names 188 and Passwords", RFC 4013, February 2005. 190 4.2. Informative References 192 [SASL-GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", draft-ietf- 193 sasl-gssapi, work in progress. <> 195 [WHO-AM-I] Zeilenga, K., "Lightweight Directory Access Protocol 196 (LDAP) - "Who am I?" Operation", RFC 4532, June 2006. 198 5. Author's Address 200 Alexey Melnikov 201 Isode Limited 202 5 Castle Business Village 203 36 Station Road 204 Hampton, Middlesex 205 TW12 2BX, United Kingdom 207 Email: Alexey.Melnikov@isode.com 208 URI: http://www.melnikov.ca/ 210 6. Acknowledgments 212 Thanks to Chris Ridd for providing useful feedback and suggestions. 214 Internet DRAFT Kerberos Authorization Id for LDAP 20 November 2006 216 Disclaimer of validity 218 The IETF takes no position regarding the validity or scope of any 219 Intellectual Property Rights or other rights that might be claimed to 220 pertain to the implementation or use of the technology described in 221 this document or the extent to which any license under such rights 222 might or might not be available; nor does it represent that it has 223 made any independent effort to identify any such rights. Information 224 on the procedures with respect to rights in RFC documents can be 225 found in BCP 78 and BCP 79. 227 Copies of IPR disclosures made to the IETF Secretariat and any 228 assurances of licenses to be made available, or the result of an 229 attempt made to obtain a general license or permission for the use of 230 such proprietary rights by implementers or users of this 231 specification can be obtained from the IETF on-line IPR repository at 232 http://www.ietf.org/ipr. 234 The IETF invites any interested party to bring to its attention any 235 copyrights, patents or patent applications, or other proprietary 236 rights that may cover technology that may be required to implement 237 this standard. Please address the information to the IETF at ietf- 238 ipr@ietf.org. 240 Full Copyright Statement 242 Copyright (C) The Internet Society (2006). This document is subject 243 to the rights, licenses and restrictions contained in BCP 78, and 244 except as set forth therein, the authors retain all their rights. 246 This document and the information contained herein are provided on an 247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 249 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 250 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 251 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 254 Acknowledgment 256 Funding for the RFC Editor function is currently provided by the 257 Internet Society. 259 Internet DRAFT Kerberos Authorization Id for LDAP 20 November 2006 261 Status of this Memo .......................................... i 262 Abstract ..................................................... 2 263 1. Conventions used in this document ...................... 2 264 2. Authorization Identity Syntax for Kerberos ............. 2 265 3. Security considerations ................................. 4 266 4. References ............................................. 4 267 4.1. Normative References ................................... 4 268 4.2. Informative References ................................. 5 269 5. Author's Address ........................................ 5 270 6. Acknowledgments ......................................... 5