idnits 2.17.1 draft-petithuguenin-p2psip-access-control-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 13, 2011) is 4732 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) -- Looks like a reference, but probably isn't: '16' on line 368 -- Looks like a reference, but probably isn't: '17' on line 368 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-13 -- Possible downref: Non-RFC (?) normative reference: ref. 'ECMA-262' -- 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 (-03) exists of draft-knauf-p2psip-share-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 May 13, 2011 5 Expires: November 14, 2011 7 Configuration of Access Control Policy in REsource LOcation And 8 Discovery (RELOAD) Base Protocol 9 draft-petithuguenin-p2psip-access-control-02 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 November 14, 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 . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 6 65 A.1. Standard Access Control Policies . . . . . . . . . . . . . 6 66 A.1.1. USER-MATCH . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . 8 71 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . . 10 72 B.1. Modifications between -02 and -01 . . . . . . . . . . . . 10 73 B.2. Modifications between -01 and -00 . . . . . . . . . . . . 10 74 B.3. Running Code Considerations . . . . . . . . . . . . . . . 10 75 B.4. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 11 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 The RELOAD base protocol specifies an Access Control Policy as 81 "defin[ing] whether a request from a given node to operate on a given 82 value should succeed or fail." The paragraph continues saying that 83 "[i]t is anticipated that only a small number of generic access 84 control policies are required", but there is indications that this 85 assumption will not hold. On all the RELOAD Usages defined in other 86 documents than the RELOAD base protocol, roughly 50% defines a new 87 Access Control Policy. 89 The problem with a new Access Control Policy is that, because it is 90 executed when a Store request is processed, it needs to be 91 implemented by all the peers and so requires an upgrade of the 92 software. This is something that is probably not possible in large 93 overlays or on overlays using different implementations. For this 94 reason, this document proposes an extension to the RELOAD 95 configuration document that permits to transport the code of a new 96 Access Control Policy to each peer. 98 This extension defines a new element that can 99 be optionally added to a element in the configuration 100 document. The element contains ECMAScript 101 [ECMA-262] code that will be called for each StoredData object in a 102 StoreReq processed by a peer. The code receives four parameters, 103 corresponding to the Resource-ID, Signature, Kind and StoredDataValue 104 of the value to store. The code returns true or false to signal to 105 the implementation if the request should succeed or fail. 107 For example the USER-MATCH Access Control Policy defined in the base 108 protocol could be redefined by inserting the following code in an 109 element: 111 return resource.equalsHash(signature.user_name.bytes()); 113 The parameters are also passed to the code, so the NODE- 114 MULTIPLE Access Control Policy could be implemented like this: 116 for (var i = 0; i < kind.max_node_multiple; i++) { 117 if (resource.equalsHash(signature.node_id, i.width(4))) { 118 return true; 119 } 120 } 121 return false; 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 3. Processing an extended Kind 131 A peer receiving a definition containing an access-control- 132 code elemtn , either by retrieving it from the configuration server 133 or in a ConfigUpdateReq message, MUST reject this configuration if 134 the kind element is not signed or if the signature verification 135 fails. 137 If the element is present in the namespace 138 allocated to this specification, and the Access Control Policy is not 139 natively implemented, then the code inside the element MUST be called 140 for each DataValue found in a received StoreReq for this Kind. For 141 each call to the code, the following ECMAScript objects, properties 142 and functions MUST be available: 144 resource: An opaque object representing the Resource-ID, as an array 145 of bytes. 146 resource.equalsHash(Object...): A function that returns true if 147 hashing the concatenation of the arguments according to the 148 mapping function of the overlay algorithm is equal to the 149 Resource-ID. Each argument is an array of bytes. 150 signature.user_name: The rfc822Name stored in the certificate that 151 was used to sign the request, as a String object. 152 signature.node_id: The Node-ID stored in the certificate that was 153 used to sign the request, as an array of bytes. 154 kind.id: The id of the Kind associated with the entry, as a Number 155 object. 156 kind.name: If the Kind associated with the entry is registered by 157 IANA, contains the name as a String object. If not, this property 158 is undefined. 159 kind.data_model: The name of the Data Model associated with the 160 entry, as a String object. 161 kind.access_control: The name of the Access Control Policy 162 associated with the entry, as a String object. 163 kind.max_count: The value of the max-count element in the 164 configuration file, as a Number object. 165 kind.max_size: The value of the max-size element in the 166 configuration file as a Number object. 168 kind.max_node_multiple: If the Access Control is MULTIPLE-NODE, 169 contains the value of the max-node-multiple element in the 170 configuration file, as a Number object. If not, this property is 171 undefined. 172 entry.index: If the Data Model is ARRAY, contains the index of the 173 entry, as a Number object. If not, this property is undefined. 174 entry.key: If the Data Model is DICTIONARY, contains the key of the 175 entry, as an array of bytes. If not, this property is undefined. 176 entry.storage_time: The date and time used to store the entry, as a 177 Date object. 178 entry.lifetime: The validity for the entry in seconds, as a Number 179 object. 180 entry.exists: Indicates if the entry value exists, as Boolean 181 object. 182 entry.value: This property contains an opaque object that represents 183 the whole data, as an array of bytes. 185 The properties SHOULD NOT be modifiable or deletable and if they are, 186 modifying or deleting them MUST NOT modify or delete the equivalent 187 internal values (in other words, the code cannot be used to modify 188 the elements that will be stored). 190 The value returned by the code is evaluated to true or false, 191 according to the ECMAScript rules. If the return value of one of the 192 call to the code is evaluated to false, then the StoreReq fails, the 193 state MUST be rolled back and an Error_Forbidden MUST be returned. 195 4. Security Considerations 197 TBD 199 5. IANA Considerations 201 No IANA considerations. 203 6. Acknowledgements 205 This document was written with the xml2rfc tool described in 206 [RFC2629]. 208 7. References 209 7.1. Normative References 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 214 [I-D.ietf-p2psip-base] 215 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 216 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 217 Base Protocol", draft-ietf-p2psip-base-13 (work in 218 progress), March 2011. 220 [ECMA-262] 221 Ecma, "ECMAScript Language Specification 3rd Edition", 222 December 2009. 224 7.2. Informative References 226 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 227 June 1999. 229 [I-D.ietf-p2psip-service-discovery] 230 Maenpaa, J. and G. Camarillo, "Service Discovery Usage for 231 REsource LOcation And Discovery (RELOAD)", 232 draft-ietf-p2psip-service-discovery-02 (work in progress), 233 January 2011. 235 [I-D.knauf-p2psip-share] 236 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 237 Usage for Shared Resources in RELOAD (ShaRe)", 238 draft-knauf-p2psip-share-00 (work in progress), 239 March 2011. 241 Appendix A. Examples 243 A.1. Standard Access Control Policies 245 This section shows the ECMAScript code that could be used to 246 implement the standard Access Control Policies defined in 247 [I-D.ietf-p2psip-base]. 249 A.1.1. USER-MATCH 250 String.prototype['bytes'] = function() { 251 var bytes = []; 252 for (var i = 0; i < this.length; i++) { 253 bytes[i] = this.charCodeAt(i); 254 } 255 return bytes; 256 }; 258 return resource.equalsHash(signature.user_name.bytes()); 260 A.1.2. NODE-MATCH 262 return resource.equalsHash(signature.node_id); 264 A.1.3. USER-NODE-MATCH 266 String.prototype['bytes'] = function() { 267 var bytes = []; 268 for (var i = 0; i < this.length; i++) { 269 bytes[i] = this.charCodeAt(i); 270 } 271 return bytes; 272 }; 274 var equals = function(a, b) { 275 if (a.length !== b.length) return false; 276 for (var i = 0; i < a.length; i++) { 277 if (a[i] !== b[i]) return false; 278 } 279 return true; 280 }; 282 return resource.equalsHash(signature.user_name.bytes()) 283 && equals(entry.key, signature.node_id); 285 A.1.4. NODE-MULTIPLE 286 Number.prototype['width'] = function(w) { 287 var bytes = []; 288 for (var i = 0; i < w; i++) { 289 bytes[i] = (this >>> ((w - i - 1) * 8)) & 255; 290 } 291 return bytes; 292 }; 294 for (var i = 0; i < kind.max_node_multiple; i++) { 295 if (resource.equalsHash(signature.node_id, i.width(4))) { 296 return true; 297 } 298 } 299 return false; 301 [[Note that base-13 do not state exactly the length of i when 302 concatenated in the hash input]] 304 A.2. Service Discovery Usage 306 [I-D.ietf-p2psip-service-discovery] defines a specific Access Control 307 Policy (NODE-ID-MATCH) that need to access the content of the entry 308 to be written. If implemented as specified by this document, the 309 element would look something like this: 311 314 DICTIONARY 315 NODE-ID-MATCH 316 100 317 60 319 320 /* Insert here the code from 321 http://jsfromhell.com/classes/bignumber 322 */ 324 var toBigNumber = function(node_id) { 325 var bignum = new BigNumber(0); 326 for (var i = 0; i < node_id.length; i++) { 327 bignum = bignum.multiply(256).add(node_id[i]); 328 } 329 return bignum; 330 }; 332 var checkIntervals = function(node_id, level, node, factor) { 333 var size = new BigNumber(2).pow(128); 334 var node = toBigNumber(node_id); 335 for (var f = 0; f < factor; f++) { 336 var temp = size.multiply(new BigNumber(f) 337 .pow(new BigNumber(level).negate())); 338 var min = temp.multiply(node.add(new BigNumber(f) 339 .divide(factor))); 340 var max = temp.multiply(node.add(new BigNumber(f + 1) 341 .divide(factor))); 342 if (node.compare(min) === -1 || node.compare(max) == 1 343 || node.compare(max) == 0) return false; 344 } 345 return true; 346 }; 348 var equals = function(a, b) { 349 if (a.length !== b.length) return false; 350 for (var i = 0; i < a.length; i++) { 351 if (a[i] !== b[i]) return false; 352 } 353 return true; 354 }; 356 var level = function(value) { 357 var length = value[16] * 256 + value[17]; 358 return value[18 + length] * 256 + value[18 + length + 1]; 359 }; 361 var node = function(value) { 362 var length = value[16] * 256 + value[17]; 363 return value[18 + length + 2] * 256 364 + value[18 + length + 3]; 365 }; 367 var namespace = function(value) { 368 var length = value[16] * 256 + value[17]; 369 return String.fromCharCode(value.slice(18, length)); 370 }; 372 var branching_factor = 2; 373 return equals(entry.key, signature.node_id) 374 && (!entry.exists || checkIntervals(entry.key, 375 level(entry.value), node(entry.value), 376 branching_factor)) 377 && (!entry.exists 378 || resource.equalsHash(namespace(entry.value), 379 level(entry.value), node(entry.value))); 380 381 382 Note that the code for the BigNumber object was removed from this 383 example, as the licensing terms are unclear. The code is available 384 at . 386 The branching-factor variable in the code must match the 387 element, which is not accessible to the code. 388 The signer of the kind must be sure that the two match. 390 Appendix B. Release notes 392 This section must be removed before publication as an RFC. 394 B.1. Modifications between -02 and -01 396 o Made clear that an unsigned kind with this extension must be 397 rejected. 398 o Removed the kind.params array, and converted the max-count, max- 399 size and max-node-multiple as Number objects. Fixed the examples. 400 o Removed the parsing of extensions in the kind element. The former 401 system did not work with namespaces or attributes, and the right 402 solution (xpath) is probably too complex. The value of the 403 parameters can still be manually mirrored in the script, so there 404 is perhaps no need for the added complexity. Also fixed the 405 examples. 406 o Reference draft-p2psip-share instance of draft-p2psip-disco. 407 o Added a "Running Code Considerations" section that contain the 408 reference to the reference implementation and script tester. 409 o Nits 411 B.2. Modifications between -01 and -00 413 o Changed reference from JavaScript to ECMAScript. 414 o Changed signature from equals() to equalsHash(). 415 o Fixed the examples following implementation. 416 o Replaced automatic decoding of value by ECMAScript code. 417 o Added the type of each property. 418 o Specified that the code cannot be used to modify the value stored. 420 B.3. Running Code Considerations 422 o Reference Implementation and Access Control Policy script tester 423 (). 424 Marc Petit-Huguenin. Implements version -02. 426 B.4. TODO List 428 o Need to convert ShaRe [I-D.knauf-p2psip-share] Usages USER-CHAIN- 429 ACL and USER-PATTERN-MATCH. 431 Author's Address 433 Marc Petit-Huguenin 434 Stonyfish, Inc. 436 Email: petithug@acm.org