idnits 2.17.1 draft-petithuguenin-p2psip-access-control-01.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 (March 13, 2011) is 4794 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 370 -- Looks like a reference, but probably isn't: '17' on line 370 == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-12 -- 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 (-05) exists of draft-knauf-p2psip-disco-01 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 March 13, 2011 5 Expires: September 14, 2011 7 Configuration of Access Control Policy in REsource LOcation And 8 Discovery (RELOAD) Base Protocol 9 draft-petithuguenin-p2psip-access-control-01 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 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 -01 and -00 . . . . . . . . . . . . 10 73 B.2. TODO List . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 The RELOAD base protocol specifies an Access Control Policy as 79 "defin[ing] whether a request from a given node to operate on a given 80 value should succeed or fail." The paragraph continues saying that 81 "[i]t is anticipated that only a small number of generic access 82 control policies are required", but there is indications that this 83 assumption will not hold. On all the RELOAD Usages defined in other 84 documents than the RELOAD base protocol, roughly 50% defines a new 85 Access Control Policy. 87 The problem with a new Access Control Policy is that, because they 88 are executed when a Store request is processed, they need to be 89 implemented by all the peers and so require an upgrade of the 90 software. This is something that is probably not possible in large 91 overlays or on overlays using different implementations. For this 92 reason, this document proposes an extension to the RELOAD 93 configuration document that permits to transport the code of a new 94 Access Control Policy to each peer. 96 This extension defines a new element that can 97 be optionally added to a element in the configuration 98 document. The element contains ECMAScript 99 [ECMA-262] code that will be called for each StoredData object in a 100 StoreReq processed by a peer. The code receives four parameters, 101 corresponding to the Resource-ID, Signature, Kind and StoredDataValue 102 of the value to store. The code returns true or false to signal to 103 the implementation if the request should succeed 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.equalsHash(signature.user_name.bytes()); 111 The parameters are also passed to the code, so the NODE- 112 MULTIPLE Access Control Policy could be implemented like this: 114 for (var i = 0; i < kind.params['max-node-multiple']; i++) { 115 if (resource.equalsHash(signature.node_id, i.width(4))) { 116 return true; 117 } 118 } 119 return false; 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Processing an extended Kind 129 A peer receiving a definition, either by retrieving it from 130 the configuration server or in a ConfigUpdateReq message, MUST verify 131 the signature in the kind-signature element before executing the 132 code. 134 If the element is present in the namespace 135 allocated to this specification, and the Access Control Policy is not 136 natively implemented, then the code inside the element MUST be called 137 for each DataValue found in a received StoreReq for this Kind. For 138 each call to the code, the following ECMAScript objects, properties 139 and functions MUST be available: 141 resource: An opaque object representing the Resource-ID, as an array 142 of bytes. 143 resource.equalsHash(Object...): Returns true if hashing the 144 concatenation of the arguments according to the mapping function 145 of the overlay algorithm is equal to the Resource-ID. Each 146 argument is an array of bytes. 147 signature.user_name: The rfc822Name stored in the certificate that 148 was used to sign the request, as a String object. 149 signature.node_id: The Node-ID stored in the certificate that was 150 used to sign the request, as an array of bytes. 151 kind.id: The id of the Kind associated with the entry, as a Number 152 object. 153 kind.name: The name of the Kind associated with the entry, as a 154 String object. 155 kind.data_model: The name of the Data Model associated with the 156 entry, as a String object. 157 kind.access_control: The name of the Access Control Policy 158 associated with the entry, as a String object. 159 kind.params: An associative array containing the parameters of the 160 Access Control Policy as specified in the configuration file. 161 max-count: The value of the max-count element in the 162 configuration file, as a String object. 163 max-size: The value of the max-size element in the configuration 164 file as a String object. 166 max-node-multiple: If the Access Control is MULTIPLE-NODE, 167 contains the value of the max-node-multiple element in the 168 configuration file, as a String object. If not, this property 169 is undefined. 170 entry.index: If the Data Model is ARRAY, contains the index of the 171 entry, as a Number object. If not, this property is undefined. 172 entry.key: If the Data Model is DICTIONARY, contains the key of the 173 entry, as an array of bytes. If not, this property is undefined. 174 entry.storage_time: The date and time used to store the entry, as a 175 Date object. 176 entry.lifetime: The validity for the entry in seconds, as a Number 177 object. 178 entry.exist: Indicates if the entry value exists, as Boolean object. 179 entry.value: This property contains an opaque object that represents 180 the whole data, as an array of bytes. 182 The properties SHOULD NOT be modifiable or deletable and if they are, 183 modifying or deleting them MUST NOT modify or delete the equivalent 184 internal values (in other words, the code cannot be used to modify 185 the elements that will be stored). 187 If addition to the "max-count", "max-size" and eventual "max-node- 188 multiple" properties in the kind.params associative array, any 189 extension element in any namespace found in the element MUST 190 be added to this array, using the element name as key and the content 191 as value. 193 The value returned by the code is evaluated to true or false, 194 according to the ECMAScript rules. If the return value of one of the 195 call to the code is evaluated to false, then the StoreReq fails, the 196 state MUST be rolled back and an Error_Forbidden MUST be returned. 198 4. Security Considerations 200 TBD 202 5. IANA Considerations 204 No IANA considerations. 206 6. Acknowledgements 208 This document was written with the xml2rfc tool described in 209 [RFC2629]. 211 7. References 213 7.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [I-D.ietf-p2psip-base] 219 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 220 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 221 Base Protocol", draft-ietf-p2psip-base-12 (work in 222 progress), November 2010. 224 [ECMA-262] 225 Ecma, "ECMAScript Language Specification 3rd Edition", 226 December 2009. 228 7.2. Informative References 230 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 231 June 1999. 233 [I-D.ietf-p2psip-service-discovery] 234 Maenpaa, J. and G. Camarillo, "Service Discovery Usage for 235 REsource LOcation And Discovery (RELOAD)", 236 draft-ietf-p2psip-service-discovery-02 (work in progress), 237 January 2011. 239 [I-D.knauf-p2psip-disco] 240 Knauf, A., Hege, G., Schmidt, T., and M. Waehlisch, "A 241 RELOAD Usage for Distributed Conference Control (DisCo)", 242 draft-knauf-p2psip-disco-01 (work in progress), 243 December 2010. 245 Appendix A. Examples 247 A.1. Standard Access Control Policies 249 This section shows the ECMAScript code that could be used to 250 implement the standard Access Control Policies defined in 251 [I-D.ietf-p2psip-base]. 253 A.1.1. USER-MATCH 254 String.prototype['bytes'] = function() { 255 var bytes = []; 256 for (var i = 0; i < this.length; i++) { 257 bytes[i] = this.charCodeAt(i); 258 } 259 return bytes; 260 }; 262 return resource.equalsHash(signature.user_name.bytes()); 264 A.1.2. NODE-MATCH 266 return resource.equalsHash(signature.node_id); 268 A.1.3. USER-NODE-MATCH 270 String.prototype['bytes'] = function() { 271 var bytes = []; 272 for (var i = 0; i < this.length; i++) { 273 bytes[i] = this.charCodeAt(i); 274 } 275 return bytes; 276 }; 278 var equals = function(a, b) { 279 if (a.length !== b.length) return false; 280 for (var i = 0; i < a.length; i++) { 281 if (a[i] !== b[i]) return false; 282 } 283 return true; 284 }; 286 return resource.equalsHash(signature.user_name.bytes()) 287 && equals(entry.key, signature.node_id); 289 A.1.4. NODE-MULTIPLE 290 Number.prototype['width'] = function(w) { 291 var bytes = []; 292 for (var i = 0; i < w; i++) { 293 bytes[i] = (this >>> ((w - i - 1) * 8)) & 255; 294 } 295 return bytes; 296 }; 298 for (var i = 0; i < kind.params['max-node-multiple']; i++) { 299 if (resource.equalsHash(signature.node_id, i.width(4))) { 300 return true; 301 } 302 } 303 return false; 305 A.2. Service Discovery Usage 307 [I-D.ietf-p2psip-service-discovery] defines a specific Access Control 308 Policy (NODE-ID-MATCH) that need to access the content of the entry 309 to be written. If implemented as specified by this document, the 310 element would look something like this: 312 315 DICTIONARY 316 NODE-ID-MATCH 317 100 318 60 319 2 321 322 /* Insert here the code from 323 http://jsfromhell.com/classes/bignumber 324 */ 326 var toBigNumber = function(node_id) { 327 var bignum = new BigNumber(0); 328 for (var i = 0; i < node_id.length; i++) { 329 bignum = bignum.multiply(256).add(node_id[i]); 330 } 331 return bignum; 332 }; 334 var checkIntervals = function(node_id, level, node, factor) { 335 var size = new BigNumber(2).pow(128); 336 var node = toBigNumber(node_id); 337 for (var f = 0; f < factor; f++) { 338 var temp = size.multiply(new BigNumber(f) 339 .pow(new BigNumber(level).negate())); 340 var min = temp.multiply(node.add(new BigNumber(f) 341 .divide(factor))); 342 var max = temp.multiply(node.add(new BigNumber(f + 1) 343 .divide(factor))); 344 if (node.compare(min) === -1 || node.compare(max) == 1 345 || node.compare(max) == 0) return false; 346 } 347 return true; 348 }; 350 var equals = function(a, b) { 351 if (a.length !== b.length) return false; 352 for (var i = 0; i < a.length; i++) { 353 if (a[i] !== b[i]) return false; 354 } 355 return true; 356 }; 358 var level = function(value) { 359 var length = value[16] * 256 + value[17]; 360 return value[18 + length] * 256 + value[18 + length + 1]; 361 }; 363 var node = function(value) { 364 var length = value[16] * 256 + value[17]; 365 return value[18 + length + 2] * 256 366 + value[18 + length + 3]; 367 }; 369 var namespace = function(value) { 370 var length = value[16] * 256 + value[17]; 371 return String.fromCharCode(value.slice(18, length)); 372 }; 374 return equals(entry.key, signature.node_id) 375 && (!entry.exists || checkIntervals(entry.key, 376 level(entry.value), node(entry.value), 377 kind.params['branching-factor'])) 378 && (!entry.exists 379 || resource.equalsHash(namespace(entry.value), 380 level(entry.value), node(entry.value))); 381 382 384 Note that the code for the BigNumber object was removed from this 385 example, as the licensing terms are unclear. The code is available 386 at . 388 The parameter is used to match the 389 parameter that is not accessible to the code. 390 The signer of the kind must be sure that the two match. In fact the 391 branching factor could have been set directly in the code, but that 392 would make it more difficult to change. 394 Appendix B. Release notes 396 This section must be removed before publication as an RFC. 398 B.1. Modifications between -01 and -00 400 o Changed reference from JavaScript to ECMAScript. 401 o Changed signature from equals() to equalsHash(). 402 o Fixed the examples following implementation. 403 o Replaced automatic decoding of value by ECMAScript code. 404 o Added the type of each property. 405 o Specified that the code cannot be used to modify the value stored. 407 B.2. TODO List 409 o Need to present the complete list of certificates for the DisCo 410 [I-D.knauf-p2psip-disco] Usage USER-CHAIN-MATCH. 412 Author's Address 414 Marc Petit-Huguenin 415 Stonyfish, Inc. 417 Email: petithug@acm.org