idnits 2.17.1 draft-petithuguenin-p2psip-access-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 6, 2011) is 4797 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-12 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-15) exists of draft-ietf-p2psip-service-discovery-02 == Outdated reference: A later version (-05) exists of draft-knauf-p2psip-disco-01 Summary: 0 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 M. Petit-Huguenin 3 Internet-Draft Stonyfish, Inc. 4 Intended status: Standards Track March 6, 2011 5 Expires: September 7, 2011 7 Configuration of Access Control Policy in REsource LOcation And 8 Discovery (RELOAD) Base Protocol 9 draft-petithuguenin-p2psip-access-control-00 11 Abstract 13 This document describes an extension to the REsource LOcation And 14 Discovery (RELOAD) base protocol to distribute the code of new Access 15 Control Policies without having to upgrade the RELOAD implementations 16 in an overlay. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may not be modified, 22 and derivative works of it may not be created, except to format it 23 for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 7, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Processing an extended Kind . . . . . . . . . . . . . . . . . . 4 58 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7 65 A.1. Standard Access Control Policies . . . . . . . . . . . . . 7 66 A.1.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . . 7 67 A.1.2. NODE-MATCH . . . . . . . . . . . . . . . . . . . . . . 7 68 A.1.3. USER-NODE-MATCH . . . . . . . . . . . . . . . . . . . . 7 69 A.1.4. NODE-MULTIPLE . . . . . . . . . . . . . . . . . . . . . 7 70 A.2. Service Discovery Usage . . . . . . . . . . . . . . . . . . 7 71 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 8 72 B.1. TODO List . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The RELOAD base protocol defines an Access Control Policy as 78 "defin[ing] whether a request from a given node to operate on a given 79 value should succeed or fail." The paragraph continues saying that 80 "[i]t is anticipated that only a small number of generic access 81 control policies are required", but there is indications that this 82 assumption will not hold. On all the RELOAD Usages defined in other 83 documents than the RELOAD base protocol, roughly 50% defines a new 84 Access Control Policy. 86 The problem with a new Access Control Policy is that, because they 87 are executed when a Store request is processed, they need to be 88 implemented by all the peers, and so require an upgrade of the 89 software. This is something that is probably not possible in large 90 overlays or on overlays using different implementations. For this 91 reason, this document proposes an extension to the RELOAD 92 configuration document that permits to transport the code of a new 93 Access Control Policy to each peer. 95 This extension defines a set of new elements that can be optionally 96 added to a element in the configuration document. The most 97 important of this elements is the element that 98 contains JavaScript code that will be called for each StoredData 99 object in a StoreReq processed by a peer. The code receives four 100 parameters, corresponding to the Resource-ID, Signature, Kind and 101 StoredDataValue of the value to store. The code returns true or 102 false to signal to the implementation if the request should succeed 103 or fail. 105 For example the USER-MATCH Access Control Policy defined in the base 106 protocol could be redefined by inserting the following code in an 107 element: 109 return resource.equals(signature.user_name); 111 The parameters are also passed to the code, so the NODE- 112 MULTIPLE Access Control Policy could be implemented like this: 114 for (int i = 0; i < kind.params['max-node-multiple']; i++) { 115 if (resource.equals(signature.node_id, i)) return true; 116 } 117 return false; 119 Some Access Control Policies requires access to the content of the 120 value to be stored. To permit this a element can be 121 added to describe the content of the value. This description uses 122 the same syntax that is used in the RELOAD base protocol to describe 123 the various messages and is automatically converted to a JavaScript 124 object accessible from the Access Control Policy code. For example 125 ReDiR [I-D.ietf-p2psip-service-discovery] requires such mechanism so 126 if the structure described in section 4.1. is copied in the element then the following code can be used to define the 128 NODE-ID-MATCH Access Control Policy: 130 return entry.key === signature.node_id 131 && (!entry.exists 132 || resource.equals(entry.value.data.namespace, 133 entry.value.data.level, entry.value.data.node); 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 3. Processing an extended Kind 143 A peer receiving a , either by retrieving it from the 144 configuration server or in a ConfigUpdateReq message, MUST verify the 145 signature in the kind-signature element before executing the code. 147 If the element is present in the namespace 148 allocated to this specification, and the Access Control Policy is not 149 natively implemented, then the code inside the element MUST be called 150 for each DataValue found in a received StoreReq for this Kind. For 151 each call to the code, the following JavaScript objects, properties 152 and functions MUST be available: 154 resource: An opaque object representing the Resource-ID. 155 resource.equals(Object...): Returns true if hashing the 156 concatenation of the arguments according to the mapping function 157 of the overlay algorithm is equal to the Resource-ID. 158 signature.user_name: The rfc822Name stored in the certificate that 159 was used to sign the request. 160 signature.node_id: The Node-ID stored in the certificate that was 161 used to sign the request. 162 kind.id: The id of the Kind associated with the entry. 163 kind.name: The name of the Kind associated with the entry. 164 kind.data_model: The name of the Data Model associated with the 165 entry. 167 kind.access_control: The name of the Access Control Policy 168 associated with the entry. 169 kind.params: An associative array containing the parameters of the 170 Access Control Policy as specified in the configuration file. 171 max-count: The value of the max-count element in the 172 configuration file. 173 max-size: The value of the max-size element in the configuration 174 file. 175 max-node-multiple: If the Access Control is MULTIPLE-NODE, 176 contains the value of the max-node-multiple element in the 177 configuration file. If not, this property is undefined. 178 entry.index: If the Data Model is ARRAY, contains the index of the 179 entry. If not, this property is undefined. 180 entry.key: If the Data Model is DICTIONARY, contains the key of the 181 entry. If not, this property is undefined. 182 entry.storage_time: A Date object containing the time for the 183 storage. 184 entry.lifetime: A number that contain the validity for the data in 185 seconds. 186 entry.exist: A boolean that indicates if the entry value exists. 187 entry.value: If a extension element is present in the 188 element, then the content of this property is automatically 189 generated from the definition. If not, this property contains an 190 opaque object that represent the whole data. 192 If addition to the "max-count", "max-size" and eventually "max-node- 193 multiple" properties in the kind.params associative array, any 194 extension element in any namespace found in the element MUST 195 be added to this array, using the element name as key and the content 196 as value. 198 The value returned by the code is evaluated to true or false, 199 according to the JavaScript rules. If the return value of one of the 200 call to the code is evaluated to false, then the StoreReq fails, the 201 state MUST be rolled back and an Error_Forbidden MUST be returned. 203 If the element is present in the namespace allocated to 204 this specification, then its content MUST be parsed and converted in 205 a way that will permit to parse the value in the DataValue structure 206 and generate a JavaScript object with properties corresponding to 207 each label. The "value" attribute MUST be filled with the label of 208 the statement inside the element that must be used as the root of the 209 parsing. Each statement in the content MUST be converted as follow: 211 Vectors: Variable-length vectors are converted to arrays. 212 Numbers: uint8, uint16, uint24, uint32, uint64, and uint128 are 213 converted to a JavaScript number. 214 Enumerateds: TBD 215 Structures: Structures are converted to an object, which each fields 216 being converted to a property of same name. 217 Variants: TBD 219 If the element is not present, the value in the 220 DataValue structure will still be passed as an opaque object to the 221 code. 223 4. Security Considerations 225 TBD 227 5. IANA Considerations 229 No IANA considerations. 231 6. Acknowledgements 233 This document was written with the xml2rfc tool described in 234 [RFC2629]. 236 7. References 238 7.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, March 1997. 243 [I-D.ietf-p2psip-base] 244 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 245 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 246 Base Protocol", draft-ietf-p2psip-base-12 (work in 247 progress), November 2010. 249 7.2. Informative References 251 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 252 June 1999. 254 [I-D.ietf-p2psip-service-discovery] 255 Maenpaa, J. and G. Camarillo, "Service Discovery Usage for 256 REsource LOcation And Discovery (RELOAD)", 257 draft-ietf-p2psip-service-discovery-02 (work in progress), 258 January 2011. 260 [I-D.knauf-p2psip-disco] 261 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 262 RELOAD Usage for Distributed Conference Control (DisCo)", 263 draft-knauf-p2psip-disco-01 (work in progress), 264 December 2010. 266 Appendix A. Examples 268 A.1. Standard Access Control Policies 270 This section shows the JavaScript code that could be used to 271 implement the standard Access Control Policies defined in 272 [I-D.ietf-p2psip-base]. 274 A.1.1. USER-MATCH 276 return resource.equals(signature.user_name); 278 A.1.2. NODE-MATCH 280 return resource.equals(signature.node_id); 282 A.1.3. USER-NODE-MATCH 284 return resource.equals(signature.user_name) 285 && entry.key === signature.node_id; 287 A.1.4. NODE-MULTIPLE 289 for (int i = 0; i < kind.params['max-node-multiple']; i++) { 290 if (resource.equals(signature.node_id, i)) return true; 291 } 292 return false; 294 A.2. Service Discovery Usage 296 [I-D.ietf-p2psip-service-discovery] defines a specific Access Control 297 Policy (NODE-ID-MATCH) that need to access the content of the entry 298 to be written. If implemented as specified by this document, the 299 element would look something like this: 301 303 DICTIONARY 304 NODE-ID-MATCH 305 100 306 60 308 309 return entry.key === signature.node_id 310 && true /* placeholder */ 311 && (!entry.exists 312 || (resource.equals(entry.value.data.namespace, 313 entry.value.data.level, entry.value.data.node); 314 316 317 struct { 318 NodeId serviceProvider; 319 opaque namespace<0..2^16-1>; 320 uint16 level; 321 uint16 node; 323 /* This type can be extended */ 325 } RedirServiceProviderData; 327 struct { 328 uint16 length; 329 RedirServiceProviderData data; 330 } RedirServiceProvider; 331 332 334 Appendix B. Release notes 336 This section must be removed before publication as an RFC. 338 B.1. TODO List 340 o Need to present the complete list of certificates for the DisCo 341 [I-D.knauf-p2psip-disco] Usage USER-CHAIN-MATCH. 342 o Add ABNF for the presentation language. 344 Author's Address 346 Marc Petit-Huguenin 347 Stonyfish, Inc. 349 Email: petithug@acm.org