idnits 2.17.1 draft-weltman-ldapv3-proxy-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The abstract seems to contain references ([AUTH]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 69: '... The criticality MUST be present and M...' RFC 2119 keyword, line 82: '...uest is denied, the server MUST return...' RFC 2119 keyword, line 122: '... honored. "Anonymous" users SHOULD NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 48 has weird spacing: '...ocument are...' == Line 137 has weird spacing: '...for the purpo...' -- 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 (April 2002) is 8040 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 section? 'AUTH' on line 168 looks like a reference -- Missing reference section? 'LDAPV3' on line 155 looks like a reference -- Missing reference section? 'SASL' on line 165 looks like a reference -- Missing reference section? 'KEYWORDS' on line 158 looks like a reference -- Missing reference section? 'RFC 2828' on line 63 looks like a reference -- Missing reference section? 'LDAPv3' on line 73 looks like a reference -- Missing reference section? 'LDAPTLS' on line 171 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Rob Weltman 3 Intended Category: Standards Track Netscape Communications Corp. 4 April 2002 6 LDAP Proxied Authorization Control 7 draft-weltman-ldapv3-proxy-10.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Task Force 15 (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document defines the Lightweight Directory Access Protocol 32 (LDAP) Proxied Authorization Control. The Proxied Authorization 33 Control allows a client to request that an operation be processed 34 under a provided authorization identity [AUTH] instead of as the 35 current authorization identity associated with the connection. 37 1. Introduction 39 This document defines support for proxied authorization using the 40 Control mechanism. LDAP [LDAPV3] supports the use of SASL [SASL] for 41 authentication and for supplying an authorization identity distinct 42 from the authentication identity, where the authorization identity 43 applies to the whole LDAP session. The proposed Proxied Authorization 44 Control provides a mechanism for specifying an authorization identity 45 on a per operation basis, benefiting clients that need to efficiently 46 perform operations on behalf of multiple users. 48 The key words "MUST", "SHOULD", and "MAY" used in this document are 49 to be interpreted as described in [KEYWORDS]. 51 2. Publishing support for the Proxied Authorization Control 53 Support for the Proxied Authorization Control is indicated by the 54 presence of the OID "2.16.840.1.113730.3.4.18" in the 55 supportedControl attribute of a server's root DSE. 57 3. Proxied Authorization Control 59 A single Proxied Authorization Control may be included in any 60 search, compare, modify, add, delete, modDN or extended operation 61 request message (with the exception of any extension that causes a 62 change in authentication, authorization, or data confidentiality 63 [RFC 2828], such as startTLS) as part of the controls field of the 64 LDAPMessage, as defined in [LDAPV3]. 66 The controlType of the proxied authorization control is 67 "2.16.840.1.113730.3.4.18". 69 The criticality MUST be present and MUST be TRUE. This requirement 70 protects clients from submitting a request that is executed with an 71 unintended authorization identity. 73 The control value is either an LDAPString [LDAPv3] containing an 74 authzId as defined in section 9 of [AUTH] to use as the authorization 75 identity for the request, or an empty value if the anonymous identity 76 is to be used. 78 4. Permission to execute as proxy 80 An LDAP server supporting the Proxied Authorization Control may 81 choose to honor or not honor a particular request. If the control is 82 supported but a particular request is denied, the server MUST return 83 the error code insufficientAccessRights. 85 The mechanism for determining proxy access rights is server-specific. 86 A typical implementation will evaluate if the requester has proxy 87 access rights at the base DN of the request. If the requester has 88 proxy access rights, and if the authorization identity is recognized 89 by the server, the request will be honored. If the request is 90 honored, it will be executed as if submitted by the proxied 91 authorization identity. The result code TBD is returned if the client 92 is not authorized to adopt the requested authorization identity. 93 [Note to the IESG/IANA/RFC Editor: the value TBD is to be replaced 94 with an IANA assigned LDAP Result Code (see draft-ietf-ldapbis-iana- 95 xx.txt, Section 3.5)] 97 The interaction of proxied authorization access control and normal 98 access control is illustrated here for the case of search requests. 99 During evaluation of a search request, an entry which would have been 100 returned for the search if submitted by the proxied authorization 101 identity directly may not be returned if the server finds that the 102 requester does not have proxy rights to the entry, even if the entry 103 is within the scope of a search request under a base DN which does 104 imply such rights. This means that fewer results, or no results, may 105 be returned compared to the case where the proxied authorization 106 identity issued the request directly. An example of such a case may 107 be a system with fine-grained access control, where the proxy right 108 requester has proxy rights at the top of a search tree, but not at or 109 below a point or points within the tree. 111 5. Security Considerations 113 The Proxied Authorization Control method is subject to general LDAP 114 security considerations [LDAPV3] [AUTH] [LDAPTLS]. The control may be 115 passed over a secure as well as over an insecure channel. 117 The control allows for an additional authorization identity to be 118 passed. In some deployments, these identities may contain 119 confidential information which require privacy protection. 121 Note that the server is responsible for determining if a proxied 122 authorization request is to be honored. "Anonymous" users SHOULD NOT 123 be allowed to assume the identity of others. 125 6. Copyright 127 Copyright (C) The Internet Society (date). All Rights Reserved. 129 This document and translations of it may be copied and furnished to 130 others, and derivative works that comment on or otherwise explain it 131 or assist in its implementation may be prepared, copied, published 132 and distributed, in whole or in part, without restriction of any 133 kind, provided that the above copyright notice and this paragraph are 134 included on all such copies and derivative works. However, this 135 document itself may not be modified in any way, such as by removing 136 the copyright notice or references to the Internet Society or other 137 Internet organizations, except as needed for the purpose of 138 developing Internet standards in which case the procedures for 139 copyrights defined in the Internet Standards process must be 140 followed, or as required to translate it into languages other than 141 English. 143 The limited permissions granted above are perpetual and will not be 144 revoked by the Internet Society or its successors or assigns. 146 This document and the information contained herein is provided on an 147 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 148 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 149 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 150 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 151 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 153 7. Bibliography 155 [LDAPV3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 156 Protocol (v3)", RFC 2251, December 1997. 158 [KEYWORDS] Bradner, Scott, "Key Words for use in RFCs to Indicate 159 Requirement Levels", draft-bradner-key-words-03.txt, January, 160 1997. 162 [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication 163 Methods for LDAP", RFC 2829, May 2000 165 [SASL] J. Myers, "Simple Authentication and Security Layer (SASL)", 166 RFC 2222, October 1997 168 [AUTH] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication 169 Methods for LDAP", RFC 2829, May 2000 171 [LDAPTLS] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory 172 Access Protocol (v3): Extension for Transport Layer Security", 173 RFC 2830, May 2000 175 8. Author's Address 177 Rob Weltman 178 Netscape Communications Corp. 179 466 Ellis Street 180 Mountain View, CA 94043 181 USA 182 +1 650 937-3194 183 rweltman@netscape.com 185 9. Acknowledgements 187 Mark Smith of Netscape Communications Corp., Mark Wahl of Sun 188 Microsystems, Inc, Kurt Zeilenga of OpenLDAP Foundation, and Jim 189 Sermersheim of Novell have contributed with reviews of this draft. 191 10. Revision History 193 10.1 Changes from draft-weltman-ldapv3-proxy-09.txt 195 Removed description of Control mechanism from Abstract. 197 Added description of how this is different from SASL authz to the 198 Introduction. 199 Reworded description of the value of the control (no semantic 200 changes). 201 Added new result code TBD for failure to acquire proxy rights. 203 Added references to RFCs 2829 and 2830 in Security section. 205 10.2 Changes from draft-weltman-ldapv3-proxy-08.txt 207 Proxied Authorization Control 209 Clarifications: the control may not be submitted with a startTLS 210 request; an empty controlValue implies the anonymous identity; only 211 one control may be included with a request. 213 Permission to execute as proxy 215 Replaced "proxy identity" with "proxied authorization identity". 217 Security Considerations 219 Added statement that anonymous users should not be allowed to assume 220 the identity of others. 222 10.3 Changes from draft-weltman-ldapv3-proxy-07.txt 224 Proxied Authorization Control 226 Clarification: the content of the control is an LDAPString. 228 10.4 Changes from draft-weltman-ldapv3-proxy-06.txt 230 None 232 10.5 Changes from draft-weltman-ldapv3-proxy-05.txt 234 The control also applies to add and extended operations. 236 The control value is an authorization ID, not necessarily a DN. 238 Confidentiality concerns are mentioned. 240 10.6 Changes from draft-weltman-ldapv3-proxy-04.txt 242 The control does not apply to bind, unbind, or abandon operations. 244 The proxy DN is represented as a string in the control, rather than 245 embedded in a sequence. 247 Support for the control is published in the supportedControl 248 attribute of the root DSE, not in supportedExtensions. 250 The security section mentions confidentiality issues with exposing an 251 additional identity. 253 10.7 Changes from draft-weltman-ldapv3-proxy-03.txt 255 None 257 10.8 Changes from draft-weltman-ldapv3-proxy-02.txt 259 The Control is now called Proxied Authorization Control, rather than 260 Proxied Authentication Control, to reflect that no authentication 261 occurs as a consequence of processing the Control. 263 Rather than containing an LDAPDN as the Control value, the Control 264 contains a Sequence (which contains an LDAPDN). This is to provide 265 for future extensions.