idnits 2.17.1 draft-weltman-ldapv3-proxy-01.txt: -(78): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 an Authors' Addresses Section. ** 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 76: '... The criticality SHOULD be included an...' RFC 2119 keyword, line 89: '...uest is denied, the server MUST return...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 55 has weird spacing: '...ocument are...' == Line 67 has weird spacing: '...sage as part ...' == Line 73 has weird spacing: '...olValue pro...' == Line 122 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 (July 14, 1998) is 9411 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 140 looks like a reference -- Missing reference section? '2' on line 144 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 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 Tim Howes 5 Netscape Communications Corp. 6 July 14, 1998 8 LDAP Proxied Authentication Control 9 draft-weltman-ldapv3-proxy-01.txt 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 27 munnari.oz.au. 29 Copyright (C) The Internet Society (1997). All Rights Reserved. 31 Please see the Copyright section near the end of this document for 32 more information. 34 Abstract 36 This document defines support for the Proxied Authentication Control. 37 Controls are an LDAP protocol version 3 extension, to allow passing 38 arbitrary control information along with a standard request to a 39 server, and to receive arbitrary information back with a standard 40 result. The Proxied Authentication Control allows a connection with 41 sufficient privileges to assume the identity of another entry for the 42 duration of an LDAP request. 44 1. Introduction 46 Version 3 of the LDAP protocol provides a means of supplying 47 arbitrary additional information along with a request to an LDAP 48 server, and receiving arbitrary additional response information. The 49 Control protocol extension is described in [1], section 4.1.12. This 50 document defines support for proxied authentication using the Control 51 mechanism. 53 PROXIED AUTHENTICATION CONTROL July, 1998 55 The key words "MUST", "SHOULD", and "MAY" used in this document are 56 to be interpreted as described in [2]. 58 2. Publishing support for the Proxied Authentication Control 60 Support for the virtual list view extended operation is indicated by 61 the presence of the OID "2.16.840.1.113730.3.4.12" in the 62 supportedExtensions attribute of a server's root DSE. 64 3. Proxied Authentication Control 66 This control may be included in any search, modify, delete, or modrdn 67 request message as part of the controls field of the LDAPMessage, 68 as defined in [1]. 70 proxyAuthControl ::= SEQUENCE { 71 controlType 2.16.840.1.113730.3.4.12, 72 criticality BOOLEAN DEFAULT FALSE, 73 controlValue proxyAuthValue 74 } 76 The criticality SHOULD be included and SHOULD be TRUE. If it is not 77 TRUE, and the requester is not authorized to use proxied 78 authentication within the target Directory tree, the requester�s own 79 authentication will be used to execute the request. The controlValue 80 is an OCTET STRING, whose value is the BER encoding of a value of the 81 following: 83 proxyAuthValue ::= LDAPDN 85 4. Permission to execute as proxy 87 An LDAP server supporting the proxied authentication 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 5. Security Considerations 99 The proxied authentication control method is subject to standard LDAP 100 security considerations. The control may be passed over a secure as 102 PROXIED AUTHENTICATION CONTROL July, 1998 104 well as over an insecure channel. No additional confidential 105 information is passed in the control. 107 Note that the server is responsible for determining if a proxied 108 authentication request is to be honored. 110 6. Copyright 112 Copyright (C) The Internet Society (date). All Rights Reserved. 114 This document and translations of it may be copied and furnished to 115 others, and derivative works that comment on or otherwise explain it 116 or assist in its implementation may be prepared, copied, published 117 and distributed, in whole or in part, without restriction of any 118 kind, provided that the above copyright notice and this paragraph are 119 included on all such copies and derivative works. However, this 120 document itself may not be modified in any way, such as by removing 121 the copyright notice or references to the Internet Society or other 122 Internet organizations, except as needed for the purpose of 123 developing Internet standards in which case the procedures for 124 copyrights defined in the Internet Standards process must be 125 followed, or as required to translate it into languages other than 126 English. 128 The limited permissions granted above are perpetual and will not be 129 revoked by the Internet Society or its successors or assigns. 131 This document and the information contained herein is provided on an 132 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 133 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 134 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 135 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 136 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 138 7. Bibliography 140 [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 141 Protocol (v3)", Internet Draft draft-ietf-asid-ldapv3-protocol- 142 06.txt, July 1997. 144 [2] Bradner, Scott, "Key Words for use in RFCs to Indicate 145 Requirement Levels", draft-bradner-key-words-03.txt, January, 146 1997. 148 PROXIED AUTHENTICATION CONTROL July, 1998 150 8. Author�s Addresses 152 Rob Weltman 153 Netscape Communications Corp. 154 501 E. Middlefield Rd. 155 Mountain View, CA 94043 156 USA 157 +1 650 937-3301 158 rweltman@netscape.com 160 Tim Howes 161 Netscape Communications Corp. 162 501 E. Middlefield Rd. 163 Mountain View, CA 94043 164 USA 165 +1 650 937-3419 166 howes@netscape.com