idnits 2.17.1 draft-ietf-ace-oauth-authz-00.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 (December 21, 2015) is 3048 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) == Unused Reference: 'I-D.ietf-oauth-pop-key-distribution' is defined on line 1366, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-bormann-core-ace-aif-03 ** Downref: Normative reference to an Informational draft: draft-bormann-core-ace-aif (ref. 'I-D.bormann-core-ace-aif') == Outdated reference: A later version (-24) exists of draft-ietf-cose-msg-09 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-pop-architecture-07 ** Downref: Normative reference to an Informational draft: draft-ietf-oauth-pop-architecture (ref. 'I-D.ietf-oauth-pop-architecture') == Outdated reference: A later version (-07) exists of draft-ietf-oauth-pop-key-distribution-02 == Outdated reference: A later version (-06) exists of draft-selander-ace-object-security-03 ** Downref: Normative reference to an Informational draft: draft-wahlstroem-ace-cbor-web-token (ref. 'I-D.wahlstroem-ace-cbor-web-token') ** Downref: Normative reference to an Informational draft: draft-wahlstroem-ace-oauth-introspection (ref. 'I-D.wahlstroem-ace-oauth-introspection') ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-02 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-18 == Outdated reference: A later version (-02) exists of draft-somaraju-ace-multicast-00 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft SICS 4 Intended status: Standards Track G. Selander 5 Expires: June 23, 2016 Ericsson 6 E. Wahlstroem 7 S. Erdtman 8 Nexus Technology 9 H. Tschofenig 10 ARM Ltd. 11 December 21, 2015 13 Authorization for the Internet of Things using OAuth 2.0 14 draft-ietf-ace-oauth-authz-00 16 Abstract 18 This memo defines how to use OAuth 2.0 as an authorization framework 19 with Internet of Things (IoT) deployments, thus bringing a well-known 20 and widely used security solution to IoT devices. Where possible 21 vanilla OAuth 2.0 is used, but where the limitations of IoT devices 22 require it, profiles and extensions are provided. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 23, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. OAuth 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. CoAP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.3. Object Security . . . . . . . . . . . . . . . . . . . . . 8 64 4. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 8 65 5. OAuth 2.0 Profiling . . . . . . . . . . . . . . . . . . . . . 12 66 5.1. Communication Security Protocol . . . . . . . . . . . . . 12 67 5.2. Authorization Information Resource at the Resource Server 13 68 5.3. Authorization Information Format . . . . . . . . . . . . 13 69 5.4. CBOR Data Formats . . . . . . . . . . . . . . . . . . . . 13 70 6. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . 13 71 6.1. Client and Resource Server are Offline . . . . . . . . . 14 72 6.2. Resource Server Offline . . . . . . . . . . . . . . . . . 17 73 6.3. Token Introspection with an Offline Client . . . . . . . 21 74 6.4. Always-On Connectivity . . . . . . . . . . . . . . . . . 25 75 6.5. Token-less Authorization . . . . . . . . . . . . . . . . 26 76 6.6. Securing Group Communication . . . . . . . . . . . . . . 29 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 30 82 10.2. Informative References . . . . . . . . . . . . . . . . . 32 83 Appendix A. Design Justification . . . . . . . . . . . . . . . . 33 84 Appendix B. Optimizations . . . . . . . . . . . . . . . . . . . 35 85 Appendix C. CoAP and CBOR profiles for OAuth 2.0 . . . . . . . . 36 86 C.1. Profile for Token resource . . . . . . . . . . . . . . . 36 87 C.1.1. Token Request . . . . . . . . . . . . . . . . . . . . 36 88 C.1.2. Token Response . . . . . . . . . . . . . . . . . . . 38 89 C.2. CoAP Profile for OAuth Introspection . . . . . . . . . . 39 90 C.2.1. Introspection Request . . . . . . . . . . . . . . . . 39 91 C.2.2. Introspection Response . . . . . . . . . . . . . . . 40 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 94 1. Introduction 96 Authorization is the process for granting approval to an entity to 97 access a resource [RFC4949]. Managing authorization information for 98 a large number of devices and users is often a complex task where 99 dedicated servers are used. 101 Managing authorization of users, services and their devices with the 102 help of dedicated authorization servers (AS) is a common task, found 103 in enterprise networks as well as on the Web. In its simplest form 104 the authorization task can be described as granting access to a 105 resource hosted on a device, the resource server (RS). This exchange 106 is mediated by one or multiple authorization servers. 108 We envision that end consumers and enterprises will want to manage 109 their Internet of Things (IoT) devices in the same style and this 110 desire will increase with the number of exposed services and 111 capabilities provided by applications hosted on the IoT devices. The 112 IoT devices may be constrained in various ways including processing, 113 memory, code, energy, etc., as defined in [RFC7228], and the 114 different IoT deployments present a continuous range of device and 115 network capabilities. Taking energy consumption as an example: At 116 one end there are energy-harvesting or battery powered devices which 117 have a tight power budget, on the other end there are devices 118 connected to a continuous power supply which are not constrained in 119 terms of power, and all levels in between. Thus IoT devices are very 120 different in terms of available processing and message exchange 121 capabilities. 123 This memo describes how to re-use OAuth 2.0 [RFC6749] to extend 124 authorization to Internet of Things devices with different kinds of 125 constrainedness. At the time of writing, OAuth 2.0 is already used 126 with certain types of IoT devices and this document will provide 127 implementers additional guidance for using it in a secure and 128 privacy-friendly way. Where possible the basic OAuth 2.0 mechanisms 129 are used; in some circumstances profiles are defined, for example to 130 support lower the over-the-wire message size and smaller code size. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 Certain security-related terms such as "authentication", 139 "authorization", "confidentiality", "(data) integrity", "message 140 authentication code", and "verify" are taken from [RFC4949]. 142 Since we describe exchanges as RESTful protocol interactions HTTP 143 [RFC7231] offers useful terminology. 145 Terminology for entities in the architecture is defined in OAuth 2.0 146 [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource 147 server (RS), and authorization server (AS). OAuth 2.0 uses the term 148 "endpoint" to denote HTTP resources such as /token and /authorize at 149 the AS, but we will use the term "resource" in this memo to avoid 150 confusion with the CoAP [RFC7252] term "endpoint". 152 Since this draft focuses on the problem of access control to 153 resources, we simplify the actors by assuming that the client 154 authorization server (CAS) functionality is not stand-alone but 155 subsumed by either the authorization server or the client (see 156 section 2.2 in [I-D.ietf-ace-actors]). 158 3. Overview 160 This specification describes a framework for authorization in the 161 Internet of Things consisting of a set of building blocks. 163 The basic block is the OAuth 2.0 [RFC6749] framework, which enjoys 164 widespread deployment. Many IoT devices can support OAuth 2.0 165 without any additional extensions, but for certain constrained 166 settings additional profiling is needed. 168 Another building block is the lightweight web transfer protocol CoAP 169 [RFC7252] for those communication environments where HTTP is not 170 appropriate. CoAP typically runs on top of UDP which further reduces 171 overhead and message exchanges. Transport layer security can be 172 provided either by DTLS 1.2 [RFC6347] or TLS 1.2 [RFC5246]. 174 A third building block is CBOR [RFC7049] for encodings where JSON 175 [RFC7159] is not sufficiently compact. CBOR is a binary encoding 176 designed for extremely small code size and fairly small message size. 177 OAuth 2.0 allows access tokens to use different encodings and this 178 document defines such an alternative encoding. The COSE message 179 format [I-D.ietf-cose-msg] is also based on CBOR. 181 A fourth building block is application layer security, which is used 182 where transport layer security is insufficient. At the time of 183 writing the preferred approach for securing CoAP at the application 184 layer is via the use of COSE [I-D.ietf-cose-msg], which adds object 185 security to CBOR-encoded data. More details about applying COSE to 186 CoAP can be found in OSCOAP [I-D.selander-ace-object-security]. 188 With the building blocks listed above, solutions satisfying various 189 IoT device and network constraints are possible. A list of 190 constraints is described in detail in RFC 7228 [RFC7228] and a 191 description of how the building blocks mentioned above relate to the 192 various constraints can be found in Appendix A. 194 Luckily, not every IoT device suffers from all constraints. The 195 described framework nevertheless takes all these aspects into account 196 and allows several different deployment variants to co-exist rather 197 than mandating a one-size-fits-all solution. We believe this is 198 important to cover the wide range of possible interworking use cases 199 and the different requirements from a security point of view. Once 200 IoT deployments mature, popular deployment variants will be 201 documented in form of profiles. 203 In the subsections below we provide further details about the 204 different building blocks. 206 3.1. OAuth 2.0 208 The OAuth 2.0 authorization framework enables a client to obtain 209 limited access to a resource with the permission of a resource owner. 210 Authorization related information is passed between the nodes using 211 access tokens. These access tokens are issued to clients by an 212 authorization server with the approval of the resource owner. The 213 client uses the access token to access the protected resources hosted 214 by the resource server. 216 A number of OAuth 2.0 terms are used within this memo: 218 Access Tokens: 220 Access tokens are credentials used to access protected resources. 221 An access token is a data structure representing authorization 222 permissions issued to the client. Access tokens are generated by 223 the authorization server and consumed by the resource server. The 224 access token is opaque to the client. 226 Access tokens can have different formats, and various methods of 227 utilization (e.g., cryptographic properties) based on the security 228 requirements of the given deployment. 230 Proof of Possession Tokens: 232 An access token may be bound to a cryptographic key, which is then 233 used by an RS to authenticate requests from a client. Such tokens 234 are called proof-of-possession tokens (or PoP tokens) 235 [I-D.ietf-oauth-pop-architecture]. 237 The proof-of-possession (PoP) security concept assumes that the AS 238 acts as a trusted third party that binds keys to access tokens. 239 These so called PoP keys are then used by the client to 240 demonstrate the possession of the secret to the RS when accessing 241 the resource. The RS, when receiving an access token, needs to 242 verify that the key used by the client matches the one included in 243 the access token. When this memo uses the term "access token" it 244 is assumed to be a PoP token unless specifically stated otherwise. 246 The key bound to the access token (aka PoP key) may be based on 247 symmetric as well as on asymmetric cryptography. The appropriate 248 choice of security depends on the constraints of the IoT devices 249 as well as on the security requirements of the use case. 251 Symmetric PoP key: 253 The AS generates a random symmetric PoP key, encrypts it for 254 the RS and includes it inside an access token. The PoP key is 255 also encrypted for the client and sent together with the access 256 token to the client. 258 Asymmetric PoP key: 260 An asymmetric key pair is generated on the client and the 261 public key is sent to the AS (if it does not already have 262 knowledge of the client's public key). Information about the 263 public key, which is the PoP key in this case, is then included 264 inside the access token and sent back to the requesting client. 265 The RS can identify the client's public key from the 266 information in the token, which allows the client to use the 267 corresponding private key for the proof of possession. 269 The access token is protected against modifications using a MAC or 270 a digital signature of the AS. The choice of PoP key does not 271 necessarily imply a specific credential type for the integrity 272 protection of the token. More information about PoP tokens can be 273 found in [I-D.ietf-oauth-pop-architecture]. 275 Scopes and Permissions: 277 In OAuth 2.0, the client specifies the type of permissions it is 278 seeking to obtain (via the scope parameter) in the access request. 279 In turn, the AS may use the "scope" response parameter to inform 280 the client of the scope of the access token issued. As the client 281 could be a constrained device as well, this memo uses CBOR encoded 282 messages defined in Appendix C to request scopes and to be 283 informed what scopes the access token was actually authorized for 284 by the AS. 286 The values of the scope parameter are expressed as a list of 287 space- delimited, case-sensitive strings, with a semantic that is 288 well-known to the AS and the RS. More details about the concept 289 of scopes is found under Section 3.3 in [RFC6749]. 291 Claims: 293 The information carried in the access token in the form of type- 294 value pairs is called claims. An access token may for example 295 include a claim about the AS that issued the token (the "iss" 296 claim) and what audience the access token is intended for (the 297 "aud" claim). The audience of an access token can be a specific 298 resource or one or many resource servers. The resource owner 299 policies influence the what claims are put into the access token 300 by the authorization server. 302 While the structure and encoding of the access token varies 303 throughout deployments, a standardized format has been defined 304 with the JSON Web Token (JWT) [RFC7519] where claims are encoded 305 as a JSON object. In [I-D.wahlstroem-ace-cbor-web-token] an 306 equivalent format using CBOR encoding (CWT) has been defined. 308 Introspection: 310 Introspection is a method for a resource server to query the 311 authorization server for the active state and content of a 312 received access token. This is particularly useful in those cases 313 where the authorization decisions are very dynamic and/or where 314 the received access token itself is a reference rather than a 315 self-contained token. More information about introspection in 316 OAuth 2.0 can be found in [I-D.ietf-oauth-introspection]. 318 3.2. CoAP 320 CoAP is an application layer protocol similar to HTTP, but 321 specifically designed for constrained environments. CoAP typically 322 uses datagram-oriented transport, such as UDP, where reordering and 323 loss of packets can occur. A security solution need to take the 324 latter aspects into account. 326 Where HTTP uses headers and query-strings to convey additional 327 information about a request, CoAP encodes such information in so- 328 called 'options'. 330 CoAP supports application-layer fragmentation of the CoAP payloads 331 through blockwise transfers [I-D.ietf-core-block]. However, this 332 method does not allow the fragmentation of large CoAP options, 333 therefore data encoded in options has to be kept small. 335 3.3. Object Security 337 Transport layer security is not always sufficient and application 338 layer security has to be provided. COSE [I-D.ietf-cose-msg] defines 339 a message format for cryptographic protection of data using CBOR 340 encoding. There are two main approaches for application layer 341 security: 343 Object Security of CoAP (OSCOAP) 345 OSCOAP [I-D.selander-ace-object-security] is a method for 346 protecting CoAP request/response message exchanges, including CoAP 347 payloads, CoAP header fields as well as CoAP options. OSCOAP 348 provides end-to-end confidentiality, integrity and replay 349 protection, and a secure binding between CoAP request and response 350 messages. 352 A CoAP message protected with OSCOAP contains the CoAP option 353 "Object-Security" which signals that the CoAP message carries a 354 COSE message ([I-D.ietf-cose-msg]). OSCOAP defines a profile of 355 COSE which includes replay protection. 357 Object Security of Content (OSCON) 359 For the case of wrapping of application layer payload data 360 ("content") only, such as resource representations or claims of 361 access tokens, the same COSE profile can be applied to obtain end- 362 to-end confidentiality, integrity and replay protection. 363 [I-D.selander-ace-object-security] defines this functionality as 364 Object Security of Content (OSCON). 366 In this case, the message is not bound to the underlying 367 application layer protocol and can therefore be used with HTTP, 368 CoAP, Bluetooth Smart, etc. Whereas OSCOAP integrity protects 369 specific CoAP message meta-data like request/response code, and 370 binds a response to a specific request, OSCON protects only 371 payload/content, therefore those security features are lost. The 372 advantages are that an OSCON message can be passed across 373 different protocols, from request to response, and used to secure 374 group communications. 376 4. Protocol Interactions 378 This framework is based on the same protocol interactions as OAuth 379 2.0: A client obtains an access token from an AS and presents the 380 token to an RS to gain access to a protected resource. These 381 interactions are shown in Figure 1. An overview of various OAuth 382 concepts is provided in Section 3.1. 384 The consent of the resource owner, for giving a client access to a 385 protected resource, can be pre-configured authorization policies or 386 dynamically at the time when the request is sent. The resource owner 387 and the requesting party (= client owner) are not shown in Figure 1. 389 For the description in this document we assume that the client has 390 been registered to an AS. Registration means that the two share 391 credentials, configuration parameters and that some form of 392 authorization has taken place. These credentials are used to protect 393 the token request by the client and the transport of access tokens 394 and client information from AS to the client. 396 It is also assumed that the RS has been registered with the AS. 397 Established keying material between the AS and the RS allows the AS 398 to apply cryptographic protection to the access token to ensure that 399 the content cannot be modified, and if needed, that the content is 400 confidentiality protected. 402 The keying material necessary for establishing communication security 403 between C and RS is dynamically established as part of the protocol 404 described in this document. 406 At the start of the protocol there is an optional discovery step 407 where the client discovers the resource server and the resources this 408 server hosts. In this step the client might also determine what 409 permissions are needed to access the protected resource. The exact 410 procedure depends on the protocols being used and the specific 411 deployment environment. In Bluetooth Smart, for example, 412 advertisements are broadcasted by a peripheral, including information 413 about the supported services. In CoAP, as a second example, a client 414 can makes a request to "/.well-known/core" to obtain information 415 about available resources, which are returned in a standardized 416 format as described in [RFC6690]. 418 +--------+ +---------------+ 419 | |---(A)-- Token Request ------------->| | 420 | | | Authorization | 421 | |<--(B)-- Access Token ---------------| Server | 422 | | + Client Information | | 423 | | +---------------+ 424 | | ^ | 425 | | Introspection Request & Response (D)| |(E) 426 | Client | | v 427 | | +--------------+ 428 | |---(C)-- Token + Request ----------->| | 429 | | | Resource | 430 | |<--(F)-- Protected Resource ---------| Server | 431 | | | | 432 +--------+ +--------------+ 434 Figure 1: Overview of the basic protocol flow 436 Requesting an Access Token (A): 438 The client makes an access token request to the AS. This memo 439 assumes the use of PoP tokens (see Section 3.1 for a short 440 description) wherein the AS binds a key to an access token. The 441 client may include permissions it seeks to obtain, and information 442 about the type of credentials it wants to use (i.e., symmetric or 443 asymmetric cryptography). 445 Access Token Response (B): 447 If the AS successfully processes the request from the client, it 448 returns an access token. It also includes various parameters, 449 which we call "Client Information". In addition to the response 450 parameters defined by OAuth 2.0 and the PoP token extension, we 451 consider new kinds of response parameters in Section 5, including 452 information on which security protocol the client should use with 453 the resource server(s) that it has just been authorized to access. 454 Communication security between client and RS may be based on pre- 455 provisioned keys/security contexts or dynamically established to 456 the RS via the PoP token; and to the client via the client 457 information as described in Section 5.1. 459 Resource Request (C): 461 The client interacts with the RS to request access to the 462 protected resource and provides the access token. The protocol to 463 use between the client and the RS is not restricted to CoAP; HTTP, 464 HTTP/2, Bluetooth Smart etc., are also possible candidates. 466 Depending on the device limitations and the selected protocol this 467 exchange may be split up into two phases: 469 (1) the client sends the access token to a newly defined 470 authorization endpoint at the RS (see Section 5.2) , which 471 conveys authorization information to the RS that may be used 472 for subsequent resource requests, and 474 (2) the client makes the resource access request, using the 475 communication security protocol and other client information 476 obtained from the AS. 478 The RS verifies that the token is integrity protected by the AS 479 and compares the claims contained in the access token with the 480 resource request. If the RS is online, validation can be handed 481 over to the AS using token introspection (see messages D and E) 482 over HTTP or CoAP, in which case the different parts of step C may 483 be interleaved with introspection. 485 Token Introspection Request (D): 487 A resource server may be configured to use token introspection to 488 interact with the AS to obtain the most recent claims, such as 489 scope, audience, validity etc. associated with a specific access 490 token. Token introspection over CoAP is defined in 491 [I-D.wahlstroem-ace-oauth-introspection] and for HTTP in 492 [I-D.ietf-oauth-introspection]. 494 Note that token introspection is an optional step and can be 495 omitted if the token is self-contained and the resource server is 496 prepared to perform the token validation on its own. 498 Token Introspection Response (E): 500 The AS validates the token and returns the claims associated with 501 it back to the RS. The RS then uses the received claims to 502 process the request to either accept or to deny it. 504 Protected Resource (F): 506 If the request from the client is authorized, the RS fulfills the 507 request and returns a response with the appropriate response code. 508 The RS uses the dynamically established keys to protect the 509 response, according to used communication security protocol. 511 5. OAuth 2.0 Profiling 513 This section describes profiles of OAuth 2.0 adjusting it to 514 constrained environments for use cases where this is necessary. 515 Profiling for JSON Web Tokens (JWT) is provided in 516 [I-D.wahlstroem-ace-cbor-web-token]. 518 5.1. Communication Security Protocol 520 OAuth 2.0 using bearer tokens, as described in RFC 6749 and in RFC 521 6750, requires TLS for all communication interactions between client, 522 authorization server, and resource server. This is possible in the 523 scope where OAuth 2.0 was originally developed, web and mobile 524 applications. In these environments resources like computational 525 power and bandwidth are not scarce and operating systems as well as 526 browser platforms are pre-provisioned with trust anchors that enable 527 clients to authenticate servers based on the Web PKI. In a more 528 heterogeneous IoT environment a wider range of use cases needs to be 529 supported. Therefore, this document suggests extensions to OAuth 2.0 530 that enable the AS to inform the client on how to communicate 531 securely with a RS. 533 The client and the RS might not have any prior knowledge about each 534 other, therefore the AS needs to help them to establish a security 535 context or at least a key. The AS does this by indicating 536 communication security protocol ("csp") and additional key parameters 537 in the client information. 539 The "csp" parameter specifies how client and RS communication is 540 going to be secured based on returned keys. Currently defined values 541 are "TLS", "DTLS", "OSCOAP" and "OSCON". Depending on the value 542 different additional parameters become mandatory. 544 TLS with certificates may make use of pre-established trust anchors 545 or configured more tightly with additional client information 546 parameters, like x5c, x5t or x5t#S256. 548 CoAP specifies three security "modes" of DTLS: PreSharedKey, 549 RawPublicKey and Certificate. In case of PreSharedKey and 550 RawPublicKey DTLS is based on the use keys distributed in the PoP 551 token and via the client information. Additional certificate 552 information may also be added, for example using the parameter x5c, 553 x5t or x5t#S256. 555 To use OSCOAP and OSCON requires security context to be established, 556 which can be provisioned with PoP token and client information, or 557 derived from that information. 559 5.2. Authorization Information Resource at the Resource Server 561 A consequence of allowing the use of CoAP as web transfer protocol is 562 that we cannot rely on HTTP specific mechanisms, such as transferring 563 information elements in HTTP headers since those are not necessarily 564 gracefully mapped to CoAP. In case the access token is larger than 565 255 bytes it should not be sent as a CoAP option. 567 For conveying authorization information to the RS we therefore 568 introduce a new resource to which the PoP tokens can be sent to 569 convey authorization information before the first resource request is 570 made by the client. This specification calls this resource "/authz- 571 info"; the URI may, however, vary in deployments. 573 5.3. Authorization Information Format 575 We introduce a new claim for describing access rights with a specific 576 format, the "aif" claim. In this memo we propose to use the compact 577 format provided by AIF [I-D.bormann-core-ace-aif]. Access rights may 578 be specified as a list of URIs of resources together with allowed 579 actions (GET, POST, PUT, PATCH, or DELETE). Other formats may be 580 mandated by specific applications or requirements (e.g. specifying 581 local conditions on access). 583 5.4. CBOR Data Formats 585 The /token resource (called "endpoint" in OAuth 2.0), defined in 586 Section 3.2 of [RFC6749], is used by the client to obtain an access 587 token. Requests sent to the /token resource use the HTTP POST method 588 and the payload includes a query component, which is formatted as 589 application/x-www-form-urlencoded. CoAP payloads cannot be formatted 590 in the same way which requires the /token resource on the AS to be 591 profiled. Appendix C defines a CBOR-based format for sending 592 parameters to the /token resource. 594 6. Deployment Scenarios 596 There is a large variety of IoT deployments, as is indicated in 597 Appendix A, and this section highlights common variants. This 598 section is not normative but illustrates how the framework can be 599 applied. 601 For each of the deployment variants there are a number of possible 602 security setups between clients, resource servers and authorization 603 servers. The main focus in the following subsections is on how 604 authorization of a client request for a resource hosted by a RS is 605 performed. This requires us to also consider how these requests and 606 responses between the clients and the resource servers are secured. 608 The security protocols between other pairs of nodes in the 609 architecture, namely client-to-AS and RS-to-AS, are not detailed in 610 these examples. Different security protocols may be used on 611 transport or application layer. 613 Note: We use the CBOR diagnostic notation for examples of requests 614 and responses. 616 6.1. Client and Resource Server are Offline 618 In this scenario we consider the case where both the resource server 619 and the client are offline, i.e., they are not connected to the AS at 620 the time of the resource request. This access procedure involves 621 steps A, B, C, and F of Figure 1, but assumes that step A and B have 622 been carried out during a phase when the client had connectivity to 623 AS. 625 Since the resource server must be able to verify the access token 626 locally, self-contained access tokens must be used. 628 This example shows the interactions between a client, the 629 authorization server and a temperature sensor acting as a resource 630 server. Message exchanges A and B are shown in Figure 2. 632 A: The client first generates a public-private key pair used for 633 communication security with the RS. 635 The client sends the POST request to /token at AS. The request 636 contains the public key of the client and the Audience parameter 637 set to "tempSensorInLivingRoom", a value the that the temperature 638 sensor identifies itself with. The AS evaluates the request and 639 authorizes the client to access the resource. 641 B: The AS responds with a PoP token and client information. The 642 PoP token contains the public key of the client, while the client 643 information contains the public key of the RS. For communication 644 security this example uses DTLS with raw public keys between the 645 client and the RS. 647 Note: In this example we assume that the client knows what 648 resource it wants to access, and is therefore able to request 649 specific audience and scope claims for the access token. 651 Authorization 652 Client Server 653 | | 654 | | 655 A: +-------->| Header: POST (Code=0.02) 656 | POST | Uri-Path:"token" 657 | | Payload: 658 | | 659 B: |<--------+ Header: 2.05 Content 660 | | Content-Type: application/cbor 661 | 2.05 | Payload: 662 | | 664 Figure 2: Token Request and Response Using Client Credentials. 666 The information contained in the Request-Payload and the Response- 667 Payload is shown in Figure 3. 669 Request-Payload : 670 { 671 "grant_type" : "client_credentials", 672 "aud" : "tempSensorInLivingRoom", 673 "client_id" : "myclient", 674 "client_secret" : "qwerty" 675 } 677 Response-Payload : 678 { 679 "access_token" : b64'SlAV32hkKG ...', 680 "token_type" : "pop", 681 "csp" : "DTLS", 682 "key" : b64'eyJhbGciOiJSU0ExXzUi ...' 683 } 685 Figure 3: Request and Response Payload Details. 687 The content of the "key" parameter and the access token are shown in 688 Figure 4 and Figure 5. 690 { 691 "kid" : b64'c29tZSBwdWJsaWMga2V5IGlk', 692 "kty" : "EC", 693 "crv" : "P-256", 694 "x" : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4', 695 "y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM' 696 } 698 Figure 4: Public Key of the RS. 700 { 701 "aud" : "tempSensorInLivingRoom", 702 "iat" : "1360189224", 703 "cnf" : { 704 "jwk" : { 705 "kid" : b64'1Bg8vub9tLe1gHMzV76e8', 706 "kty" : "EC", 707 "crv" : "P-256", 708 "x" : b64'f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU', 709 "y" : b64'x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0' 710 } 711 } 712 } 714 Figure 5: Access Token including Public Key of the Client. 716 Messages C and F are shown in Figure 6 - Figure 7. 718 C: The client then sends the PoP token to the /authz-info resource 719 at the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP 720 between client and RS, since the token is integrity protected 721 between AS and RS. The RS verifies that the PoP token was created 722 by a known and trusted AS, is valid, and responds to the client. 723 The RS caches the security context together with authorization 724 information about this client contained in the PoP token. 726 The client and resource server run the DTLS handshake using the 727 raw public keys established in step B and C. 729 The client sends the CoAP request GET to /temperature on RS over 730 DTLS. The RS verifies that the request is authorized. 732 F: The RS responds with a resource representation over DTLS. 734 Resource 735 Client Server 736 | | 737 C: +-------->| Header: POST (Code=0.02) 738 | POST | Uri-Path:"authz-info" 739 | | Payload: SlAV32hkKG ... 740 | | (access token) 741 | | 742 |<--------+ Header: 2.04 Changed 743 | 2.04 | 744 | | 746 Figure 6: Access Token provisioning to RS 748 Resource 749 Client Server 750 | | 751 |<=======>| DTLS Connection Establishment 752 | | using Raw Public Keys 753 | | 754 | | 755 +-------->| Header: GET (Code=0.01) 756 | GET | Uri-Path: "temperature" 757 | | 758 | | 759 | | 760 F: |<--------+ Header: 2.05 Content 761 | 2.05 | Payload: {"t":"22.7"} 762 | | 764 Figure 7: Resource Request and Response protected by DTLS. 766 6.2. Resource Server Offline 768 In this deployment scenario we consider the case of an RS that may 769 not be able to access the AS at the time it receives an access 770 request from a client. We denote this case "RS offline", it involves 771 steps A, B, C and F of Figure 1. 773 If the RS is offline, then it must be possible for the RS to locally 774 validate the access token. This requires self-contained tokens to be 775 used. 777 The validity time for the token should always be chosen as short as 778 possible to reduce the possibility that a token contains out-of-date 779 authorization information. Therefore the value for the Expiration 780 Time claim ("exp") should be set only slightly larger than the value 781 for the Issuing Time claim ("iss"). A constrained RS with means to 782 reliably measure time must validate the expiration time of the access 783 token. 785 The following example shows interactions between a client (AC control 786 unit), an offline resource server (temperature sensor) and an 787 authorization server. The message exchanges A and B are shown in 788 Figure 8. 790 A: The client sends the request POST to /token at AS. The request 791 contains the Audience parameter set to "tempSensor109797", a value 792 that the temperature sensor identifies itself with. The scope the 793 client want's the AS to authorize the access token for is "owner", 794 which means that the token can be used to both read temperature 795 data and upgrade the firmware on the RS. The AS evaluates the 796 request and authorizes the client to access the resource. 798 B: The AS responds with a PoP token and client information. The 799 PoP token is wrapped in a COSE message, object secured content 800 from AS to RS. The client information contains a symmetric key. 801 In this case communication security between C and RS is OSCOAP 802 with an authenticated encryption algorithm. The client derives 803 two unidirectional security contexts to use with the resource 804 request and response messages. The access token includes the 805 claim "aif" with the authorized access that an owner of the 806 temperature device can enjoy. The "aif" claim, issued by the AS, 807 informs the RS that the owner of the access token, that can prove 808 the possession of a key is authorized to make a GET request 809 against the /tempC resource and a POST request on the /firmware 810 resource. 812 Authorization 813 Client Server 814 | | 815 | | 816 A: +-------->| Header: POST (Code=0.02) 817 | POST | Uri-Path: "token" 818 | | Payload: 819 | | 820 B: |<--------+ Header: 2.05 Content 821 | | Content-Type: application/cbor 822 | 2.05 | Payload: 823 | | 824 | | 826 Figure 8: Token Request and Response 828 The information contained in the Request-Payload and the Response- 829 Payload is shown in Figure 9. 831 Request-Payload: 832 { 833 "grant_type" : "client_credentials", 834 "client_id" : "myclient", 835 "client_secret" : "qwerty", 836 "aud" : "tempSensor109797", 837 "scope" : "owner" 838 } 840 Response-Payload: 841 { 842 "access_token": b64'SlAV32hkKG ...', 843 "token_type" : "pop", 844 "csp" : "OSCOAP", 845 "key" : b64'eyJhbGciOiJSU0ExXzUi ...' 846 } 848 Figure 9: Request and Response Payload for RS offline 850 Figure 10 shows examples of the key and the access_token parameters 851 of the Response-Payload, decoded to CBOR. 853 access_token: 854 { 855 "aud" : "tempSensor109797", 856 "exp" : 1311281970, 857 "iat" : 1311280970, 858 "aif" : [["/tempC", 0], ["/firmware", 2]], 859 "cnf" : { 860 "ck":b64'JDLUhTMjU2IiwiY3R5Ijoi ...' 861 } 862 } 864 key: 865 { 866 "alg" : "AES_128_CCM_8", 867 "kid" : b64'U29tZSBLZXkgSWQ', 868 "k" : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE' 869 } 871 Figure 10: Access Token and symmetric key from the Response-Payload 873 Message exchanges C and F are shown in Figure 11 and Figure 12. 875 C: The client then sends the PoP token to the /authz-info resource 876 in the RS. This is a plain CoAP request, i.e. no DTLS/OSCOAP 877 between client and RS, since the token is integrity protected 878 between AS and RS. The RS verifies that the PoP token was created 879 by a known and trusted AS, is valid, and responds to the client. 880 The RS derives and caches the security contexts together with 881 authorization information about this client contained in the PoP 882 token. 884 The client sends the CoAP requests GET to /tempC on the RS using 885 OSCOAP. The RS verifies the request and that it is authorized. 887 F: The RS responds with a protected status code using OSCOAP. The 888 client verifies the response. 890 Resource 891 Client Server 892 | | 893 C: +-------->| Header: POST (Code=0.02) 894 | POST | Uri-Path:"authz-info" 895 | | Payload: 896 | | 897 | | 898 |<--------+ Header: 2.04 Changed 899 | 2.04 | 900 | | 901 | | 903 Figure 11: Access Token provisioning to RS 905 Resource 906 Client Server 907 | | 908 +-------->| Header: GET (Code=0.01) 909 | GET | Object-Security: 910 | | (,,[Uri-Path:"tempC"],) 911 | | 912 F: |<--------+ Header: 2.05 Content 913 | 2.05 | Object-Security: 914 | | (,,[22.7 C],) 915 | | 917 Figure 12: Resource request and response protected by OSCOAP 919 In Figure 12 the GET request contains an Object-Security option and 920 an indication of the content of the COSE object: a sequence number 921 ("seq", starting from 0), a context identifier ("cid") indicating the 922 security context, the ciphertext containing the encrypted CoAP option 923 identifying the resource, and the Message Authentication Code ("tag") 924 which also covers the Code in the CoAP header. 926 The Object-Security ciphertext in the response [22.7 C] represents an 927 encrypted temperature reading. (The COSE object is actually carried 928 in the CoAP payload when possible but that is omitted to simplify 929 notation.) 931 6.3. Token Introspection with an Offline Client 933 In this deployment scenario we assume that a client is not be able to 934 access the AS at the time of the access request. Since the RS is, 935 however, connected to the back-end infrastructure it can make use of 936 token introspection. This access procedure involves steps A-F of 937 Figure 1, but assumes steps A and B have been carried out during a 938 phase when the client had connectivity to AS. 940 Since the client is assumed to be offline, at least for a certain 941 period of time, a pre-provisioned access token has to be long-lived. 942 The resource server may use its online connectivity to validate the 943 access token with the authorization server, which is shown in the 944 example below. 946 In the example we show the interactions between an offline client 947 (key fob), a resource server (online lock), and an authorization 948 server. We assume that there is a provisioning step where the client 949 has access to the AS. This corresponds to message exchanges A and B 950 which are shown in Figure 13. 952 A: The client sends the request using POST to /token at AS. The 953 request contains the Audience parameter set to "lockOfDoor4711", a 954 value the that the online door in question identifies itself with. 955 The AS generates an access token as on opaque string, which it can 956 match to the specific client, a targeted audience and a symmetric 957 key security context. 959 B: The AS responds with the an access token and client 960 information, the latter containing a symmetric key. Communication 961 security between C and RS will be OSCOAP with authenticated 962 encryption. 964 Authorization 965 Client Server 966 | | 967 | | 968 A: +-------->| Header: POST (Code=0.02) 969 | POST | Uri-Path:"token" 970 | | Payload: 971 | | 972 B: |<--------+ Header: 2.05 Content 973 | | Content-Type: application/cbor 974 | 2.05 | Payload: 975 | | 977 Figure 13: Token Request and Response using Client Credentials. 979 Authorization consent from the resource owner can be pre-configured, 980 but it can also be provided via an interactive flow with the resource 981 owner. An example of this for the key fob case could be that the 982 resource owner has a connected car, he buys a generic key that he 983 wants to use with the car. To authorize the key fob he connects it 984 to his computer that then provides the UI for the device. After that 985 OAuth 2.0 implicit flow is used to authorize the key for his car at 986 the the car manufacturers AS. 988 The information contained in the Request-Payload and the Response- 989 Payload is shown in Figure 14. 991 Request-Payload: 992 { 993 "grant_type" : "token", 994 "aud" : "lockOfDoor4711", 995 "client_id" : "myclient", 996 } 998 Response-Payload: 999 { 1000 "access_token" : b64'SlAV32hkKG ...' 1001 "token_type" : "pop", 1002 "csp" : "OSCOAP", 1003 "key" : b64'eyJhbGciOiJSU0ExXzUi ...' 1004 } 1006 Figure 14: Request and Response Payload for C offline 1008 The access token in this case is just an opaque string referencing 1009 the authorization information at the AS. 1011 C: Next, the client POSTs the access token to the /authz-info 1012 resource in the RS. This is a plain CoAP request, i.e. no DTLS/ 1013 OSCOAP between client and RS. Since the token is an opaque 1014 string, the RS cannot verify it on its own, and thus defers to 1015 respond the client with a status code until step E and only 1016 acknowledges on the CoAP message layer (indicated with a dashed 1017 line). 1019 Resource 1020 Client Server 1021 | | 1022 C: +-------->| Header: POST (T=CON, Code=0.02 1023 | POST | Token 0x2a12) 1024 | | Uri-Path:"authz-info" 1025 | | Payload: SlAV32hkKG ... 1026 | | (access token) 1027 | | 1028 |<- - - - + Header: T=ACK 1029 | | 1031 Figure 15: Access Token provisioning to RS 1033 D: The RS forwards the token to the /introspect resource on the 1034 AS. Introspection assumes a secure connection between the AS and 1035 the RS, e.g. using DTLS or OSCOAP, which is not detailed in this 1036 example. 1038 E: The AS provides the introspection response containing claims 1039 about the token. This includes the confirmation key (cnf) claim 1040 that allows the RS to verify the client's proof of possession in 1041 step F. 1043 After receiving message E, the RS responds to the client's POST in 1044 step C with Code 2.04 (Changed), using CoAP Token 0x2a12. This 1045 step is not shown in the figures. 1047 Resource Authorization 1048 Server Server 1049 | | 1050 D: +--------->| Header: POST (Code=0.02) 1051 | POST | Uri-Path: "introspect" 1052 | | Payload: 1053 | | 1054 E: |<---------+ Header: 2.05 Content 1055 | 2.05 | Content-Type: application/cbor) 1056 | | Payload: 1057 | | 1059 Figure 16: Token Introspection for C offline 1061 The information contained in the Request-Payload and the Response- 1062 Payload is shown in Figure 17. 1064 Request-Payload: 1065 { 1066 "token" : b64'SlAV32hkKG...', 1067 "client_id" : "myRS", 1068 "client_secret" : "ytrewq" 1069 } 1071 Response-Payload: 1072 { 1073 "active" : true, 1074 "aud" : "lockOfDoor4711", 1075 "scope" : "open, close", 1076 "iat" : 1311280970, 1077 "cnf" : { 1078 "ck" : b64'JDLUhTMjU2IiwiY3R5Ijoi ...' 1079 } 1080 } 1082 Figure 17: Request and Response Payload for Introspection 1084 The client sends the CoAP requests PUT 1 (= "close the lock") to 1085 /lock on RS using OSCOAP with a security context derived from the 1086 key supplied in step B. The RS verifies the request with the key 1087 supplied in step E and that it is authorized by the token supplied 1088 in step C. 1090 F: The RS responds with a protected status code using OSCOAP. The 1091 client verifies the response. 1093 Resource 1094 Client Server 1095 | | 1096 +-------->| Header: PUT (Code=0.03) 1097 | PUT | Object-Security: 1098 | | (,,[Uri-Path:"lock", 1],) 1099 | | 1100 F: |<--------+ Header: 2.04 Changed 1101 | 2.04 | Object-Security: 1102 | | (,,,) 1103 | | 1105 Figure 18: Resource request and response protected by OSCOAP 1107 The Object-Security ciphertext [...] of the PUT request contains CoAP 1108 options that are encrypted, as well as the payload value '1' which is 1109 the value of PUT to the door lock. 1111 In this example there is no ciphertext of the PUT response, but "tag" 1112 contains a MAC which covers the request sequence number and context 1113 identifier as well as the Code which allows the Client to verify that 1114 this actuator command was well received (door is locked). 1116 6.4. Always-On Connectivity 1118 A popular deployment scenario for IoT devices is to have them always 1119 be connected to the Internet so that they can be reachable to receive 1120 commands. As a continuation from the previous scenarios we assume 1121 that both the client and the RS are online at the time of the access 1122 request. 1124 If the client and the resource server are online then the AS should 1125 be configured to issue short-lived access tokens for the resource to 1126 the client. The resource server must then validate self-contained 1127 access tokens or otherwise must use token introspection to obtain the 1128 up-to-date claim information. If transmission costs are high or the 1129 channel is lossy, the CWT token format 1130 [I-D.wahlstroem-ace-cbor-web-token] may be used instead of a JWT to 1131 reduce the volume of network traffic. In terms of messaging this 1132 deployment scenario uses the patterns described in the previous sub- 1133 sections. 1135 Note that despite the lack of connectivity constraints there may 1136 still be other restrictions a deployment may face. 1138 6.5. Token-less Authorization 1140 In this deployment scenario we consider the case of an RS which is 1141 severely energy constrained, sleeps most of the time and need to have 1142 a tight messaging budget. It is not only infeasible to access the AS 1143 at the time of the access request, as in the "RS offline" case 1144 Section 6.2, it must be offloaded as much message communication as 1145 possible. 1147 OAuth 2.0 is already an efficient protocol in terms of message 1148 exchanges and can be further optimized by compact encodings of 1149 tokens. The scenario illustrated in this section goes beyond that 1150 and removes the access tokens from the protocol. This may be 1151 considered a degenerate case of OAuth 2.0 but it allows us to do two 1152 things: 1154 1. The common case where authorization is performed by means of 1155 authentication fits into the same protocol framework. 1156 Authentication protocol and key is specified by client 1157 information, and access token is omitted. 1159 2. Authentication, and thereby authorization, may even be implicit, 1160 i.e. anyone with access to the right key is authorized to access 1161 the protected resource. 1163 In case 2., the RS does not need to receive any message from the 1164 client, and therefore enables offloading recurring resource request 1165 and response processing to a third party, such as a Message Broker 1166 (MB) in a publish-subscribe setting. 1168 This scenario involves steps A, B, C and F of Figure 1 and four 1169 parties: a client (subscriber), an offline RS (publisher), a trusted 1170 AS, and a MB, not necessarily trusted with access to the plain text 1171 publications. Message exchange A, B is shown in Figure 19. 1173 A: The client sends the request POST to /token at AS. The request 1174 contains the Audience parameter set to "birchPollenSensor301", a 1175 value that characterizes a certain pollen sensor resource. The AS 1176 evaluates the request and authorizes the client to access the 1177 resource. 1179 B: The AS responds with an empty token and client information with 1180 a security context to be used by the client. The empty token 1181 signifies that authorization is performed by means of 1182 authentication using the communication security protocol indicated 1183 with "csp". In this case it is object security of content (OSCON) 1184 i.e. protection of CoAP payload only. The security context 1185 contains the symmetric decryption key and a public signature 1186 verification key of the RS. 1188 Authorization 1189 Client Server 1190 | | 1191 | | 1192 A: +-------->| Header: POST (Code=0.02) 1193 | POST | Uri-Path:"token" 1194 | | Payload: 1195 | | 1196 B: |<--------+ Header: 2.05 Content 1197 | | Content-Type: application/cbor 1198 | 2.05 | Payload: 1199 | | 1200 | | 1202 Figure 19: Token Request and Response 1204 The information contained in the Request-Payload and the Response- 1205 Payload is shown in Figure 20. 1207 Request-Payload : 1208 { 1209 "grant_type" : "client_credentials", 1210 "aud" : "birchPollenSensor301", 1211 "client_id" : "myclient", 1212 "client_secret" : "qwerty" 1213 } 1215 Response-Payload : 1216 { 1217 "access_token" : NULL, 1218 "token_type" : "none", 1219 "csp" : "OSCON", 1220 "key" : b64'eyJhbGciOiJSU0ExXzUi ...' 1221 } 1223 Figure 20: Request and Response Payload for RS severely constrained 1225 The content of the "key" parameter is shown in Figure 21. 1227 key : 1228 { 1229 "alg" : "AES_128_CTR_ECDSA", 1230 "kid" : b64'c29tZSBvdGhlciBrZXkgaWQ'; 1231 "k" : b64'ZoRSOrFzN_FzUA5XKMYoVHyzff5oRJxl-IXRtztJ6uE', 1232 "crv" : "P-256", 1233 "x" : b64'MKBCTNIcKUSDii11ySs3526iDZ8AiTo7Tu6KPAqv7D4', 1234 "y" : b64'4Etl6SRW2YiLUrN5vfvVHuhp7x8PxltmWWlbbM4IFyM' 1235 } 1237 Figure 21: The 'key' Parameter 1239 The RS, which sleeps most of the time, occasionally wakes up, 1240 measures the number birch pollens per cubic meters, publishes the 1241 measurements to the MB, and then returns to sleep. See Figure 22. 1243 In this case the birch pollen count stopped at 270, which is 1244 encrypted with the symmetric key and signed with the private key of 1245 the RS. The MB verifies that the message originates from RS using 1246 the public key of RS, that it is not a replay of an old measurement 1247 using the sequence number of the OSCON COSE profile, and caches the 1248 object secured content. The MB does not have the secret key so is 1249 unable to read the plain text measurement. 1251 Message exchanges C and F are shown in Figure 22. 1253 C: Since there is no access token, the client does not address the 1254 /authz-info resource in the RS. The client sends the CoAP request 1255 GET to /birchPollen on MB which is a plain CoAP request. 1257 F: The MB responds with the cached object secured content. 1259 Message Resource 1260 Client Broker Server 1261 | | | 1262 | |<--------| Header: PUT (Code=0.02) 1263 | | PUT | Uri-Path: "birchPollen" 1264 | | | Payload: (,,["270"],) 1265 | | | 1266 | |-------->| Header: 2.04 Changed 1267 | | 2.04 | 1268 | | 1269 | | 1270 C: +-------->| Header: GET (Code=0.01) 1271 | GET | Uri-Path: "birchPollen" 1272 | | 1273 | | 1274 F: |<--------+ Header: 2.05 Content 1275 | 2.05 | Payload: (,,["270"],) 1276 | | 1278 Figure 22: Sensor measurement protected by COSE 1280 The payload is a COSE message consisting of sequence number 'seq' 1281 stepped by the RS for each publication, the context identifier 'cid' 1282 in this case coinciding with the key identifier 'kid' of Figure 21, 1283 the encrypted measurement and the signature by the RS. 1285 Note that the same COSE message format may be used as in OSCOAP but 1286 that only CoAP payload is protected in this case. 1288 The authorization step is implicit, so while any client could request 1289 access the COSE object, only authorized clients have access to the 1290 symmetric key needed to decrypt the content. 1292 Note that in this case the order of the message exchanges A,B and C,F 1293 could in principle be interchanged, i.e. the client could first 1294 request and obtain the protected resource in steps C,F; and after 1295 that request client information containing the keys decrypt and 1296 verify the message. 1298 6.6. Securing Group Communication 1300 There are use cases that require securing communication between a 1301 (group of) senders and a group of receivers. One prominent example 1302 is lighting. Often, a set of lighting nodes (e.g., luminaires, wall- 1303 switches, sensors) are grouped together and only authorized members 1304 of the group must be able read and process messages. Additionally, 1305 receivers of group messages must be able to verify the integrity of 1306 received messages as being generated within the group. 1308 The requirements for securely communicating in such group use cases 1309 efficiently is outlined in [I-D.somaraju-ace-multicast] along with an 1310 architectural description that aligns with the content of this 1311 document. The requirements for conveying the necessary identifiers 1312 to reference groups and also the process of commissioning devices can 1313 be accomplished using the protocol described in this document. For 1314 details about the lighting-unique use case aspects, the architecture, 1315 as well as other multicast-specific considerations we refer the 1316 reader to [I-D.somaraju-ace-multicast]. 1318 7. Security Considerations 1320 The entire document is about security. Security considerations 1321 applicable to authentication and authorization in RESTful 1322 environments provided in OAuth 2.0 [RFC6749] apply to this work, as 1323 well as the security considerations from [I-D.ietf-ace-actors]. 1324 Furthermore [RFC6819] provides additional security considerations for 1325 OAuth which apply to IoT deployments as well. Finally 1326 [I-D.ietf-oauth-pop-architecture] discusses security and privacy 1327 threats as well as mitigation measures for Proof-of-Possession 1328 tokens. 1330 8. IANA Considerations 1332 TBD 1334 9. Acknowledgments 1336 We would like to thank Eve Maler for her contributions to the use of 1337 OAuth 2.0 and UMA in IoT scenarios, Robert Taylor for his discussion 1338 input, and Malisa Vucinic for his input on the ACRE proposal 1339 [I-D.seitz-ace-core-authz] which was one source of inspiration for 1340 this work. Finally, we would like to thank the ACE working group in 1341 general for their feedback. 1343 10. References 1345 10.1. Normative References 1347 [I-D.bormann-core-ace-aif] 1348 Bormann, C., "An Authorization Information Format (AIF) 1349 for ACE", draft-bormann-core-ace-aif-03 (work in 1350 progress), July 2015. 1352 [I-D.ietf-cose-msg] 1353 Schaad, J., "CBOR Encoded Message Syntax", draft-ietf- 1354 cose-msg-09 (work in progress), December 2015. 1356 [I-D.ietf-oauth-introspection] 1357 Richer, J., "OAuth 2.0 Token Introspection", draft-ietf- 1358 oauth-introspection-11 (work in progress), July 2015. 1360 [I-D.ietf-oauth-pop-architecture] 1361 Hunt, P., Richer, J., Mills, W., Mishra, P., and H. 1362 Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security 1363 Architecture", draft-ietf-oauth-pop-architecture-07 (work 1364 in progress), December 2015. 1366 [I-D.ietf-oauth-pop-key-distribution] 1367 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 1368 "OAuth 2.0 Proof-of-Possession: Authorization Server to 1369 Client Key Distribution", draft-ietf-oauth-pop-key- 1370 distribution-02 (work in progress), October 2015. 1372 [I-D.selander-ace-object-security] 1373 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1374 "Object Security of CoAP (OSCOAP)", draft-selander-ace- 1375 object-security-03 (work in progress), October 2015. 1377 [I-D.wahlstroem-ace-cbor-web-token] 1378 Wahlstroem, E., Jones, M., and H. Tschofenig, "CBOR Web 1379 Token (CWT)", draft-wahlstroem-ace-cbor-web-token-00 (work 1380 in progress), December 2015. 1382 [I-D.wahlstroem-ace-oauth-introspection] 1383 Wahlstroem, E., "OAuth 2.0 Introspection over the 1384 Constrained Application Protocol (CoAP)", draft- 1385 wahlstroem-ace-oauth-introspection-01 (work in progress), 1386 March 2015. 1388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1389 Requirement Levels", BCP 14, RFC 2119, 1390 DOI 10.17487/RFC2119, March 1997, 1391 . 1393 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1394 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1395 January 2012, . 1397 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1398 Application Protocol (CoAP)", RFC 7252, 1399 DOI 10.17487/RFC7252, June 2014, 1400 . 1402 10.2. Informative References 1404 [I-D.ietf-ace-actors] 1405 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 1406 architecture for authorization in constrained 1407 environments", draft-ietf-ace-actors-02 (work in 1408 progress), October 2015. 1410 [I-D.ietf-core-block] 1411 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 1412 draft-ietf-core-block-18 (work in progress), September 1413 2015. 1415 [I-D.seitz-ace-core-authz] 1416 Seitz, L., Selander, G., and M. Vucinic, "Authorization 1417 for Constrained RESTful Environments", draft-seitz-ace- 1418 core-authz-00 (work in progress), June 2015. 1420 [I-D.somaraju-ace-multicast] 1421 Somaraju, A., Kumar, S., and H. Tschofenig, "Multicast 1422 Security for the Lighting Domain", draft-somaraju-ace- 1423 multicast-00 (work in progress), July 2015. 1425 [RFC4680] Santesson, S., "TLS Handshake Message for Supplemental 1426 Data", RFC 4680, DOI 10.17487/RFC4680, October 2006, 1427 . 1429 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 1430 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 1431 . 1433 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1434 (TLS) Protocol Version 1.2", RFC 5246, 1435 DOI 10.17487/RFC5246, August 2008, 1436 . 1438 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 1439 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 1440 . 1442 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1443 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1444 . 1446 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1447 Threat Model and Security Considerations", RFC 6819, 1448 DOI 10.17487/RFC6819, January 2013, 1449 . 1451 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 1452 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 1453 October 2013, . 1455 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1456 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1457 2014, . 1459 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1460 Constrained-Node Networks", RFC 7228, 1461 DOI 10.17487/RFC7228, May 2014, 1462 . 1464 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1465 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1466 DOI 10.17487/RFC7231, June 2014, 1467 . 1469 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 1470 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 1471 . 1473 Appendix A. Design Justification 1475 This section provides further insight into the design decisions of 1476 the solution documented in this document. Section 3 lists several 1477 building blocks and briefly summarizes their importance. The 1478 justification for offering some of those building blocks, as opposed 1479 to using OAuth 2.0 as is, is given below. 1481 Common IoT constraints are: 1483 Low Power Radio: 1485 Many IoT devices are equipped with a small battery which needs to 1486 last for a long time. For many constrained wireless devices the 1487 highest energy cost is associated to transmitting or receiving 1488 messages. It is therefore important to keep the total 1489 communication overhead low, including minimizing the number and 1490 size of messages sent and received, which has an impact of choice 1491 of message format and protocol. By using CoAP over UDP, and CBOR 1492 encoded messages some of these aspects are addressed. Security 1493 protocols contribute to the communication overhead and can in some 1494 cases can be optimized. For example authentication and key 1495 establishment may in certain cases where security requirements so 1496 allows be replaced by provisioning of security context by a 1497 trusted third party, using transport or application layer 1498 security. 1500 Low CPU Speed: 1502 Some IoT devices are equipped with processors that are 1503 significantly slower than those found in most current devices on 1504 the Internet. This typically has implications on what timely 1505 cryptographic operations a device is capable to perform, which in 1506 turn impacts e.g. protocol latency. Symmetric key cryptography 1507 may be used instead of the computationally more expensive public 1508 key cryptography where the security requirements so allows, but 1509 this may also require support for trusted third party assisted 1510 secret key establishment using transport or application layer 1511 security. 1513 Small Amount of Memory: 1515 Microcontrollers embedded in IoT devices are often equipped with 1516 small amount of RAM and flash memory, which places limitations 1517 what kind of processing can be performed and how much code can be 1518 put on those devices. To reduce code size fewer and smaller 1519 protocol implementations can be put on the firmware of such a 1520 device. In this case, CoAP may be used instead of HTTP, symmetric 1521 key cryptography instead of public key cryptography, and CBOR 1522 instead of JSON. Authentication and key establishment protocol, 1523 e.g. the DTLS handshake, in comparison with assisted key 1524 establishment also has an impact on memory and code. 1526 User Interface Limitations: 1528 Protecting access to resources is both an important security as 1529 well as privacy feature. End users and enterprise customers do 1530 not want to give access to the data collected by their IoT device 1531 or to functions it may offer to third parties. Since the 1532 classical approach of requesting permissions from end users via a 1533 rich user interface does not work in many IoT deployment scenarios 1534 these functions need to be delegated to user controlled devices 1535 that are better suitable for such tasks, such as smart phones and 1536 tablets. 1538 Communication Constraints: 1540 In certain constrained settings an IoT device may not be able to 1541 communicate with a given device at all times. Devices may be 1542 sleeping, or just disconnected from the Internet because of 1543 general lack of connectivity in the area, for cost reasons, or for 1544 security reasons, e.g. to avoid an entry point for Denial-of- 1545 Service attacks. 1547 The communication interactions this framework builds upon (as 1548 shown graphically in Figure 1) may be accomplished using a variety 1549 of different protocols, and not all parts of the message flow are 1550 used in all applications due to the communication constraints. 1551 While we envision deployments to make use of CoAP we explicitly 1552 want to support HTTP, HTTP/2 or specific protocols, such as 1553 Bluetooth Smart communication, which does not necessarily use IP. 1554 The latter raises the need for application layer security over the 1555 various interfaces. 1557 Appendix B. Optimizations 1559 This section sketches some potential optimizations to the presented 1560 solution. 1562 Access token in DTLS handshake 1564 In the case of CSP=DTLS/TLS, the access token provisoning exchange 1565 in step C of the protocol may be embedded in the security 1566 handshake. Different solutions are possible, where one 1567 standardized method would be the use of the TLS supplemental data 1568 extension [RFC4680] for transferring the access token. 1570 Reference token and introspection 1572 In case of introspection it may be useful with access tokens which 1573 are not self-contained (also known as "reference tokens") that are 1574 used to lookup detailed information about the authorization. The 1575 RS uses the introspection message exchange not only for validating 1576 token claims, but also for obtaining claims that potentially were 1577 not known at the time when the access token was issued. 1579 A reference token can be made much more compact than a self- 1580 contained token, since it does not need to contain any of claims 1581 that it represents. This could be very useful in particular if 1582 the client is constrained and offline most of the time. 1584 Reference token in CoAP option 1586 While large access tokens must be sent in CoAP payload, if the 1587 access token is known to be of a certain limited size, for example 1588 in the case of a reference token, then it would be favorable to 1589 combine the access token provisioning request with the resource 1590 request to the RS. 1592 One way to achieve this is to define a new CoAP option for 1593 carrying reference tokens, called "Ref-Token" as shown in the 1594 example in Figure 23. 1596 Resource 1597 Client Server 1598 | | 1599 C: +-------->| Header: PUT (Code=0.02) 1600 | PUT | Ref-Token:SlAV32hkKG 1601 | | Object-Security: 1602 | | ,,[Uri-Path:"lock", 1],) 1603 | | 1604 . . 1605 . . 1606 . . 1607 | | 1608 F: |<--------+ Header: 2.04 Changed 1609 | 2.04 | Object-Security: 1610 | | (,,,) 1611 | | 1613 Figure 23: Reference Token in CoAP Option 1615 Appendix C. CoAP and CBOR profiles for OAuth 2.0 1617 Many IoT devices can support OAuth 2.0 without any additional 1618 extensions, but for certain constrained settings additional profiling 1619 is needed. In this appendix we define CoAP resources for the HTTP 1620 based token and introspection endpoints used in vanilla OAuth 2.0. 1621 We also define a CBOR alternative to the JSON and form based POST 1622 structures used in HTTP. 1624 C.1. Profile for Token resource 1626 The token resource is used by the client to obtain an access token by 1627 presenting its authorization grant or client credentials to the 1628 /token resource the AS. 1630 C.1.1. Token Request 1632 The client makes a request to the token resource by sending a CBOR 1633 structure with the following attributes. 1635 grant_type: 1637 REQUIRED. The grant type, "code", "client_credentials", 1638 "password" or others. 1640 client_id: 1642 OPTIONAL. The client identifier issued to the holder of the token 1643 (client or RS) during the registration process. 1645 client_secret: 1647 OPTIONAL. The client secret. 1649 scope: 1651 OPTIONAL. The scope of the access request as described by 1652 Section 3.1. 1654 aud: 1656 OPTIONAL. Service-specific string identifier or list of string 1657 identifiers representing the intended audience for this token, as 1658 defined in [I-D.wahlstroem-ace-cbor-web-token]. 1660 alg: 1662 OPTIONAL. The value in the 'alg' parameter together with value 1663 from the 'token_type' parameter allow the client to indicate the 1664 supported algorithms for a given token type. 1666 key: 1668 OPTIONAL. This field contains information about the public key 1669 the client would like to bind to the access token in the COSE Key 1670 Structure format. 1672 The parameters defined above use the following CBOR major types. 1674 /-----------+--------------+-----------------------\ 1675 | Value | Major Type | Key | 1676 |-----------+--------------+-----------------------| 1677 | 0 | 0 | grant_type | 1678 | 1 | 0 | client_id | 1679 | 2 | 0 | client_secret | 1680 | 3 | 0 | scope | 1681 | 4 | 0 | aud | 1682 | 5 | 0 | alg | 1683 | 6 | 0 | key | 1684 \-----------+--------------+-----------------------/ 1686 Figure 24: CBOR mappings used in token requests 1688 C.1.2. Token Response 1690 The AS responds by sending a CBOR structure with the following 1691 attributes. 1693 access_token: 1695 REQUIRED. The access token issued by the authorization server. 1697 token_type: 1699 REQUIRED. The type of the token issued. "pop" is recommended. 1701 key: 1703 REQUIRED, if symmetric key cryptography is used. A COSE Key 1704 Structure containing the symmetric proof of possession key. The 1705 members of the structure can be found in section 7.1 of 1706 [I-D.ietf-cose-msg]. 1708 csp: 1710 REQUIRED. Information on what communication protocol to use in 1711 the communication between the client and the RS. Details on 1712 possible values can be found in Section 5.1. 1714 scope: 1716 OPTIONAL, if identical to the scope requested by the client; 1717 otherwise, REQUIRED. 1719 alg: 1721 OPTIONAL. The 'alg' parameter provides further information about 1722 the algorithm, such as whether a symmetric or an asymmetric 1723 crypto-system is used. 1725 The parameters defined above use the following CBOR major types. 1727 /-----------+--------------+-----------------------\ 1728 | Value | Major Type | Key | 1729 |-----------+--------------+-----------------------| 1730 | 0 | 0 | access_token | 1731 | 1 | 0 | token_type | 1732 | 2 | 0 | key | 1733 | 3 | 0 | csp | 1734 | 4 | 0 | scope | 1735 | 5 | 0 | alg | 1736 \-----------+--------------+-----------------------/ 1738 Figure 25: CBOR mappings used in token responses 1740 C.2. CoAP Profile for OAuth Introspection 1742 This section defines a way for a holder of access tokens, mainly 1743 clients and RS's, to get metadata like validity status, claims and 1744 scopes found in access token. The OAuth Token Introspection 1745 specification [I-D.ietf-oauth-introspection] defines a way to 1746 validate the token using HTTP POST or HTTP GET. This document reuses 1747 the work done in the OAuth Token Introspection and defines a mapping 1748 of the request and response to CoAP [RFC7252] to be used by 1749 constrained devices. 1751 C.2.1. Introspection Request 1753 The token holder makes a request to the Introspection CoAP resource 1754 by sending a CBOR structure with the following attributes. 1756 token: 1758 REQUIRED. The string value of the token. 1760 resource_id: 1762 OPTIONAL. A service-specific string identifying the resource that 1763 the client doing the introspection is asking about. 1765 client_id: 1767 OPTIONAL. The client identifier issued to the holder of the token 1768 (client or RS) during the registration process. 1770 client_secret: 1772 OPTIONAL. The client secret. 1774 The parameters defined above use the following CBOR major types: 1776 /-----------+--------------+-----------------------\ 1777 | Value | Major Type | Key | 1778 |-----------+--------------+-----------------------| 1779 | 0 | 0 | token | 1780 | 1 | 0 | resource_id | 1781 | 2 | 0 | client_id | 1782 | 3 | 0 | client_secret | 1783 \-----------+--------------+-----------------------/ 1785 Figure 26: CBOR Mappings to Token Introspection Request Parameters. 1787 C.2.2. Introspection Response 1789 If the introspection request is valid and authorized, the 1790 authorization server returns a CoAP message with the response encoded 1791 as a CBOR structure in the payload of the message. If the request 1792 failed client authentication or is invalid, the authorization server 1793 returns an error response using the CoAP 4.00 'Bad Request' response 1794 code. 1796 The JSON structure in the payload response includes the top-level 1797 members defined in Section 2.2 in the OAuth Token Introspection 1798 specification [I-D.ietf-oauth-introspection]. It is RECOMMENDED to 1799 only return the 'active' attribute considering constrained nature of 1800 CoAP client and server networks. 1802 Introspection responses in CBOR use the following mappings: 1804 active: 1806 REQUIRED. The active key is an indicator of whether or not the 1807 presented token is currently active. The specifics of a token's 1808 "active" state will vary depending on the implementation of the 1809 authorization server, and the information it keeps about its 1810 tokens, but a "true" value return for the "active" property will 1811 generally indicate that a given token has been issued by this 1812 authorization server, has not been revoked by the resource owner, 1813 and is within its given time window of validity (e.g., after its 1814 issuance time and before its expiration time). 1816 scope: 1818 OPTIONAL. A string containing a space-separated list of scopes 1819 associated with this token, in the format described in Section 3.3 1820 of OAuth 2.0 [RFC6749]. 1822 client_id: 1824 OPTIONAL. Client identifier for the client that requested this 1825 token. 1827 username: 1829 OPTIONAL. Human-readable identifier for the resource owner who 1830 authorized this token. 1832 token_type: 1834 OPTIONAL. Type of the token as defined in Section 5.1 of OAuth 1835 2.0 [RFC6749] or PoP token. 1837 exp: 1839 OPTIONAL. Integer timestamp, measured in the number of seconds 1840 since January 1 1970 UTC, indicating when this token will expire, 1841 as defined in CWT [I-D.wahlstroem-ace-cbor-web-token]. 1843 iat: 1845 OPTIONAL. Integer timestamp, measured in the number of seconds 1846 since January 1 1970 UTC, indicating when this token will expire, 1847 as defined in CWT [I-D.wahlstroem-ace-cbor-web-token]. 1849 nbf: 1851 OPTIONAL. Integer timestamp, measured in the number of seconds 1852 since January 1 1970 UTC, indicating when this token will expire, 1853 as defined in CWT [I-D.wahlstroem-ace-cbor-web-token]. 1855 sub: 1857 OPTIONAL. Subject of the token, as defined in CWT 1858 [I-D.wahlstroem-ace-cbor-web-token]. Usually a machine-readable 1859 identifier of the resource owner who authorized this token. 1861 aud: 1863 OPTIONAL. Service-specific string identifier or list of string 1864 identifiers representing the intended audience for this token, as 1865 defined in CWT [I-D.wahlstroem-ace-cbor-web-token]. 1867 iss: 1869 OPTIONAL. String representing the issuer of this token, as 1870 defined in CWT [I-D.wahlstroem-ace-cbor-web-token]. 1872 cti: 1874 OPTIONAL. String identifier for the token, as defined in CWT 1875 [I-D.wahlstroem-ace-cbor-web-token] 1877 The parameters defined above use the following CBOR major types: 1879 /-----------+--------------+-----------------------\ 1880 | Value | Major Type | Key | 1881 |-----------+--------------+-----------------------| 1882 | 0 | 0 | active | 1883 | 1 | 0 | scopes | 1884 | 2 | 0 | client_id | 1885 | 3 | 0 | username | 1886 | 4 | 0 | token_type | 1887 | 5 | 0 | exp | 1888 | 6 | 0 | iat | 1889 | 7 | 0 | nbf | 1890 | 8 | 0 | sub | 1891 | 9 | 0 | aud | 1892 | 10 | 0 | iss | 1893 | 11 | 0 | cti | 1894 \-----------+--------------+-----------------------/ 1896 Figure 27: CBOR Mappings to Token Introspection Response Parameters. 1898 Authors' Addresses 1900 Ludwig Seitz 1901 SICS 1902 Scheelevaegen 17 1903 Lund 223 70 1904 SWEDEN 1906 Email: ludwig@sics.se 1907 Goeran Selander 1908 Ericsson 1909 Faroegatan 6 1910 Kista 164 80 1911 SWEDEN 1913 Email: goran.selander@ericsson.com 1915 Erik Wahlstroem 1916 Nexus Technology 1917 Telefonvagen 26 1918 Hagersten 126 26 1919 Sweden 1921 Email: erik.wahlstrom@nexusgroup.com 1923 Samuel Erdtman 1924 Nexus Technology 1925 Telefonvagen 26 1926 Hagersten 126 26 1927 Sweden 1929 Email: samuel.erdtman@nexusgroup.com 1931 Hannes Tschofenig 1932 ARM Ltd. 1933 Hall in Tirol 6060 1934 Austria 1936 Email: Hannes.Tschofenig@arm.com