idnits 2.17.1 draft-zeilenga-ldap-proxy-grp-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([GROUPING], [RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 200 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be interpreted as described in BCP 14 [RFC2119]. -- 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 (13 November 2001) is 8193 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'AUTHZID' is defined on line 184, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** 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) -- No information found for draft-zeilenga-ldap-grouping-xx - is the name correct? -- No information found for draft-zeilenga-ldap-authzid-xx - is the name correct? -- No information found for draft-weltman-ldapv3-proxy-xx - is the name correct? Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Experimental OpenLDAP Foundation 4 Expires: 13 May 2002 13 November 2001 6 LDAPv3 Proxy Group 7 9 Status of Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 This document is intended to be, after appropriate review and 15 revision, submitted to the RFC Editor as an Experimental document. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Extension Working Group 18 mailing list . Please send editorial 19 comments directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright 2001, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Abstract 41 This document details a proxy authorization mechanism for LDAPv3 42 [RFC2251] which allows an authenticated client to concurrently issue 43 operations on behalf of multiple entities. The mechanism utilizes the 44 LDAPv3 Grouping of Related Operations [GROUPING] framework. 46 1. Background and Intended Use 48 LDAP supports a means for a client to request authorization as an 49 identity different from that of authenticated user as part of a SASL 50 [RFC2222] Bind operation [RFC2829]. This authorization, if accepted 51 by the server, applies to all operations which are issued by the 52 client until another Bind request is issued. However, it is often 53 desirable for a client to concurrently issue operations on behalf of 54 multiple entities. 56 This document provides a mechanism to allow clients to group 57 [GROUPING] related operations by the authorization identity which the 58 client wishes them to be processed under. The createGrouping 59 operation is used to assert an authorization identity. The resulting 60 group cookie is then used to identify operations which are to be 61 processed under this authorization. The endGrouping operation is used 62 to inform the server that group is no longer needed. 64 This document is a ''work in progress.'' This specification will 65 likely be significantly enhanced before it progressed. 67 The key words "SHALL", "SHALL NOT", "MUST", "MUST NOT", "SHOULD", 68 "SHOULD NOT", "MAY" and "MAY NOT" used in this document are to be 69 interpreted as described in BCP 14 [RFC2119]. 71 2. Specification of a Proxy Group 73 Servers implementing this specification SHOULD publish the 74 proxyGroupingType as a value of the supportedGroupingTypes attribute 75 contained within the Root DSE. 77 proxyGroupingType ::= 1.1.1 ;; fictious 79 A client wishing to preform operations as authorized by an identity 80 other than their authentication identity issue a createGroupingRequest 81 with a createGroupType of proxyGroupingType and createGroupValue 82 containing the authzId [RFC2829] representing the identy they would 83 like to assume. A server which is willing and able to allow the 84 client to assume this identity SHALL return a createGroupingResponse 85 with a success result code, createGroupCookie, and no 86 createGroupValue. Otherwise the server SHALL return a non-success 87 result code, no createGroupCookie, and no createGroupValue. 89 The client MAY then attach a GroupingControl to subsequent operations 90 to indicate that they are to be processed under the assumed 91 authorization identity. The server then performs the operation under 92 the assumed identity. 94 If the server becomes unwilling or unable to allow the client to 95 continue issuing operations under the assumed authorization identity, 96 the server SHOULD issue a endGroupNotice. Any future use of cookie by 97 the client SHALL result in a response containing a non-success result 98 code. 100 Upon receipt of a endGroupingNotice, the client SHOULD discontinue all 101 use of the grouping cookie. The client SHOULD NOT issue an 102 endGroupingRequest for the grouping cookie as the grouping is null and 103 void. 105 If the client no longer wishes to issue operations under the assumed 106 operation, it SHOULD issue an endGroupingRequest where the groupCookie 107 is the group cookie associated with the assumed authorization identity 108 and no endGroupValue is provided. Upon receipt of this request, the 109 server SHALL dissaociate the group cookie from the authorization 110 identity and return an appropriate result code. Regardless of the 111 result code, the client SHALL refrain from further use of the 112 groupCookie. 114 4. Security Considerations 116 Proxies often have have access to a great deal of information, they 117 are frequent targets of attack. The client SHALL establish adequate 118 protections. The server SHALL disallow creation of a proxy grouping 119 when inadequate protections are in place. 121 4.1. Permission to assume an identity 123 It is the sole responsibility of the LDAP server to determine whether 124 or not it will allow an authenticated client to assume the identity of 125 another entity. In general, server implementations use have one proxy 126 authorization policy which applies to this mechanism, SASL proxy 127 authorization [RFC2222][RFC2829], and proxy authorization mechcanims. 129 Servers SHALL NOT allow an anonymously bound client to assume the 130 identity of any user. 132 4.2. Confidential of Identity Information 134 This mechanism allows for additional identity information to be 135 transferred. This information may contain sensitive information and 136 SHOULD be protected using data confidentiality services 137 [RFC2829][RFC2830]. 139 4.2. Data Confidential 141 If the client's authentication identity or any authorization identity 142 it may assume has access to sensitive information, the client SHOULD 143 be protected using data confidential services [RFC2829][RFC2830]. 145 4.4. Hijack the Proxying Session 147 To protect against man-in-the-middle and hijacking attacks, these 148 mechanisms SHALL only be used when integrity protections are in place. 150 5. Acknowledgments 152 This document borrows from prior work in this area including the "LDAP 153 Proxied Authorization Control" [PROXYCTL] by Rob Weltman. 155 6. Additional Information 157 The author may be contacted as follows: 158 Kurt D. Zeilenga 159 OpenLDAP Foundation 160 162 References 164 [RFC2119] S. Bradner, "Key Words for use in RFCs to Indicate 165 Requirement Levels", Harvard University, BCP 14 (also RFC 2119), 166 March 1997. 168 [RFC2222] J. Myers, "Simple Authentication and Security Layer 169 (SASL)", RFC 2222, October 1997. 171 [RFC2251] M. Wahl, S. Kille, T. Howes, "Lightweight Directory 172 Access Protocol (v3)", RFC 2251, December 1997. 174 [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, 175 "Authentication Methods for LDAP", RFC 2829, June 2000. 177 [RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory 178 Access Protocol (v3): Extension for Transport Layer Security", RFC 179 2830, May 2000. 181 [GROUPING] K. Zeilenga, "LDAPv3: Grouping of Related Operations", 182 draft-zeilenga-ldap-grouping-xx.txt, a work in progress. 184 [AUTHZID] K. Zeilenga, "LDAP AuthzId Operation", 185 draft-zeilenga-ldap-authzid-xx.txt, a work in progress. 187 [PROXYCTL] R. Weltman, "LDAP Proxied Authorization Control", 188 draft-weltman-ldapv3-proxy-xx.txt, a work in progress. 190 Copyright 2001, The Internet Society. All Rights Reserved. 192 This document and translations of it may be copied and furnished 193 to others, and derivative works that comment on or otherwise explain 194 it or assist in its implementation may be prepared, copied, published 195 and distributed, in whole or in part, without restriction of any 196 kind, provided that the above copyright notice and this paragraph 197 are included on all such copies and derivative works. However, 198 this document itself may not be modified in any way, such as by 199 removing the copyright notice or references to the Internet Society 200 or other Internet organizations, except as needed for the purpose 201 of developing Internet standards in which case the procedures for 202 copyrights defined in the Internet Standards process must be 203 followed, or as required to translate it into languages other than 204 English. 206 The limited permissions granted above are perpetual and will not 207 be revoked by the Internet Society or its successors or assigns. 209 This document and the information contained herein is provided on 210 an "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE 211 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 212 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 213 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 214 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 215 PURPOSE.