idnits 2.17.1 draft-weltman-ldapv3-proxy-04.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 60 lines 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 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 71: '... The criticality MUST be included and ...' RFC 2119 keyword, line 81: '... Implementations MUST return the error...' RFC 2119 keyword, line 89: '...uest is denied, the server MUST return...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 48 has weird spacing: '...ocument are...' == Line 68 has weird spacing: '...olValue pro...' == Line 134 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 (February 7, 2000) is 8838 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? '1' on line 152 looks like a reference -- Missing reference section? '2' on line 157 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Rob Weltman 3 INTERNET-DRAFT Netscape Communications Corp. 4 February 7, 2000 6 LDAP Proxied Authorization Control 7 draft-weltman-ldapv3-proxy-04.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 support for the Proxied Authorization Control. 32 Controls are an LDAP protocol version 3 extension, to allow passing 33 arbitrary control information along with a standard request to a 34 server, and to receive arbitrary information back with a standard 35 result. The Proxied Authorization Control allows a connection with 36 sufficient privileges to assume the identity of another entry for the 37 duration of an LDAP request. 39 1. Introduction 41 Version 3 of the LDAP protocol provides a means of supplying 42 arbitrary additional information along with a request to an LDAP 43 server, and receiving arbitrary additional response information. The 44 Control protocol extension is described in [1], section 4.1.12. This 45 document defines support for proxied authorization using the Control 46 mechanism. 48 The key words "MUST", "SHOULD", and "MAY" used in this document are 49 to be interpreted as described in [2]. 51 PROXIED AUTHORIZATION CONTROL February 2000 53 2. Publishing support for the Proxied Authorization Control 55 Support for the Proxied Authorization Control is indicated by the 56 presence of the OID "2.16.840.1.113730.3.4.12" in the 57 supportedExtensions attribute of a server's root DSE. 59 3. Proxied Authorization Control 61 This control may be included in any bind, unbind, search, compare, 62 abandon, modify, delete, or modrdn request message as part of the 63 controls field of the LDAPMessage, as defined in [1]. 65 proxyAuthControl ::= SEQUENCE { 66 controlType 2.16.840.1.113730.3.4.12, 67 criticality BOOLEAN DEFAULT FALSE, 68 controlValue proxyAuthValue 69 } 71 The criticality MUST be included and MUST be TRUE. 73 The controlValue contains the BER encoding of a DN used for 74 evaluating the requested rights: 76 proxyAuthValue::= SEQUENCE { 77 proxyDN LDAPDN 78 } 80 It is represented as a Sequence in order to allow future extensions. 81 Implementations MUST return the error code 82 unsupportedCriticalExtension in the event of unrecognized additional 83 elements in the sequence 85 4. Permission to execute as proxy 87 An LDAP server supporting the Proxied Authorization Control may 88 choose to honor or not honor a particular request. If the control is 89 supported but a particular request is denied, the server MUST return 90 the error code insufficientAccessRights. A typical implementation 91 will evaluate if the requester has proxy access rights at the base DN 92 of the request. If the requester has proxy access rights, and if the 93 proxy DN corresponds to a valid entry in the directory managed by the 94 server, the request will be honored. If the request is honored, it 95 will be executed as if submitted by the proxy identity. 97 During evaluation of a search request, an entry which would have been 98 returned for the search if submitted by the proxy identity directly 99 may not be returned if the server finds that the requester does not 100 have proxy rights to the entry, even if the entry is within the scope 101 of a search request under a base DN which does imply such rights. 102 This means that fewer results, or no results, may be returned 104 PROXIED AUTHORIZATION CONTROL February 2000 106 compared to the case where the proxy identity issued the request 107 directly. An example of such a case may be a system with fine-grained 108 access control, where the proxy right requester has proxy rights at 109 the top of a search tree, but not at or below a point or points 110 within the tree. 112 5. Security Considerations 114 The Proxied Authorization Control method is subject to standard LDAP 115 security considerations. The control may be passed over a secure as 116 well as over an insecure channel. No additional confidential 117 information is passed in the control. 119 Note that the server is responsible for determining if a proxied 120 authorization request is to be honored. 122 6. Copyright 124 Copyright (C) The Internet Society (date). All Rights Reserved. 126 This document and translations of it may be copied and furnished to 127 others, and derivative works that comment on or otherwise explain it 128 or assist in its implementation may be prepared, copied, published 129 and distributed, in whole or in part, without restriction of any 130 kind, provided that the above copyright notice and this paragraph are 131 included on all such copies and derivative works. However, this 132 document itself may not be modified in any way, such as by removing 133 the copyright notice or references to the Internet Society or other 134 Internet organizations, except as needed for the purpose of 135 developing Internet standards in which case the procedures for 136 copyrights defined in the Internet Standards process must be 137 followed, or as required to translate it into languages other than 138 English. 140 The limited permissions granted above are perpetual and will not be 141 revoked by the Internet Society or its successors or assigns. 143 This document and the information contained herein is provided on an 144 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 145 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 146 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 147 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 148 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 150 7. Bibliography 152 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 153 Protocol (v3)", RFC 2251, December 1997. 155 PROXIED AUTHORIZATION CONTROL February 2000 157 [2] Bradner, Scott, "Key Words for use in RFCs to Indicate 158 Requirement Levels", draft-bradner-key-words-03.txt, January, 159 1997. 161 8. Author's Addresses 163 Rob Weltman 164 Netscape Communications Corp. 165 MV-068 166 501 E. Middlefield Rd. 167 Mountain View, CA 94043 168 USA 169 +1 650 937-3301 170 rweltman@netscape.com 172 9. Changes from draft-weltman-ldapv3-proxy-03.txt 174 10. Changes from draft-weltman-ldapv3-proxy-02.txt 176 10.1 Renamed Control 178 The Control is now called Proxied Authorization Control, rather than 179 Proxied Authentication Control, to reflect that no authentication 180 occurs as a consequence of processing the Control. 182 10.2 Control envelope 184 Rather than containing an LDAPDN as the Control value, the Control 185 contains a Sequence (which contains an LDAPDN). This is to provide 186 for future extensions.