idnits 2.17.1 draft-gerdes-ace-actors-03.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 : ---------------------------------------------------------------------------- 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 09, 2015) is 3334 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-ace-usecases-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group S. Gerdes 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational March 09, 2015 5 Expires: September 10, 2015 7 Actors in the ACE Architecture 8 draft-gerdes-ace-actors-03 10 Abstract 12 Constrained nodes are small devices which are limited in terms of 13 processing power, memory, non-volatile storage and transmission 14 capacity. Due to these constraints, commonly used security protocols 15 are not easily applicable. Nevertheless, an authentication and 16 authorization solution is needed to ensure the security of these 17 devices. 19 Due to the limitations of the constrained nodes it is especially 20 important to develop a light-weight security solution which is 21 adjusted to the relevant security objectives of each participating 22 party in this environment. Necessary security measures must be 23 identified and applied where needed. 25 In this document, the required security related tasks are identified 26 as guidance for the development of authentication and authorization 27 solutions for constrained environments. Based on the tasks, an 28 architecture is developed to represent the relationships between the 29 logical functional entities involved. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 10, 2015. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Security Objectives . . . . . . . . . . . . . . . . . . . . . 5 69 4. Authentication and Authorization . . . . . . . . . . . . . . 6 70 5. Autonomous Communication . . . . . . . . . . . . . . . . . . 7 71 6. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Basic Scenario Tasks . . . . . . . . . . . . . . . . . . 8 73 6.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 8 74 6.3. Authentication-Related Tasks . . . . . . . . . . . . . . 8 75 6.4. Authorization-Related Tasks . . . . . . . . . . . . . . . 9 76 7. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Constrained Level Actors . . . . . . . . . . . . . . . . 10 78 7.2. Principal Level Actors . . . . . . . . . . . . . . . . . 11 79 7.3. Less-Constrained Level Actors . . . . . . . . . . . . . . 12 80 8. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 13 81 8.1. Constrained Level Protocols . . . . . . . . . . . . . . . 14 82 8.1.1. Cross Level Support Protocols . . . . . . . . . . . . 14 83 8.2. Less-Constrained Level Protocols . . . . . . . . . . . . 14 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 87 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 89 12.2. Informative References . . . . . . . . . . . . . . . . . 15 90 Appendix A. List of Tasks . . . . . . . . . . . . . . . . . . . 16 91 A.1. Basic Scenario . . . . . . . . . . . . . . . . . . . . . 16 92 A.1.1. Processing Information . . . . . . . . . . . . . . . 17 93 A.1.2. Sending Information . . . . . . . . . . . . . . . . . 18 94 A.2. Security-Related Tasks . . . . . . . . . . . . . . . . . 20 95 A.2.1. Information Authenticity . . . . . . . . . . . . . . 20 96 A.2.2. Authorization Validation . . . . . . . . . . . . . . 21 97 A.2.3. Transmission Security . . . . . . . . . . . . . . . . 22 98 A.2.4. Obtain Authorization information . . . . . . . . . . 23 99 A.2.5. Attribute Binding . . . . . . . . . . . . . . . . . . 24 100 A.2.6. Configuration of Authorization Information . . . . . 26 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 Constrained nodes are small devices with limited abilities which in 106 many cases are made to fulfill a single simple task. They have 107 limited hardware resources such as processing power, memory, non- 108 volatile storage and transmission capacity and additionally in most 109 cases do not have user interfaces and displays. Due to these 110 constraints, commonly used security protocols are not always easily 111 applicable. 113 Constrained nodes are expected to be integrated in all aspects of 114 everyday life and thus will be entrusted with vast amounts of data. 115 Without appropriate security mechanisms attackers might gain control 116 over things relevant to our lives. Authentication and authorization 117 mechanisms are therefore prerequisites for a secure Internet of 118 Things. 120 The limitations of the constrained nodes ask for security mechanisms 121 which take the special characteristics of constrained environments 122 into account. Therefore, it is crucial to identify the tasks which 123 must be performed to meet the security requirements in constrained 124 scenarios. Moreover, these tasks need to be assigned to logical 125 functional entities which perform the tasks: the actors in the 126 architecture. Thus, relations between the actors and requirements 127 for protocols can be identified. 129 In this document, the required security related tasks are identified 130 as guidance for the development of authentication and authorization 131 solutions for constrained environments. Based on the tasks, an 132 architecture is developed to represent the relationships between the 133 logical functional entities involved. 135 1.1. Terminology 137 Readers are required to be familiar with the terms and concepts 138 defined in [RFC4949]. In addition, this document uses the following 139 terminology: 141 Resource (R): an item of interest, which is represented through an 142 interface. It might contain sensor or actuator values or other 143 information. 145 Constrained node: a constrained device in the sense of [RFC7228]. 147 Actor: A logical functional entity that performs one or more tasks. 148 Depending on the tasks an actor must perform, the device that 149 contains the actor may need to have certain system resources 150 available. Multiple actors may share, i.e. be present within, a 151 device or even a piece of software. 153 Server (S): An entity which hosts and represents a Resource. 155 Client (C): An entity which attempts to access a resource on a 156 Server. 158 Resource Overseeing Principal (ROP): The principal that is in charge 159 of the resource and controls its access permissions. 161 Client Overseeing Principal (COP): The principal that is in charge 162 of the Client and controls permissions concerning authorized 163 representations of a Resource. 165 Server Authorization Manager (SAM): An entity that prepares and 166 endorses authentication and authorization data for a Server. 168 Client Authorization Manager (CAM): An entity that prepares and 169 endorses authentication and authorization data for a Client. 171 Attribute Binding Authority: An entity that is authorized to 172 validate claims about an entity. 174 2. Problem Statement 176 The scenario this document addresses can be summarized as follows: 178 o C wants to access R on a S. 180 o A priori, C and S do not necessarily know each other and have no 181 security relationship. 183 o C and / or S are constrained. 185 ------- ------- 186 | C | -- requests resource ---> | S | 187 ------- <-- provides resource--- ------- 189 Figure 1: Basic Scenario 191 There are some security requirements for this scenario including one 192 or more of: 194 o Rq0.1: No unauthorized entity has access to (or otherwise gains 195 knowledge of) R. 197 o Rq0.2: C is exchanging status updates of a resource only with 198 authorized resources. (When C attempts to access R, that access 199 reaches an authorized R). 201 Rq0.1 requires authorization on the server side while Rq0.2 requires 202 authorization on the client side. 204 3. Security Objectives 206 The security objectives that can be addressed by an authorization 207 solution are confidentiality and integrity. Availability cannot be 208 achieved by authorization solutions. However, misconfigured or 209 wrongly designed authorization solutions can result in availability 210 breaches: Users might no longer be able to use data and services as 211 they are supposed to. 213 Authentication mechanisms can achieve additional security objectives 214 such as non-repudiation and accountability. They are not related to 215 authorization and thus are not in scope of this draft, but still 216 should be considered by Authenticated Authorization solutions. Non- 217 repudiation and accountability may require authentication on device 218 level, if it is necessary to determine which device performed an 219 action. In other cases it may be more important to find out who is 220 responsible for the device's actions. 222 The importance of a security objective depends on the application the 223 authorization mechanism is used for. [I-D.ietf-ace-usecases] 224 indicates that security objectives differ for the various constrained 225 environment use cases. 227 In many cases, one participating party might have different security 228 objectives than the other. However, to achieve a security objective, 229 both parties must participate in providing a solution. E.g., if COP 230 requires the integrity of sensor value representations S is hosting, 231 Both C and S need to integrity-protect the transmitted data. 232 Moreover, S needs to protect the access to the sensor representation 233 to prevent unauthorized users to manipulate the sensor values. 235 4. Authentication and Authorization 237 Authorization solutions aim at protecting the access to items of 238 interest, e.g. hardware or software resources or data: They enable 239 the principal of such a resource to control who can access it and 240 how. 242 To determine if an entity is authorized to access a resource, an 243 authentication mechanism is needed. According to the Internet 244 Security Glossary [RFC4949], authentication is "the process of 245 verifying a claim that a system entity or system resource has a 246 certain attribute value." Examples for attribute values are the ID 247 of a device, the type of the device or the name of its owner. 249 The security objectives the authorization mechanism aims at can only 250 be achieved if the authentication and the authorization mechanism 251 work together correctly. We use the term _authenticated 252 authorization_ to refer to a synthesis of mechanism for 253 authentication and authorization. 255 If used for authorization, the authenticated attributes must be 256 meaningful for the purpose of the authorization, i.e. the 257 authorization policy grants access permissions based on these 258 attributes. If the authorization policy assigns permissions to an 259 individual entity, the authenticated attributes must be suitable to 260 uniquely identify this entity. 262 In scenarios where devices are communicating autonomously there is 263 less need to uniquely identify an individual device. For a 264 principal, the fact that a device belongs to a certain company or 265 that it has a specific type (e.g. light bulb) is likely more 266 important than that it has a unique identifier. 268 Resource and device overseeing principals need to decide about the 269 required level of granularity for the authorization, ranging from 270 _device authorization_ over _owner authorization_ to _binary 271 authorization_ and _unrestricted authorization_. In the first case 272 different access permissions are granted to individual devices while 273 in the second case individual owners are authorized. If binary 274 authorization is used, all authenticated entities have the same 275 access permissions. Unrestricted authorization for an item of 276 interest means that no authorization mechanism is used (not even by 277 authentication) and all entities are able to access the item as they 278 see fit. More fine-grained authorization does not necessarily 279 provide more security. Resource and device overseeing principals 280 need to consider that an entity should only be granted the 281 permissions it really needs to ensure the confidentiality and 282 integrity of resources. 284 For all cases where an authorization solution is needed (all but 285 Unrestricted Authorization), the authorizing party needs to be able 286 to authenticate the party that is to be authorized. Authentication 287 is therefore required for messages that contain representations of an 288 accessed item. More precisely, the authorizing party needs to make 289 sure that the receiver of a message containing a representation, and 290 the sender of a message containing a representation are authorized to 291 receive and send this message, respectively. To achieve this, the 292 integrity of these messages is required: Authenticity cannot be 293 assured if it is possible for an attacker to modify the message 294 during transmission. 296 In some cases, only one side (only the client side or only the server 297 side) requires the integrity and / or confidentiality of a resource 298 value. In these cases, principals may decide to use binary 299 authorization which can be achieved by an authentication mechanism or 300 even unrestricted authorization where no authentication mechanism is 301 required. However, as indicated in Section 3, the security 302 objectives of both sides must be considered. The security objectives 303 of one side can often only be achieved with the help of the other 304 side. E.g., if the server requires the confidentiality of a resource 305 representation, the client must make sure that it does not send 306 resource updates to parties other than the server. Therefore, the 307 client must at least use binary authorization. 309 5. Autonomous Communication 311 The use cases defined in [I-D.ietf-ace-usecases] demonstrate that 312 constrained devices are often used for scenarios where their 313 principals are not present at the time of the communication. 314 Moreover, these devices often do not have any user interfaces or 315 displays. Even if the principals are present at the time of access, 316 they may not be able to communicate directly with the device. The 317 devices therefore need to be able to communicate autonomously. In 318 some scenarios there is an active user at one endpoint of the 319 communication. Other scenarios ask for true machine to machine (M2M) 320 communication. 322 To achieve the principals' security objectives, the devices must be 323 enabled to enforce the security policies of their principals. 325 6. Tasks 327 This section gives an overview of the tasks which must be performed 328 in the given scenario (see Section 2) to meet the security 329 requirements. 331 As described in the problem statement, either C or S or both of them 332 are constrained. Therefore tasks which must be conducted by either C 333 or S must be performable by constrained nodes. 335 6.1. Basic Scenario Tasks 337 This document does not assume a specific solution. We assume 338 however, that at least the following information is exchanged between 339 the client and the server: 341 o C transmits to S which resource it requests to access, the kind of 342 action it wants to perform on the resource, and the parameters 343 needed for the action. 345 o S transmits to C the result of the attempted access. 347 6.2. Security-Related Tasks 349 The reason for the communication is that C wants S to process some 350 information. S' reaction to C's access request might be processed by 351 C. The reason for using an authorization solution is to validate 352 that the entity that sent the information used for processing is 353 authorized to provide it. 355 To validate if a sender is authorized to send a received piece of 356 information, the receiver must determine the sender's authorization. 357 Correspondingly, to validate if a receiver is allowed to receive a 358 message, the sender must determine its authorization. This can only 359 be achieved with the help of an authentication mechanism. 361 6.3. Authentication-Related Tasks 363 Several steps must be conducted for authenticating certain attributes 364 of an entity and validating the authenticity of an information: 366 1. Attribute binding: The attribute that shall be verifiable must be 367 bound to a verifier, e.g. a key. To achieve this, an entity that 368 is authorized to conduct the attribute binding, the attribute 369 binding authority, checks if an entity actually has the 370 attributes it claims to have and then binds them to a verifier. 371 The binding authority must provide some kind of endorsement 372 information which enables other entities to validate this 373 binding. 375 Note: The attribute binding can be conducted using either symmetric 376 or asymmetric cryptography. 378 1. Verifier validation: The entity that wants to authenticate the 379 source of an information checks the attribute-verifier-binding 380 using the endorsement provided by the attribute binding 381 authority. 383 2. Authentication: The verifier is used for authenticating the 384 source of a data item, i.e. it is checked whether the data item 385 is bound to the verifier. Thus the attributes of the source can 386 be determined. 388 Step 1 is addressed in Appendix A.2.5. After the first step is 389 conducted, step 2 and step 3 can be performed when needed. They must 390 be performed together and thus are examined together as well. Tasks 391 for step 2 and 3 are Information authenticity (see Appendix A.2.1) 392 and secure communication (see Appendix A.2.3). 394 6.4. Authorization-Related Tasks 396 Several steps must be conducted for explicit authorization: 398 1. Configuration of authorization information: The respective 399 principals (COP and ROP) must configure the authorization 400 information according to their authorization policy. An 401 authorization information must contain one or more permissions 402 and the attribute an entity must have to apply to this 403 authorization. 405 2. Obtaining authorization information: Authorization information 406 must be made available to the entity which enforces the 407 authorization. 409 3. Authorization validation: The authorization of an entity with 410 certain attributes must be confirmed by applying the request in 411 conjunction with authenticated attributes to the policy provided 412 by the authorization information. 414 4. Authorization enforcement: According to the result of the 415 authorization validation the access to a resource is granted or 416 denied. 418 Tasks for step 1 are defined in Appendix A.2.6. Appendix A.2.4 419 addresses step 2. After step 1 and step 2 are conducted, step 3 and 420 step 4 can be performed when needed. Step 3 and step 4 must be 421 performed together and thus are examined together. Appendix A.2.2 422 introduces tasks for these steps. 424 7. Actors 426 This section describes the various actors in the architecture. An 427 actor consists of a set of tasks and additionally has an security 428 domain (client domain or server domain) and a level (constrained, 429 principal, less-constrained). Tasks are assigned to actors according 430 to their security domain and required level. 432 Note: Actors are a concept to understand the security requirements 433 for constrained devices. The architecture of an actual solution 434 might differ as long as the security requirements that derive from 435 the relationship between the identified actors are considered. 436 Several actors might share a single device or even be combined in a 437 single piece of software. Interfaces between actors may be realized 438 as protocols or be internal to such a piece of software. 440 The concept of actors is used to assign the tasks defined in 441 Appendix A to logical functional entities. 443 7.1. Constrained Level Actors 445 As described in the problem statement (see Section 2), either C or S 446 or both of them may be located on a constrained node. We therefore 447 define that C and S must be able to perform their tasks even if they 448 are located on a constrained node. Thus, C and S are considered to 449 be Constrained Level Actors. 451 C performs the following tasks: 453 o Negotiate means for secure communication (Task TSecureComm, see 454 Appendix A.2.3). 456 o Validate that an entity is an authorized source for R (Task 457 TValSourceAuthz, see Appendix A.2.2). 459 o Securely transmit an access request (Task TSendReq, see 460 Appendix A.1.2). 462 o Validate that the response to an access request is authentic (Task 463 TAuthnResp, see Appendix A.2.1). 465 o Process the response to an access request (Task TProcResp, see 466 Appendix A.1.1). 468 S performs the following tasks: 470 o Negotiate means for secure communication (Task TSecureComm, see 471 Appendix A.2.3). 473 o Validate the authenticity of an access request (Task TAuthnReq, 474 see Appendix A.2.1). 476 o Validate the authorization of the requester to access the 477 requested resource as requested (Task TValAccessAuthZ, see 478 Appendix A.2.2). 480 o Process an access request (Task TProcReq, see Appendix A.1.1). 482 o Securely transmit a response to an access request (Task TSendResp, 483 see Appendix A.1.2). 485 R is an item of interest such as a sensor or actuator value. R is 486 considered to be part of S and not a separate actor. The device on 487 which S is located might contain several resources of different 488 Resource Overseeing Principals. For simplicity of exposition, these 489 resources are described as if they had separate S. 491 As C and S do not necessarily know each other they might belong to 492 different security domains. 494 ------- ------- 495 | C | -- requests resource ---> | S | Constrained Level 496 ------- <-- provides resource--- ------- 498 Figure 2: Constrained Level Actors 500 7.2. Principal Level Actors 502 Our objective is that C and S are under control of principals in the 503 physical world, the Client Overseeing Principal (COP) and the 504 Resource Overseeing Principal (ROP) respectively. The principals 505 decide about the security policies of their respective devices and 506 belong to the same security domain. 508 COP is in charge of C, i.e. COP specifies security policies for C, 509 e.g. with whom C is allowed to communicate. By definition, C and COP 510 belong to the same security domain. 512 COP must fulfill the following task: 514 o Configure for C authorization information for sources for R (Task 515 TConfigSourceAuthz, see Appendix A.2.6). 517 ROP is in charge of R and S. ROP specifies authorization policies 518 for R and decides with whom S is allowed to communicate. By 519 definition, R, S and ROP belong to the same security domain. 521 ROP must fulfill the following task: 523 o Configure for S authorization information for accessing R (Task 524 TConfigAccessAuthz, see Appendix A.2.6). 526 ------- ------- 527 | COP | | ROP | Principal Level 528 ------- ------- 529 | | 530 in charge of in charge of 531 | | 532 V V 533 ------- ------- 534 | C | -- requests resource ---> | S | Constrained Level 535 ------- <-- provides resource--- ------- 537 Figure 3: Constrained Level Actors and Principal Level Actors 539 7.3. Less-Constrained Level Actors 541 Constrained level actors can only fulfill a limited number of tasks 542 and may not have network connectivity all the time. To relieve them 543 from having to manage keys for numerous devices and conducting 544 computationally intensive tasks, another complexity level for actors 545 is introduced. An actor on the less-constrained level belongs to the 546 same security domain as its respective constrained level actor. They 547 also have the same principal. 549 The Client Authorization Manager (CAM) belongs to the same security 550 domain as C and COP. CAM acts on behalf of COP. It assists C in 551 authenticating S and determining if S is an authorized source for R. 552 CAM can do that because for C, CAM is the authority for claims about 553 S. 555 CAM performs the following tasks: 557 o Validate on the client side that an entity has certain attributes 558 (Task TValSourceAttr, see Appendix A.2.5). 560 o Obtain authorization information about an entity from C's 561 principal and provide it to C. (Task TObtainSourceAuthz, see 562 Appendix A.2.4). 564 o Negotiate means for secure communication to communicate with C 565 (Task TSecureComm, see Appendix A.2.3). 567 The Server Authorization Manager (SAM) belongs to the same security 568 domain as R, S and ROP. SAM acts on behalf of ROP. It supports S by 569 authenticating C and determining C's permissions on R. SAM can do 570 that because for S, SAM is the authority for claims about C. 572 SAM performs the following tasks: 574 o Validate on the server side that an entity has certain attributes 575 (Task TValReqAttr, see Appendix A.2.5). 577 o Obtain authorization information about an entity from S' principal 578 and provide it to S (Task TObtainAccessAuthz, see Appendix A.2.4). 580 o Negotiate means for secure communication to communicate with S 581 (Task TSecureComm, see Appendix A.2.3). 583 ------- ------- 584 | COP | | ROP | Principal Level 585 ------- ------- 586 | | 587 in charge of in charge of 588 | | 589 V V 590 ---------- ----------- 591 | CAM | <- AuthN and AuthZ -> | SAM | Less-Constrained Level 592 ---------- ----------- 593 | | 594 authentication authentication 595 and authorization and authorization 596 support support 597 | | 598 V V 599 ------- ------- 600 | C | -- requests resource ---> | S | Constrained Level 601 ------- <-- provides resource -- ------- 603 Figure 4: Overview of all Complexity Levels 605 For more detailed graphics please consult the PDF version. 607 8. Protocol Requirements 609 Devices on the less-constrained level potentially are more powerful 610 than constrained level devices in terms of processing power, memory, 611 non-volatile storage. This results in different requirements for the 612 protocols used on these levels. 614 8.1. Constrained Level Protocols 616 A protocol is considered to be on the constrained level if it is used 617 between the actors C and S which are considered to be constrained 618 (see Section 7.1). C and S might not belong to the same security 619 domain. Therefore, constrained level protocols are required to work 620 between different security domains. 622 Commonly used Internet protocols can not in every case be applied to 623 constrained environments. In some cases, tweaking and profiling is 624 required. In other cases it is beneficial to define new protocols 625 which were designed with the special characteristics of constrained 626 environments in mind. 628 On the constrained level, protocols must be used which address the 629 specific requirements of constrained environments. The Constrained 630 Application Protocol (CoAP) [RFC7252] should be used as transfer 631 protocol if possible. CoAP defines a security binding to Datagram 632 Transport Layer Security Protocol (DTLS) [RFC6347]. Thus, DTLS 633 should be used for channel security. 635 Constrained devices have only limited storage space and thus cannot 636 store large numbers of keys. This is especially important because 637 constrained networks are expected to consist of thousands of nodes. 638 Protocols on the constrained level should keep this limitation in 639 mind. 641 8.1.1. Cross Level Support Protocols 643 Protocols which operate between a constrained device on one side and 644 the corresponding less constrained device on the other are considered 645 to be (cross level) support protocols. Protocols used between C and 646 CAM or S and SAM are therefore support protocols. 648 Support protocols must consider the limitations of their constrained 649 endpoint and therefore belong to the constrained level protocols. 651 8.2. Less-Constrained Level Protocols 653 A protocol is considered to be on the less-constrained level if it is 654 used between the actors CAM and SAM. CAM and SAM might belong to 655 different security domains. 657 On the less-constrained level, HTTP [RFC7230] and Transport Layer 658 Security (TLS) [RFC5246] can be used alongside or instead of CoAP and 659 DTLS. Moreover, existing security solutions for authentication and 660 authorization such as the Web Authorization Protocol (OAuth) 661 [RFC6749] and Kerberos [RFC4120] can likely be used without 662 modifications and there are no limitations for the use of a Public 663 Key Infrastructure (PKI). 665 9. IANA Considerations 667 None 669 10. Security Considerations 671 This document discusses security requirements for the ACE 672 architecture. 674 11. Acknowledgments 676 The author would like to thank Carsten Bormann, Olaf Bergmann, Robert 677 Cragie and Klaus Hartke for their valuable input and feedback. 679 12. References 681 12.1. Normative References 683 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 684 Constrained-Node Networks", RFC 7228, May 2014. 686 12.2. Informative References 688 [I-D.ietf-ace-usecases] 689 Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. 690 Kumar, "ACE use cases", draft-ietf-ace-usecases-02 (work 691 in progress), February 2015. 693 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 694 Kerberos Network Authentication Service (V5)", RFC 4120, 695 July 2005. 697 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 698 4949, August 2007. 700 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 701 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 703 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 704 Security Version 1.2", RFC 6347, January 2012. 706 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 707 6749, October 2012. 709 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 710 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 711 2014. 713 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 714 Application Protocol (CoAP)", RFC 7252, June 2014. 716 Appendix A. List of Tasks 718 This section defines the tasks which must be performed in the given 719 scenario (see Section 2) starting from communication related tasks 720 and then deriving the required security-related tasks. An overview 721 of the tasks can be found in Section 6. 723 A task has the following structure: 725 o The name of the task which has the form TXXX 727 o One or more Requirements (if applicable) of the form RqXXX 729 o One or more Preconditions (if applicable) of the form PreXXX 731 o One or more Postconditions (if applicable) of the form PostXXX 733 Requirements have to be met _while_ performing the task. They derive 734 directly from the scenario (see Section 2) or from the security 735 requirements defined for the scenario. Preconditions have to be 736 fulfilled _before_ conducting the task. Postconditions are the 737 _results_ of the completed task. 739 We start our analysis with the processing tasks and define which 740 preconditions need to be fulfilled before these tasks can be 741 conducted. We then determine which tasks therefore need to be 742 performed first (have postconditions which match the respective 743 preconditions). 745 Note: Regarding the communication, C and S are defined as entities 746 each having their set of attributes and a verifier which is bound to 747 these attributes. Attributes are not necessarily usable to identify 748 an individual C or S. Several entities might have the same 749 attributes. 751 A.1. Basic Scenario 753 The intended result of the interaction between C and S is that C has 754 successfully accessed R. C gets to know that its access request was 755 successful by receiving the answer from S. 757 The transmission of information from C to S comprises two parts: 758 sending the information on one side and receiving and processing it 759 on the other. Security has to be considered at each of these steps. 761 A.1.1. Processing Information 763 The purpose of the communication between C and S is C's intent to 764 access R. To achieve this, S must process the information about the 765 requested access and C must process the information in the response 766 to a requested access. The request and the response might both 767 contain resource values. 769 The confidentiality and integrity of R require that only authorized 770 entities are able to access R (see Rq0.1). Therefore, C and S must 771 check that the information is authentic and that the source of the 772 information is authorized to provide it, before the information can 773 be processed. C must validate that S is an authorized source for R. 774 S must validate that C is authorized to access R as requested. 776 If proxies are used, it depends on the type of proxy how they are 777 integrated into the communication and what kind of security 778 relationships need to be established. A future version of this 779 document will provide more details on this topic. At this point we 780 assume that C and S might receive the information either from S or C 781 directly or from a proxy which is authorized to speak for the 782 respective communication partner. 784 o Task TProcResp: Process the response to an access request. 785 Description: C processes the response to an access request 786 according to the reason for requesting the resource in the first 787 place. The response might include resource values or information 788 about the results of a request. 789 Requirements: 790 * RqProcResp.1: Is performed by C (derives from the problem 791 statement). 792 * RqProcResp.2: Must be performable by a constrained device 793 (derives from the problem statement: C and / or S are 794 constrained). 795 Preconditions: 796 * PreProcResp.1: A response to an access request was sent (see 797 Appendix A.1.2). 798 * PreProcResp.2 (required for Rq0.2): C validated that the 799 response to an access request is authentic, i.e. it stems from the 800 entity requested in TSendReq (see Appendix A.1.2), i.e. S or an 801 entity which is authorized to speak for S (see Appendix A.2.1). 802 * PreProcResp.3 (required for Rq0.2): C validated that S or the 803 entity which is authorized to speak for S is an authorized source 804 for R (see Appendix A.2.2). 806 Postcondition: 807 * PostProcResp.1: C processed the response. 809 o Task TProcReq: Process an access request. 810 Description: S either performs an action on the resource according 811 to the information in the request, or determines the reason for 812 not performing an action. 813 Requirements: 814 * RqProcReq.1: Is performed by S. 815 * RqProcReq.2: Must be performable by a constrained device 816 (derives from the problem statement: C and / or S are 817 constrained). 818 Preconditions: 819 * PreProcReq.1: An access request was sent (see Appendix A.1.2). 820 * PreProcReq.2 (needed for Rq0.1): S validated that the request is 821 authentic, i.e. it stems from C or an entity which is authorized 822 to speak for C and is fresh. (see Appendix A.2.1). 823 * PreProcReq.3 (needed for Rq0.1): S validated the authorization 824 of C or the entity which is authorized to speak for C to access 825 the resource as requested (see Appendix A.2.2). 826 Postconditions: 827 * PostProcReq.1: The access request was processed (fulfills 828 PreSendResp.1, see Appendix A.1.2). 830 Note: The preconditions PreProcReq.2 and PreProcReq.3 must be 831 conducted together. S must assure that the response is bound to a 832 verifier, the verifier is bound to certain attributes and the 833 authorization information refers to these attributes. 835 A.1.2. Sending Information 837 The information needed for processing has to be transmitted at some 838 point. C has to transmit to S which resource it wants to access with 839 which actions and parameters. S has to transmit to C the result of 840 the request. The request and the response might both contain 841 resource values. To fulfill Rq0.1, the confidentiality and integrity 842 of the transmitted data has to be assured. 844 If proxies are used, it depends on the type of proxy how they need to 845 be handled. A future version of this document will provide more 846 details on this topic. At this point we assume that C and S might 847 transmit the message either to S and C directly or to a proxy which 848 is authorized to speak for the respective communication partner. 850 o Task TSendReq: Securely transmit an access request. 851 Description: C wants to access a resource R hosted by the resource 852 server S. To achieve this, it has to transmit some information to 853 S such as the resource to be accessed, the action to be performed 854 on the resource and, if a writing access is requested, the value 855 to write. C might send the request directly to S or to an entity 856 which is authorized to speak for S. C assures that the request 857 reaches the proper R. C binds the request to C's verifier to 858 ensure the integrity of the message. C uses means to assure that 859 no unauthorized entity is able to access the information in the 860 request. 861 Requirements: 862 * RqSendReq.1: Is performed by C (derives from problem statement). 863 * RqSendReq.2: Must be performable by a constrained device 864 (derives from the problem statement: C and / or S are 865 constrained). 866 * RqSendReq.3: As the request might contain resource values, the 867 confidentiality and integrity of the request must be ensured 868 during transmission. Only authorized parties must be able to read 869 or modify the request (derives from Rq0.1). 870 Preconditions: 871 * PreSendReq.1: Validate that the receiver is an authorized source 872 for R (see Appendix A.2.2). 873 * PreSendReq.2: To assure that the request reaches the proper S, 874 that no unauthorized party is able to access the request, and that 875 the information in the request is bound to C's verifier it is 876 necessary to negotiate means for secure communication with S (see 877 Appendix A.2.3). 878 Postconditions: 879 * PostSendReq.1: The request was sent securely to S (necessary for 880 Rq0.1) (fulfills PreProcReq.1, see Appendix A.1.1). 882 Note: The preconditions PreSendReq.1 and PreSendReq.2 must be 883 conducted together. C must assure that the request reaches an entity 884 with certain attributes and that the authorization information refers 885 to these attributes. 887 o Task TSendResp: Securely transmit a response to an access request. 888 Description: S sends a response to an access request to inform C 889 about the result of the request. S must assure that response 890 reaches the requesting C. S might send the response to C or to an 891 entity which is authorized to speak for C. The response might 892 contain resource values. S binds the request to S's verifier to 893 ensure the integrity of the message. S uses means to assure that 894 no unauthorized entity is able to access the information in the 895 response. 896 Requirements: 897 * RqSendResp.1: Is performed by S (derives from the problem 898 statement). 899 * RqSendResp.2: Must be performable by a constrained device 900 (derives from the problem statement: C and / or S are 901 constrained). 903 * RqSendResp.3: As the response might contain resource values, the 904 confidentiality and integrity of the response must be ensured 905 during transmission. Only authorized parties must be able to read 906 or modify the response (derives from Rq0.1). 907 Preconditions: 908 * PreSendResp.1: An access request was processed (see 909 Appendix A.1.1). 910 * PreSendResp.2: If information about R is transmitted, validate 911 that the receiver is authorized to access R (see Appendix A.2.2). 912 * PreSendResp.3: S must assure that the response reaches the 913 requesting C, no unauthorized party is able to access the response 914 and the information in the response is bound to S' verifier: Means 915 for secure communication were negotiated (see Appendix A.2.3). 916 Postconditions: 917 * PostSendResp.1: A response to an access request was sent 918 (fulfills PreProcResp.1, see Appendix A.1.1). 920 A.2. Security-Related Tasks 922 A.2.1. Information Authenticity 924 This section addresses information authentication, i.e. using the 925 verifier to validate the source of an information. Information 926 authentication must be conducted before processing received 927 information. C must validate that a response to an access request is 928 fresh, really stems from the queried S (or an entity which is 929 authorized to speak for S) and was not modified during transmission. 930 S must validate that the information in the access request is fresh, 931 really stems from C (or an entity which is authorized to speak for C) 932 and was not modified during transmission. 934 The entity which processes the information must be the entity which 935 is validating the source of the information. 937 C and S must assure that the authenticated source of the information 938 is authorized to provide the information. 940 o Task TAuthnResp: Validate that the response to an access request 941 is authentic. 942 Description: C checks if the response to an access request stems 943 from an entity in possession of the respective verifier and is 944 fresh. Thus, C validates that the response stems from the queried 945 S or an entity which is authorized to speak for S. 946 Requirements: 947 * RqAuthnResp.1: Must be performed by C. 948 * RqAuthnResp.2: Must be performable by a constrained device 949 (derives from the problem statement: C and / or S are 950 constrained). 952 Preconditions: 953 * PreAuthnResp.1: Means for secure communication were negotiated 954 (see Appendix A.2.3). 955 Postconditions: 956 * PostAuthnResp.1: C knows that the response came from S (fulfills 957 PreProcResp.2, see Appendix A.1.1). 959 o Task TAuthnReq: Validate the authenticity of a request. 960 Description: S checks if the request stems from an entity in 961 possession of the respective verifier and is fresh. Thus, S 962 validates that the request stems from C or an entity which is 963 authorized to speak for C. 964 Requirements: 965 * RqAuthnReq.1: Must be performed by S. 966 * RqAuthnReq.2: Must be performable by a constrained device 967 (derives from the problem statement: C and / or S are 968 constrained). 969 Preconditions: 970 * PreAuthnReq.1: Means for secure communication were negotiated 971 (see Appendix A.2.3). 972 Postconditions: 973 * PostAuthnReq.1: S knows that the request is authentic (fulfills 974 PreProcReq.2, see Appendix A.1.1). 976 A.2.2. Authorization Validation 978 This section addresses the validation of the authorization of an 979 entity. The entity which processes the information must validate 980 that the source of the information is authorized to provide it. The 981 processing entity has to verify that the source of the information 982 has certain attributes which authorize it to provide the information: 983 C must validate that S (or the entity which speaks for S) is in 984 possession of attributes which are necessary for being an authorized 985 source for R. S must validate that C (or the entity which speaks for 986 C) has attributes which are necessary for a permission to access R as 987 requested. 989 o Task TValSourceAuthz: Validate that an entity is an authorized 990 source for R. 991 Description: C checks if according to COP's authorization policy 992 and the authentication endorsement provided by the attribute 993 binding authority, S (or an entity which speaks for S) is 994 authorized to be a source for R. S assures that the entity's 995 verifier is bound to certain attributes and the authorization 996 information refers to these attributes. 997 Requirements: 998 * RqValSourceAuthz.1: Is performed by C 999 * RqValSourceAuthz.2: Must be performable by a constrained device 1000 (derives from the problem statement: C and / or S are 1001 constrained). 1002 Preconditions: 1003 * PreValSourceAuthz.1: Authorization information about the entity 1004 is available. Requires obtaining authorization information about 1005 the entity from C's principal (see Appendix A.2.4). 1006 * PreValSourceAuthz.2: Means to validate that the entity has 1007 certain attributes which are relevant for the authorization: 1008 Requires validation of claims about S (see Appendix A.2.5). 1009 Postconditions: 1010 * PostValSourceAuthz.1: The entity which performs the task knows 1011 that an entity is an authorized source for R (fulfills 1012 PreProcResp.3, see Appendix A.1.1 and PreSendReq.1, see 1013 Appendix A.1.2). 1015 o Task TValAccessAuthZ: Validate the authorization of the requester 1016 to access the requested resource as requested. 1017 Description: R's principal configures which clients are authorized 1018 to perform which action on R. S has to check if according to 1019 ROP's authorization policy and the authentication endorsement 1020 provided by the attribute binding authority, C (or an entity which 1021 speaks for C) is authorized to access R as requested. S assures 1022 that requester's verifier is bound to certain attributes and the 1023 authorization information refers to these attributes. 1024 Requirements: 1025 * RqValAccessAuthz.1: Is performed by S 1026 * RqValAccessAuthz.2: Must be performable by a constrained device 1027 (derives from the problem statement: C and / or S are 1028 constrained). 1029 Preconditions: 1030 * PreValAccessAuthz.1: Authorization information about the entity 1031 are available. Requires obtaining authorization information about 1032 the entity from S's principal (see Appendix A.2.4). 1033 * PreValAccessAuthz.2: Means to validate that the entity has 1034 certain attributes which are relevant for the authorization: 1035 Requires validation of claims about C or the entity which speaks 1036 for C (see Appendix A.2.5). 1037 Postconditions: 1038 * PostValAccessAuthz.1: The entity which performs the task knows 1039 that an entity is authorized to access R with the requested action 1040 (fulfills PreProcReq.3, see Appendix A.1.1). 1042 A.2.3. Transmission Security 1044 To ensure the confidentiality and integrity of information during 1045 transmission means for secure communication have to be negotiated 1046 between the communicating parties. 1048 o Task TSecureComm: Negotiate means for secure communication. 1049 Description: To ensure the confidentiality and integrity of 1050 transmitted information, means for secure communication have to be 1051 negotiated. Channel security as well as object security solutions 1052 are possible. Details depend on the used solution and are not in 1053 the scope of this document. 1054 Requirements: 1055 * RqSecureComm.1: Must be performable by a constrained device 1056 (derives from the problem statement: C and / or S are 1057 constrained). 1058 Preconditions: 1059 * PreSecureComm.1: Sender and receiver must be able to validate 1060 that the entity in possession of a certain verifier has the 1061 claimed attributes. (see Appendix A.2.5). 1062 Postconditions: 1063 * PostSecureComm.1: C and S can communicate securely: The 1064 integrity and confidentiality of information is ensured during 1065 transmission. The sending entity can use means to assure that the 1066 information reaches the intended receiver so that no unauthorized 1067 party is able to access the information. The sending entity can 1068 bind the information to the entity's verifier (fulfills 1069 PreSendResp.3 and PreSendReq.2, see Appendix A.1.2 as well as 1070 PreAuthnResp.1 and PreAuthnReq.1, see Appendix A.2.1). 1072 A.2.4. Obtain Authorization information 1074 As described in Section 6.4, the authorization of an entity requires 1075 several steps. The authorization information must be configured by 1076 the principal and provided to the enforcing entity. 1078 o Task TObtainSourceAuthz: Obtain authorization information about an 1079 entity from C's principal. 1080 Description: C's principal defines authorized sources for R. The 1081 authorization information must be made available to C to enable it 1082 to enforce COP's authorization information. To facilitate the 1083 configuration for the principal this device should have a user 1084 interface. The authorization information has to be made available 1085 to C in a secure way. 1086 Requirements: 1087 * RqObtainSourceAuthz.1: Must be performed by an entity which is 1088 authorized by C's principal. 1089 * RqObtainSourceAuthz.2: Must be performed by an entity which is 1090 authorized to speak for C's principal concerning authorized 1091 sources for R. 1092 * RqObtainSourceAuthz.3: Should be performed by a device which can 1093 provide some sort of user interface to facilitate the 1094 configuration of authorization information for C's principal. 1095 Preconditions: 1097 * PreObtainSourceAuthz.1: C's principal configured authorized 1098 sources for R (see Appendix A.2.6). 1099 Postconditions: 1100 * PostObtainSourceAuthz.1: C obtained S' authorization to be a 1101 source for R (fulfills PreValSourceAuthz.1, see Appendix A.2.2). 1103 o Task TObtainAccessAuthz: Obtain authorization information about an 1104 entity from S' principal. 1105 Description: S' principal defines if and how C is authorized to 1106 access R. The authorization information must be made available to 1107 S to enable it to enforce ROP's authorization policies. To 1108 facilitate the configuration for the principal this device should 1109 have a user interface. The authorization information has to be 1110 made available to S in a secure way. 1111 Requirements: 1112 * RqObtainAccessAuthz.1: Must be performed by an entity which is 1113 authorized by R's principal. 1114 * RqObtainAccessAuthz.2: Must be performed by an entity which is 1115 authorized to speak for R's principal concerning authorization of 1116 access to R. 1117 * RqObtainAccessAuthz.3: Should be performed by a device which can 1118 provide some sort of user interface to facilitate the 1119 configuration of authorization information for R's principal. 1120 Preconditions: 1121 * PreObtainAccessAuthz.1: R's principal configured authorization 1122 information for the access to R (see Appendix A.2.6). 1123 Postconditions: 1124 * PostObtainAccessAuthz.1: S obtained C's authorization for 1125 accessing R (fulfills PreValAccessAuthz.1, see Appendix A.2.2). 1127 A.2.5. Attribute Binding 1129 As described in Section 6.3, several steps must be conducted for 1130 authentication. This section addresses the binding of attributes to 1131 a verifier. 1133 For authentication it is necessary to validate if an entity has 1134 certain attributes. An example for such an attribute in the physical 1135 world is the name of a person or her age. In constrained 1136 environments, attributes might be the name of the owner or the type 1137 of device. Authorizations are bound to such attributes. 1139 The possession of attributes must be verifiable. For that purpose, 1140 attributes must be bound to a verifier. An example for a verifier in 1141 the physical world is a passport. In constrained environments, a 1142 verifier will likely be the knowledge of a secret. 1144 At some point, an authority has to check if an entity in possession 1145 of the verifier really possesses the claimed attributes. In the 1146 physical world, government agencies check your name and age before 1147 they give you a passport. 1149 The entity that validates the claims has to provide some kind of seal 1150 to make its endorsement verifiable for other entities and thus bind 1151 the attributes to the verifier. In the physical world passports are 1152 stamped by the issuing government agencies (and must only be provided 1153 by government agencies anyway). 1155 o Task TValSourceAttr: Validate on the client side that an entity 1156 has certain attributes. 1157 Description: The claim that an entity has certain attributes has 1158 to be checked and made available for C in a secure way. The 1159 validating party states that an entity in possession of a certain 1160 key has certain attributes and provides C with means to validate 1161 this endorsement. 1162 Requirements: 1163 * RqValSourceAttr.1: Must be performed by an entity which is 1164 authorized by C's principal to validate claims about S. 1165 * RqValSourceAttr.3: The executing entity must have the means to 1166 fulfill the task (e.g. enough storage space, computational power, 1167 a user interface to facilitate the configuration of authentication 1168 policies). 1169 Postconditions: 1170 * PostValSourceAttr.1: Means for authenticating (validating the 1171 attribute-verifier-binding of) other entities were given to C in 1172 form of a verifiable endorsement (fulfills PreValSourceAuthz.2, 1173 see Appendix A.2.2 and PreSecureComm.1, see Appendix A.2.3). 1175 o Task TValReqAttr: Validate on the server side that an entity has 1176 certain attributes. 1177 Description: The claim that an entity has certain attributes has 1178 to be checked and made available for S in a secure way. The 1179 validating party states that an entity in possession of a certain 1180 key has certain attributes and provides S with means to validate 1181 this endorsement. 1182 Requirements: 1183 * RqValReqAttr.1: Must be performed by an entity which is 1184 authorized by S' principal to validate claims about C. 1185 * RqValReqAttr.2: The executing entity must have the means to 1186 fulfill the task (e.g. enough storage space, computational power, 1187 a user interface to facilitate the configuration of authentication 1188 policies). 1189 Postconditions: 1190 * PostValReqAttr.1: Means for authenticating (validating the 1191 attribute-verifier-binding of) other entities were given to S in 1192 form of a verifiable endorsement (fulfills PreValSourceAuthz.2, 1193 see Appendix A.2.2 and PreSecureComm.1, see Appendix A.2.3). 1195 A.2.6. Configuration of Authorization Information 1197 As stated in Section 6.4, several steps have to be conducted for 1198 authorization. This section is about the configuration of 1199 authorization information. 1201 The principal of a device or resource wants to be in control of her 1202 device and her data. For that purpose, she has to configure 1203 authorization information. C's principal might want to configure 1204 which attributes an entity must have to be allowed to represent R. 1205 R's principal might want to configure which attributes are required 1206 for accessing R with a certain action. 1208 o Task TConfigSourceAuthz: Configure for C authorization information 1209 for sources for R. 1210 Description: C's principal has to define authorized sources for R. 1211 Requirements: 1212 * RqConfigSourceAuthz.1: Must be provided by C's principal. 1213 Postconditions: 1214 * PostConfigSourceAuthz.1: The authorization information are 1215 available to a device which performs TObtainSourceAuthz (fulfills 1216 PreObtainSourceAuthz.1 see Appendix A.2.4). 1218 o Task TConfigAccessAuthz: Configure for S authorization information 1219 for accessing R. 1220 Description: R's principal has to configure if and how an entity 1221 with certain attributes is allowed to access R. 1222 Requirements: 1223 * RqConfigAccessAuthz.1: Must be provided by R's principal. 1224 Postconditions: 1225 * PostConfigAccessAuthz.1: The authorization information are 1226 available to the device which performs TObtainAccessAuthz 1227 (fulfills PreObtainAccessAuthz.1, see Appendix A.2.4). 1229 Author's Address 1231 Stefanie Gerdes 1232 Universitaet Bremen TZI 1233 Postfach 330440 1234 Bremen D-28359 1235 Germany 1237 Phone: +49-421-218-63906 1238 Email: gerdes@tzi.org