idnits 2.17.1 draft-tiloca-core-oscore-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2019) is 1871 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) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-01 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-04 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-19 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-22 -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track C. Amsuess 5 Expires: September 12, 2019 6 P. van der Stok 7 Consultant 8 March 11, 2019 10 Discovery of OSCORE Groups with the CoRE Resource Directory 11 draft-tiloca-core-oscore-discovery-02 13 Abstract 15 Group communication over the Constrained Application Protocol (CoAP) 16 can be secured by means of Object Security for Constrained RESTful 17 Environments (OSCORE). At deployment time, devices may not know the 18 exact OSCORE groups to join, the respective Group Manager, or other 19 information required to perform the joining process. This document 20 describes how CoAP endpoints can use the CoRE Resource Directory to 21 discover OSCORE groups and acquire information to join them through 22 their respective Group Manager. A same OSCORE group may protect 23 multiple application groups, which are separately announced in the 24 Resource Directory as sets of endpoints sharing a pool of resources. 25 This approach is consistent with, but not limited to, the joining of 26 OSCORE groups based on the ACE framework for Authentication and 27 Authorization in constrained environments. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 12, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Registration Resource for Group Managers . . . . . . . . . . 5 66 3. Registration of Group Manager Endpoints . . . . . . . . . . . 5 67 4. Addition and Update of OSCORE Groups . . . . . . . . . . . . 6 68 5. Discovery of OSCORE Groups . . . . . . . . . . . . . . . . . 7 69 5.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 8 70 5.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 7.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 76 8.2. Informative References . . . . . . . . . . . . . . . . . 11 77 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 A set of CoAP endpoints may share a common pool of resources, hence 83 composing an application group. All the members of an application 84 group may also be members of a same security group, hence sharing a 85 common set of keying material to secure group communication. 87 The Constrained Application Protocol (CoAP) [RFC7252] supports group 88 communication over IP multicast [RFC7390] to improve efficiency and 89 latency of communication and reduce bandwidth requirements. The 90 method Object Security for Constrained RESTful Environments (OSCORE) 91 [I-D.ietf-core-object-security] enables end-to-end security for CoAP 92 messages through CBOR Object Signing and Encryption (COSE) [RFC8152]. 94 In particular, [I-D.ietf-core-oscore-groupcomm] specifies how OSCORE 95 protects CoAP messages in group communication contexts, so enabling 96 OSCORE groups as security groups. Typically, one application group 97 relies on exactly one OSCORE group, while a same OSCORE group may be 98 used by multiple application groups at the same time. 100 A CoAP endpoint joins an OSCORE group via the responsible Group 101 Manager (GM), in order to get the necessary group keying material. 102 As in [I-D.ietf-ace-key-groupcomm-oscore], the joining process can be 103 based on the ACE framework for Authentication and Authorization in 104 constrained environments [I-D.ietf-ace-oauth-authz], with the joining 105 endpoint and the GM as ACE Client and Resource Server, respectively. 106 That is, the joining endpoint accesses the join resource associated 107 to the OSCORE group of interest and exported by the GM. 109 Typically, devices are equipped with a static X509 IDevID certificate 110 installed at manufacturing time. This certificate is used at 111 deployment time during an enrollment process that provides the device 112 with an Operational Certificate, possibly updated during the device 113 lifetime. In the presence of secure group communication for CoAP, 114 such an Operational Certificate may be accompanied by information 115 required to join OSCORE groups. This especially includes a reference 116 to the join resources to access at the respective GMs. 118 However, it is usually impossible to provide such precise information 119 to freshly deployed devices as part of their (early) Operational 120 Certificate. This can be due to a number of reasons: the OSCORE 121 group(s) to join and the responsible GM(s) are generally unknown at 122 manufacturing time; an OSCORE group of interest is created, or the 123 responsible GM is deployed, only after the device is enrolled and 124 fully operative in the network; information related to existing 125 OSCORE groups or to their GMs has been changed. This requires a 126 method for CoAP endpoints to dynamically discover OSCORE groups and 127 their GM, and to retrieve updated information about those groups. 129 This specification describes how CoAP endpoints can use the CoRE 130 Resource Directory (RD) [I-D.ietf-core-resource-directory] for 131 discovering an OSCORE group and retrieving the information required 132 to join that group through the responsible GM. In principle, the GM 133 registers as an endpoint with the RD. The corresponding registration 134 resource includes one link for each OSCORE group under that GM, 135 specifying the path to the related join resource. 137 More information about the OSCORE group is stored in the target 138 attributes of the respective link. This especially includes the 139 identifiers of the application groups which use that OSCORE group. 140 This enables a lookup of those application groups at the Resource 141 Directory, where they are separately announced by a Commissioning 142 Tool (see Appendix A of [I-D.ietf-core-resource-directory]). 144 When querying the RD for OSCORE groups, a CoAP endpoint can further 145 benefit of the CoAP Observe Option [RFC7641]. This enables 146 convenient notifications about the creation of new OSCORE groups or 147 the updates of information concerning existing ones. Thus, it 148 facilitates the early deployment of CoAP endpoints, i.e. even before 149 the GM is deployed and the OSCORE groups of interest are created. 151 The approach in this document is consistent with, but not limited to, 152 the joining of OSCORE groups in [I-D.ietf-ace-key-groupcomm-oscore]. 154 1.1. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119] [RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 This specification requires readers to be familiar with the terms and 163 concepts discussed in [I-D.ietf-core-resource-directory] and 164 [RFC6690]. Readers should also be familiar with the terms and 165 concepts discussed in [RFC7252], [I-D.ietf-core-oscore-groupcomm] and 166 [I-D.ietf-ace-key-groupcomm-oscore]. 168 Terminology for constrained environments, such as "constrained 169 device" and "constrained-node network", is defined in [RFC7228]. 171 This document also refers to the following terminology. 173 o OSCORE group: a set of CoAP endpoints that share a same OSCORE 174 Common Security Context to protect group communication as 175 described in [I-D.ietf-core-oscore-groupcomm]. That is, an OSCORE 176 group acts as security group for all its members. 178 o Application group: a set of CoAP endpoints that share a set of 179 common resources. Application groups are announced in the RD by a 180 Commissioning Tool, according to the RD-Groups usage pattern (see 181 Appendix A of [I-D.ietf-core-resource-directory]). An application 182 group can be associated to a single OSCORE group, while different 183 application groups can rely on the same OSCORE group. Application 184 groups MAY share resources. Any two application groups associated 185 to the same OSCORE group do not share any resource. 187 o Zeroed-epoch Group ID: this refers to the Group ID of an OSCORE 188 group as stored in the RD. The structure of such a stored Group 189 ID is as per Appendix C of [I-D.ietf-core-oscore-groupcomm], with 190 the "Group Epoch" part immutable and set to zero. 192 2. Registration Resource for Group Managers 194 With reference to Figure 3 of [I-D.ietf-core-resource-directory], a 195 Group Manager (GM) registers as an endpoint with the CoRE Resource 196 Directory (RD). The registration includes the links to the join 197 resources at the GM, associated to the OSCORE groups under that GM. 199 In particular, each link to a join resource includes: 201 o "target": URI of the join resource at the GM. 203 o target attributes, including: 205 * Resource Type (rt) with the value "core.osc.j" defined in 206 Section 7.1 of this specification. 208 * The zeroed-epoch Group ID of the OSCORE group. 210 * One target attribute for each application group associated to 211 the OSCORE group, specifying the name of that application 212 group. 214 3. Registration of Group Manager Endpoints 216 Upon deployment, a GM finds the RD as described in Section 4 of 217 [I-D.ietf-core-resource-directory]. After that, the GM registers as 218 an endpoint with the RD, as described in Section 5.3 of 219 [I-D.ietf-core-resource-directory]. 221 When doing so, the GM MUST also register all the join resources it is 222 exporting at that point in time, i.e. one for each of its OSCORE 223 groups. 225 For each registered join resource, the GM MUST specify the following 226 parameters in the payload of the registration request. 228 o 'rt' = "core.osc.j" (see Section 7.1). 230 o 'oscore-gid', specifying the zeroed-epoch Group ID of the OSCORE 231 group of interest. This parameter MUST specify a single value. 233 o 'app-gp', specifying the name(s) of the application group(s) 234 associated to the OSCORE group of interest. This parameter MAY be 235 included multiple times, and each occurrence MUST specify the name 236 of one application group. A same application group MUST NOT be 237 specified multiple times. 239 The GM SHOULD NOT use the Simple Registration approach described in 240 Section 5.3.1 of [I-D.ietf-core-resource-directory]. 242 The example below shows a GM with endpoint name "gm1" and address 243 2001:db8::ab that registers with the RD. The GM specifies the link 244 to one join resource for accessing the OSCORE group with zeroed-epoch 245 Group ID "feedca570000" and used by one application group with name 246 "group1". 248 Request: GM -> RD 250 Req: POST coap://rd.example.com/rd?ep=gm1 251 Content-Format: 40 252 Payload: 253 ;ct=41;rt="core.osc.j"; 254 oscore-gid="feedca570000";app-gp="group1" 256 Response: RD -> GM 258 Res: 2.01 Created 259 Location-Path: /rd/4521 261 4. Addition and Update of OSCORE Groups 263 The GM is responsible to keep its registration with the RD up to date 264 with links to all its join resources. This means that the GM has to 265 update the registration within its lifetime as per Section 5.4.1 of 266 [I-D.ietf-core-resource-directory], and has to change the content of 267 the registration when a join resource is added/removed or if its 268 target attributes have to be changed, such as in the following cases. 270 o The GM creates a new OSCORE group and starts exporting the related 271 join resource. 273 o The GM dismisses an OSCORE group and stops exporting the related 274 join resource. 276 o Information related to an existing OSCORE group changes, e.g. the 277 list of associated application groups. 279 In order to perform an update to the set of links in its 280 registration, the GM can re-register with the RD and fully specify 281 all links to its join resources and their target attributes in the 282 payload of the POST request. 284 The example below shows the same GM from Section 3 that re-registers 285 with the RD. When doing so, it specifies: 287 o The same previous join resource associated to the OSCORE group 288 with zeroed-epoch Group ID "feedca570000". 290 o A second join resource associated to the OSCORE group with zeroed- 291 epoch Group ID "ech0ech00000" and used by one application group, 292 namely "group2". 294 o A third join resource associated to the OSCORE group with zeroed- 295 epoch Group ID "abcdef120000" and used by two application groups, 296 namely "group3" and "group4". 298 Request: GM -> RD 300 Req: POST coap://rd.example.com/rd?ep=gm1 301 Content-Format: 40 302 Payload: 303 ;ct=41;rt="core.osc.j"; 304 oscore-gid="feedca570000";app-gp="group1", 305 ;ct=41;rt="core.osc.j"; 306 oscore-gid="ech0ech00000";app-gp="group2", 307 ;ct=41;rt="core.osc.j"; 308 oscore-gid="abcdef120000";app-gp="group3";app-gp="group4" 310 Response: RD -> GM 312 Res: 2.04 Changed 313 Location-Path: /rd/4521 315 Alternatively, the GM can perform a PATCH/iPATCH [RFC8132] request to 316 the RD, as per Section 5.4.3 of [I-D.ietf-core-resource-directory]. 317 This requires semantics to be defined in future standards, in order 318 to apply a link-format document as a patch to a different one. 320 5. Discovery of OSCORE Groups 322 A CoAP endpoint that wants to join an OSCORE group, hereafter called 323 the joining node, might not have all the necessary information at 324 deployment time. Also, it might want to know about possible new 325 OSCORE groups created afterwards by the respective Group Managers. 327 To this end, the joining node can perform a resource lookup at the RD 328 as per Section 6.1 of [I-D.ietf-core-resource-directory], in order to 329 retrieve the missing pieces of information needed to join the OSCORE 330 group(s) of interest. The joining node can find the RD as described 331 in Section 4 of [I-D.ietf-core-resource-directory]. 333 The joining node MUST consider the following search criteria for the 334 lookup filtering. 336 o 'rt' = "core.osc.j" (see Section 7.1). 338 The joining node MAY additionally consider the following search 339 criteria for the lookup filtering, depending on the information it 340 has already available. 342 o 'oscore-gid', specifying the zeroed-epoch Group ID of the OSCORE 343 group of interest. This parameter MUST specify a single value. 345 o 'ep', specifying the identifier of the GM as endpoint registered 346 with the RD. 348 o 'app-gp', specifying the name(s) of the application group(s) 349 associated to the OSCORE group of interest. This parameter MAY be 350 included multiple times, and each occurrence MUST specify the name 351 of one application group. A same application group MUST NOT be 352 specified multiple times. 354 5.1. Discovery Example #1 356 Consistently with the examples in Section 3 and Section 4, the 357 example below considers a joining node that wants to join the OSCORE 358 group associated to the application group "group1", but that does not 359 know the zeroed-epoch Group ID of the OSCORE group, the responsible 360 GM and the join resource to access. 362 Request: Joining node -> RD 364 Req: GET coap://rd.example.com/lookup/res?rt=core.osc.j&app-gp=group1 366 Response: RD -> Joining node 368 Res: 2.05 Content 369 Payload: 370 ;rt="core.osc.j"; 371 oscore-gid="feedca570000";app-gp="group1"; 372 anchor="coap://[2001:db8::ab]" 374 If it does not know the multicast IP address used in "group1", the 375 joining node can retrieve it by performing an endpoint lookup as 376 shown below. The following assumes that the application group 377 "group1" had been previously registered as per Appendix A of 378 [I-D.ietf-core-resource-directory], with ff35:30:2001:db8::23 as 379 associated multicast IP address. 381 Request: Joining node -> RD 383 Req: GET coap://rd.example.com/lookup/ep?et=core.rd-group&ep=group1 385 Response: RD -> Joining node 387 Res: 2.05 Content 388 Payload: 389 ;ep="group1";et="core.rd-group";\ 390 base="coap://[ff35:30:2001:db8::23]" 392 5.2. Discovery Example #2 394 Consistently with the examples in Section 3 and Section 4, the 395 example below considers a joining node that wants to join the OSCORE 396 group with zeroed-epoch Group ID "feedca570000", but that does not 397 know the responsible GM, the join resource to access, and the 398 associated application groups. 400 The example also shows how the joining node uses observation 401 [RFC7641], in order to be notified of possible changes in the join 402 resource's target attributes. This is also useful to handle the case 403 where the OSCORE group of interest has not been created yet, so that 404 the joining node can receive the requested information when available 405 at a later point in time. 407 Request: Joining node -> RD 409 Req: GET coap://rd.example.com/lookup/res?rt=osc.j&\ 410 oscore-gid=feedca570000 411 Observe: 0 413 Response: RD -> Joining node 415 Res: 2.05 Content 416 Observe: 24 417 Payload: 418 ;rt="osc.j"; 419 oscore-gid="feedca570000";app-gp="group1"; 420 anchor="coap://[2001:db8::ab]" 422 Depending on the used search criteria, the joining node performing 423 the resource lookup can get a response whose payload is quite large 424 in size. This can happen, for instance, in case the lookup request 425 targets all the join resources at a specified GM, or all the join 426 resources of all the registered GMs, as in the example below. 428 Request: Joining node -> RD 429 Req: GET coap://rd.example.com/lookup/res?rt=osc.j 431 Response: RD -> Joining node 433 Res: 2.05 Content 434 Payload: 435 ;rt="osc.j"; 436 oscore-gid="feedca570000";app-gp="group1"; 437 anchor="coap://[2001:db8::ab]", 438 ;rt="osc.j"; 439 oscore-gid="ech0ech00000";app-gp="group2"; 440 anchor="coap://[2001:db8::ab]", 441 ;rt="osc.j"; 442 oscore-gid="abcdef120000";app-gp="group3";app-gp="group4"; 443 anchor="coap://[2001:db8::cd]" 445 Therefore, it is RECOMMENDED that a joining node performing a 446 resource lookup to discover OSCORE groups uses observation only when 447 including the fine-grained seach criterion 'oscore-gid' in its GET 448 request sent to the RD. 450 6. Security Considerations 452 The security considerations as described in Section 8 of 453 [I-D.ietf-core-resource-directory] apply here as well. 455 7. IANA Considerations 457 This document has the following actions for IANA. 459 7.1. Resource Types 461 IANA is asked to enter the following value into the Resource Type 462 (rt=) Link Target Attribute Values subregistry within the Constrained 463 Restful Environments (CoRE) Parameters registry defined in [RFC6690]. 465 +------------+----------------------+-------------------+ 466 | Value | Description | Reference | 467 +------------+----------------------+-------------------+ 468 | | | | 469 | core.osc.j | Join resource of an | [[this document]] | 470 | | OSCORE Group Manager | | 471 | | | | 472 +------------+----------------------+-------------------| 474 8. References 476 8.1. Normative References 478 [I-D.ietf-ace-key-groupcomm-oscore] 479 Tiloca, M., Park, J., and F. Palombini, "Key Management 480 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 481 oscore-01 (work in progress), March 2019. 483 [I-D.ietf-core-oscore-groupcomm] 484 Tiloca, M., Selander, G., Palombini, F., and J. Park, 485 "Group OSCORE - Secure Group Communication for CoAP", 486 draft-ietf-core-oscore-groupcomm-04 (work in progress), 487 March 2019. 489 [I-D.ietf-core-resource-directory] 490 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 491 Amsuess, "CoRE Resource Directory", draft-ietf-core- 492 resource-directory-19 (work in progress), January 2019. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, 496 DOI 10.17487/RFC2119, March 1997, 497 . 499 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 500 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 501 . 503 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 504 Application Protocol (CoAP)", RFC 7252, 505 DOI 10.17487/RFC7252, June 2014, 506 . 508 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 509 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 510 May 2017, . 512 8.2. Informative References 514 [I-D.ietf-ace-oauth-authz] 515 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 516 H. Tschofenig, "Authentication and Authorization for 517 Constrained Environments (ACE) using the OAuth 2.0 518 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22 519 (work in progress), March 2019. 521 [I-D.ietf-core-object-security] 522 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 523 "Object Security for Constrained RESTful Environments 524 (OSCORE)", draft-ietf-core-object-security-16 (work in 525 progress), March 2019. 527 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 528 Constrained-Node Networks", RFC 7228, 529 DOI 10.17487/RFC7228, May 2014, 530 . 532 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 533 the Constrained Application Protocol (CoAP)", RFC 7390, 534 DOI 10.17487/RFC7390, October 2014, 535 . 537 [RFC7641] Hartke, K., "Observing Resources in the Constrained 538 Application Protocol (CoAP)", RFC 7641, 539 DOI 10.17487/RFC7641, September 2015, 540 . 542 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 543 FETCH Methods for the Constrained Application Protocol 544 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 545 . 547 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 548 RFC 8152, DOI 10.17487/RFC8152, July 2017, 549 . 551 Acknowledgments 553 The authors sincerely thank Carsten Bormann, Francesca Palombini and 554 Jim Schaad for their comments and feedback. 556 The work on this document has been partly supported by VINNOVA and 557 the Celtic-Next project CRITISEC, and by the EIT-Digital High Impact 558 Initiative ACTIVE. 560 Authors' Addresses 562 Marco Tiloca 563 RISE AB 564 Isafjordsgatan 22 565 Kista SE-16440 Stockholm 566 Sweden 568 Email: marco.tiloca@ri.se 569 Christian Amsuess 570 Hollandstr. 12/4 571 Vienna 1020 572 Austria 574 Email: christian@amsuess.com 576 Peter van der Stok 577 Consultant 579 Phone: +31-492474673 (Netherlands), +33-966015248 (France) 580 Email: consultancy@vanderstok.org 581 URI: www.vanderstok.org