idnits 2.17.1 draft-zeilenga-ldap-authzid-10.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 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 306. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 312), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (19 November 2004) is 7095 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) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2829 (Obsoleted by RFC 4510, RFC 4513) ** Obsolete normative reference: RFC 2830 (Obsoleted by RFC 4510, RFC 4511, RFC 4513) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-weltman-ldapv3-proxy-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PROXYAUTH' -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) -- No information found for draft-weltman-ldapv3-auth-response-xx - is the name correct? Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Kurt D. Zeilenga 2 Intended Category: Standard Track OpenLDAP Foundation 3 Expires in six months 19 November 2004 5 LDAP "Who am I?" Operation 6 8 Status of this Memo 10 This document is intended to be, after appropriate review and 11 revision, submitted to the RFC Editor as a Standard Track document. 12 Distribution of this memo is unlimited. Technical discussion of this 13 document will take place on the IETF LDAP Extensions mailing list 14 . Please send editorial comments directly to the 15 author . 17 By submitting this Internet-Draft, I accept the provisions of Section 18 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 19 applicable patent or other IPR claims of which I am aware have been 20 disclosed, or will be disclosed, and any of which I become aware will 21 be disclosed, in accordance with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 . The list of 34 Internet-Draft Shadow Directories can be accessed at 35 . 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Please see the Full Copyright section near the end of this document 40 for more information. 42 Abstract 44 This specification provides a mechanism for Lightweight Directory 45 Access Protocol (LDAP) clients to obtain the authorization identity 46 which the server has associated with the user or application entity. 47 This mechanism is specified as an LDAP extended operation called the 48 LDAP "Who am I?" operation. 50 Conventions 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in BCP 14 [RFC2119]. 56 1. Background and Intent of Use 58 This specification describes a Lightweight Directory Access Protocol 59 (LDAP) [RFC3377] operation which clients can use to obtain the primary 60 authorization identity in its primary form which the server has 61 associated with the user or application entity. The operation is 62 called the "Who am I?" operation. 64 This specification is intended to replace the existing [AUTHRESP] 65 mechanism which uses Bind request and response controls to request and 66 return the authorization identity. Bind controls are not protected by 67 the security layers established by the Bind operation which includes 68 them. While it is possible to establish security layers using Start 69 TLS [RFC2830] prior to the Bind operation, it is often desirable to 70 use security layers established by the Bind operation. An extended 71 operation sent after a Bind operation is protected by the security 72 layers established by the Bind operation. 74 There are other cases where it is desirable to request the 75 authorization identity which the server associated with the client 76 separately from the Bind operation. For example, the "Who am I?" 77 operation can be augmented with a Proxied Authorization Control 78 [PROXYAUTH] to determine the authorization identity which the server 79 associates with the identity asserted in the Proxied Authorization 80 Control. The "Who am I?" operation can also be used prior to the Bind 81 operation. 83 Servers often associate multiple authorization identities with the 84 client and each authorization identity may be represented by multiple 85 authzId [RFC2829] strings. This operation requests and returns the 86 authzId the server considers to be primary. In the specification, the 87 term "the authorization identity" and "the authzId" are generally to 88 be read as "the primary authorization identity" and the "the primary 89 authzId", respectively. 91 2. The "Who am I?" Operation 93 The "Who am I?" operation is defined as an LDAP Extended Operation 94 [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier 95 (OID). This section details the syntax of the operation's whoami 96 request and response messages. 98 whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3" 100 2.1. The whoami Request 102 The whoami request is an ExtendedRequest with the requestName field 103 containing the whoamiOID OID and an absent requestValue field. For 104 example, a whoami request could be encoded as the sequence of octets 105 (in hex): 107 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31 108 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33 110 2.2. The whoami Response 112 The whoami response is an ExtendedResponse where the responseName 113 field is absent and the response field, if present, is empty or an 114 authzId [RFC2829]. For example, a whoami response returning the 115 authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request) 116 would be encoded as the sequence of octets (in hex): 118 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13 119 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e 120 4e 45 54 122 3. Operational Semantics 124 The "Who am I?" operation provides a mechanism, a whoami Request, for 125 the client to request that the server returns the authorization 126 identity it currently associates with the client and provides a 127 mechanism, a whoami Response, for the server to respond to that 128 request. 130 Servers indicate their support for this extended operation by 131 providing whoamiOID object identifier as a value of the 132 'supportedExtension' attribute type in their root DSE. Server SHOULD 133 advertise this extension only when the client is willing and able to 134 perform this operation. 136 If the server is willing and able to provide the authorization 137 identity it associates with the client, the server SHALL return a 138 whoami Response with a success resultCode. If the server is treating 139 the client as an anonymous entity, the response field is present but 140 empty. Otherwise the server provides the authzId [RFC2829] 141 representing the authorization identity it currently associates with 142 the client in the response field. 144 If the server is unwilling or unable to provide the authorization 145 identity it associates with the client, the server SHALL return a 146 whoami Response with an appropriate non-success resultCode (such as 147 operationsError, protocolError, confidentialityRequired, 148 insufficientAccessRights, busy, unavailable, unwillingToPerform, or 149 other) and an absent response field. 151 As described in [RFC2251] and [RFC2829], an LDAP session has an 152 "anonymous" association until the client has been successfully 153 authenticated using the Bind operation. Clients MUST NOT invoke the 154 "Who Am I?" operation while any Bind operation is in progress, 155 including between two Bind requests made as part of a multi-stage Bind 156 operation. Where a whoami Request is received in violation of this 157 absolute prohibition, the server should return a whoami Response with 158 an operationsError resultCode. 160 4. Extending the "Who am I?" operation with controls 162 Future specifications may extend the "Who am I?" operation using the 163 control mechanism [RFC2251]. When extended by controls, the "Who am 164 I?" operation requests and returns the authorization identity the 165 server associates with the client in a particular context indicated by 166 the controls. 168 4.1. Proxied Authorization Control 170 The Proxied Authorization Control [PROXYAUTH] is used by clients to 171 request that the operation it is attached to operates under the 172 authorization of an assumed identity. The client provides the 173 identity to assume in the Proxied Authorization request control. If 174 the client is authorized to assume the requested identity, the server 175 executes the operation as if the requested identity had issued the 176 operation. 178 As servers often map the asserted authzId to another identity 179 [RFC2829], it is desirable to request the server provide the authzId 180 it associates with the assumed identity. 182 When a Proxied Authorization Control is be attached to the "Who Am I?" 183 operation, the operation requests the return of the authzId the server 184 associates with the identity asserted in the Proxied Authorization 185 Control. The TBD result code is used to indicate that the server does 186 not allow the client to assume the asserted identity. [[Note to RFC 187 Editor: TBD is to be replaced with the name/code assigned by IANA for 188 [PROXYAUTH] use.]] 190 5. Security Considerations 192 Identities associated with users may be sensitive information. When 193 so, security layers [RFC2829][RFC2830] should be established to 194 protect this information. This mechanism is specifically designed to 195 allow security layers established by a Bind operation to protect the 196 integrity and/or confidentiality of the authorization identity. 198 Servers may place access control or other restrictions upon the use of 199 this operation. As stated in Section 3, the server SHOULD advertise 200 this extension when it is willing and able to perform the operation. 202 As with any other extended operations, general LDAP security 203 considerations [RFC3377] apply. 205 6. IANA Considerations 207 The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who Am 208 I?" extended operation. This OID was assigned [ASSIGN] by OpenLDAP 209 Foundation, under its IANA-assigned private enterprise allocation 210 [PRIVATE], for use in this specification. 212 Registration of this protocol mechanism [RFC3383] is requested. 214 Subject: Request for LDAP Protocol Mechanism Registration 215 Object Identifier: 1.3.6.1.4.1.4203.1.11.3 216 Description: Who am I? 217 Person & email address to contact for further information: 218 Kurt Zeilenga 219 Usage: Extended Operation 220 Specification: RFC XXXX 221 Author/Change Controller: IESG 222 Comments: none 224 7. Acknowledgment 226 This document borrows from prior work in this area including 227 "Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark 228 Smith and Mark Wahl. 230 The LDAP "Who am I?" operation takes it name from the UNIX whoami(1) 231 command. The whoami(1) command displays the effective user id. 233 8. Author's Address 235 Kurt D. Zeilenga 236 OpenLDAP Foundation 238 Email: Kurt@OpenLDAP.org 240 9. References 242 [[Note to the RFC Editor: please replace the citation tags used in 243 referencing Internet-Drafts with tags of the form RFCnnnn where 244 possible.]] 246 9.1. Normative References 248 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 249 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 251 [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory 252 Access Protocol (v3)", RFC 2251, December 1997. 254 [RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan, 255 "Authentication Methods for LDAP", RFC 2829, June 2000. 257 [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight 258 Directory Access Protocol (v3): Extension for Transport 259 Layer Security", RFC 2830, May 2000. 261 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 262 Protocol (v3): Technical Specification", RFC 3377, 263 September 2002. 265 [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control", 266 draft-weltman-ldapv3-proxy-xx.txt, a work in progress. 268 9.2. Informative References 270 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 271 (also RFC 3383), September 2002. 273 [AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization 274 Identity Response and Request Controls", 275 draft-weltman-ldapv3-auth-response-xx.txt, a work in 276 progress. 278 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 279 http://www.openldap.org/foundation/oid-delegate.txt. 281 [PRIVATE] IANA, "Private Enterprise Numbers", 282 http://www.iana.org/assignments/enterprise-numbers. 284 Intellectual Property Rights 286 The IETF takes no position regarding the validity or scope of any 287 Intellectual Property Rights or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; nor does it represent that it has 291 made any independent effort to identify any such rights. Information 292 on the procedures with respect to rights in RFC documents can be found 293 in BCP 78 and BCP 79. 295 Copies of IPR disclosures made to the IETF Secretariat and any 296 assurances of licenses to be made available, or the result of an 297 attempt made to obtain a general license or permission for the use of 298 such proprietary rights by implementers or users of this specification 299 can be obtained from the IETF on-line IPR repository at 300 http://www.ietf.org/ipr. 302 The IETF invites any interested party to bring to its attention any 303 copyrights, patents or patent applications, or other proprietary 304 rights that may cover technology that may be required to implement 305 this standard. Please address the information to the IETF at 306 ietf-ipr@ietf.org. 308 Full Copyright 310 Copyright (C) The Internet Society (2004). This document is subject 311 to the rights, licenses and restrictions contained in BCP 78, and 312 except as set forth therein, the authors retain all their rights. 314 This document and the information contained herein are provided on an 315 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 316 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 317 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 318 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 319 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 320 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.