idnits 2.17.1 draft-cuellar-ace-pat-priv-enhanced-authz-tokens-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2016) is 2857 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) == Missing Reference: 'Resource-REQ' is mentioned on line 352, but not defined == Unused Reference: 'I-D.ietf-core-resource-directory' is defined on line 794, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) == Outdated reference: A later version (-07) exists of draft-ietf-ace-actors-03 ** Downref: Normative reference to an Informational draft: draft-ietf-ace-actors (ref. 'I-D.ietf-ace-actors') == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-07 == 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') Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group J. Cuellar 3 Internet-Draft P. Kasinathan 4 Intended status: Standards Track Siemens AG 5 Expires: January 1, 2017 D. Calvo 6 Atos Research and Innovation 7 June 30, 2016 9 Privacy-Enhanced Tokens for Authorization in ACE 10 draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 12 Abstract 14 This specification defines PAT, "Privacy-Enhanced-Authorization- 15 Tokens" or "Pseudonym-based Authorization Tokens", a protocol and a 16 token construction procedure for client authorization in a 17 constrained environment. 19 The tokens can be also used to establish a Datagram Transport Layer 20 Security (DTLS) channel between resource-constrained nodes. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 1, 2017. 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Key words to Indicate Requirement Levels . . . . . . . . 3 58 1.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Actors and Terminology . . . . . . . . . . . . . . . . . 5 60 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Message Flow Overview . . . . . . . . . . . . . . . . . . 8 63 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. RS<->SAM : Security-association-Setup . . . . . . . . . . 9 65 4.2. [C->RS: Resource-Request] . . . . . . . . . . . . . . . . 9 66 4.3. [RS->C : Un-Authorized-Request(SAM-ID)] . . . . . . . . . 9 67 4.4. C<->SAM : Security-Association-Setup . . . . . . . . . . 10 68 4.5. C->SAM: Access-Request . . . . . . . . . . . . . . . . . 11 69 4.6. C<-SAM: Ticket-Transfer . . . . . . . . . . . . . . . . . 11 70 4.6.1. Construction of CT . . . . . . . . . . . . . . . . . 12 71 4.7. C->RS : Resource-Request . . . . . . . . . . . . . . . . 13 72 4.8. RS->C : Resource-Response . . . . . . . . . . . . . . . . 14 73 5. Construction of derived Keys . . . . . . . . . . . . . . . . 16 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 76 6.2. Informative References . . . . . . . . . . . . . . . . . 18 77 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 78 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. Copyright Statement . . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 Three well-known problems in constrained environments are the 85 authorization of clients to access resources on servers, the 86 realization of secure communication between nodes, and the 87 preservation of privacy. The reader is referred for instance to 88 [draft-ietf-ace-actors] and [KoMa2014]. 90 The Internet tackles certain aspects of those three problems. It 91 describes a way of constructing Token Material (Key Material) that 92 can be used by clients and servers (or in some cases, more generally 93 by arbitrary nodes) to create secure channels and provide 94 authentication. Moreover, the construction can be used to offer user 95 consent (in the sense of privacy) and to create dynamically 96 pseudonyms to enhance the unlinkability of the information, see 97 Subsection "Features" below. 99 This draft uses the same architecture of [draft-ietf-ace-actors], 100 designed to help constrained nodes with authorization-related tasks 101 via less-constrained nodes. PAT supports an implicit authorization 102 mode where no authorization information is exchanged and uses access 103 tokens to implement this architecture. A device that wants to access 104 an item of interest on a constrained node first has to gain 105 permission in the form of a token from the node's Authorization 106 Manager. 108 A main goal of PAT is to securely transmit authorization tokens. A 109 by-product is the setup of a Datagram Transport Layer Security (DTLS) 110 [RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279] 111 between two nodes. Notice that the DTLS channel is not needed to 112 securely transmit the authorization tokens, the authorization tokens 113 may also be exchanged as described in [draft-ietf-ace-oauth-authz] 114 which will be discussed in the future version of the ID. In some 115 cases, relevant in constrained environments, it is also not necessary 116 for a secure transmission of the payload data from server to client. 118 1.1. Key words to Indicate Requirement Levels 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC-2119 [RFC2119]. 124 In this document, these words will appear with that interpretation 125 only when in ALL CAPS. Lower case uses of these words are not to be 126 interpreted as carrying RFC-2119 significance. 128 In this document, the characters ">>" preceding an indented line(s) 129 indicates a compliance requirement statement using the key words 130 listed above. This convention aids reviewers in quickly identifying 131 or finding the explicit compliance requirements of this RFC 133 1.2. Features 135 o The method allows a User, or an Authentication/Authorization 136 Manager on its behalf, to authorize one (or several) client(s) to 137 access resources on a server. The client and/or the server can be 138 constrained devices. The authorization is implemented by 139 distributing purpose-built Key Material (which we generically call 140 "Tokens") to the server and clients. This SHOULD be done by 141 secure channels. 143 o The Client Tokens are crafted in such a way that the clients can 144 construct authorization tokens that allow them to demonstrate to 145 the server their authorization claims. The message exchange 146 between client and server for the presentation of the tokens MAY 147 be performed via insecure channels. 149 o Further, the purpose-built Key material and tokens can be used for 150 establishing a secret shared key between a client and the server, 151 which can be then used to establish a DTLS communication with pre- 152 shared keys. 154 o The tokens do not provide any information about any associated 155 identities or identifiers of the clients nor of the server. 157 In particular, the method can be used in context where unlinkability 158 (privacy) is a main goal: the tokens convey only the assurance of the 159 authorization claims of the clients. This means that the payloads of 160 our protocol, and in particular, the Authentication Token secrets 161 used, can be constructed in such a way that they not leak information 162 about the correspondence of messages to the same Client. In other 163 words: if an eavesdropper observes the messages from the different 164 Clients to and from the server, the protocol does not give him 165 information about which messages correspond to the same Client. Of 166 course, other information, like the IP-addresses or the contents 167 themselves of the requests/responses may leak some information in 168 this regard, but that is not information leaked by our protocol and 169 can be treated separately. 171 o The tokens may be supported by a "proof-of-possession" (PoP) 172 method. PoP allows an authorized entity (a client) to prove to 173 the verifier (here, the server), that he is indeed the intended 174 authorized owner of the token and not simply the bearer of the 175 token. (Notice that the Authorization Token may be sent in the 176 clear, and thus, it could be stolen by an intruder. A PoP would 177 hinder the attacker to use the token pretending to be authorized). 179 o The Key Material can be used to generate and coordinate pseudonyms 180 between C and RS and potentially further parties. 182 o The user (more precisely, the Resource Owner, RO, see 183 Section "Actors and Terminology" below) is able to decide (if he 184 wishes: in a fine-grained way and in real-time) which client under 185 which circumstances may access his data stored in RS. This can be 186 used to provide consent (in terms of privacy) from users (again, 187 ROs). 189 The PAT protocol has the following features: 191 o Simplified authentication on constrained nodes by handing the more 192 sophisticated authentication over to less-constrained devices 194 o Support of secure communication between constrained devices 196 o Authorization policies of the principals of both participating 197 parties are ensured 199 o Simplified authorization mechanism for cases where implicit 200 authorization is sufficient 202 o Using only symmetric encryption on constrained nodes 204 1.3. Actors and Terminology 206 The actors and terminology are the similar to [I-D.ietf-ace-actors]. 207 Very briefly, for the purposes of this draft, the main actors are: 209 o Resource Server (RS): An endpoint which is a constrained device 210 that hosts and represents a Resource (R). 212 o Client (C): An endpoint that attempts to access a resource on RS. 214 o Server Authorization Manager (SAM): An entity that prepares and 215 endorses authentication and authorization data for a RS. 217 o Client Authorization Manager (CAM): An optional entity that 218 prepares and endorses authentication and authorization data for a 219 C. 221 o Resource Owner (RO): The principal that is in charge of the 222 resource and controls its access permissions. The RO is often the 223 data subject of the protected resource. 225 In addition to the terms defined in [I-D.ietf-ace-actors], we use 226 additionally the following terms: 228 o Client Token (CT): The token which is generated by the SAM for the 229 Client. It contains a secret, which can be used to generate the 230 Access-Token, plus some other data used for PoP. Optionally CT 231 may contain authorization information that represents RO's 232 authorization policies for C. 234 o Access-Token (AT): The token which is generated by the Client and 235 presented by him to the RS. It contains a secret, which changes 236 regularly (in a similar way to one-time passwords). The AT 237 contains all information needed by the RS to verify that it was 238 granted by SAM. The Access-Tokens can also be interpreted as 239 Authentication Tokens in this context. 241 Further, C and RS may derive keys from the initial secret: 243 o VerifK: to verify that they are talking with the intended partner, 244 for the Client C it is used as Proof of Possession of the 245 (current) Access-Token 247 o PSK: as Pre-shared Key to establish a DTLS secure channel 249 o IntK: for Integrity protection (in message authentication codes) 251 o ConfK: for Confidentiality Protection (to be elaborated in a 252 future version of the document). 254 2. System Overview 256 Each Resource Server (RS) has a Server Authorization Manger (SAM) 257 which provides the authentication and authorization for RS. To gain 258 access to a specific resource on a Resource Server RS, a Client (C) 259 requests a token from SAM, either directly or using its CAM. In the 260 following, for simplicity, we avoid Client Authorization Manager's 261 (CAM) role. After SAM receives the request from C, he decides if C 262 is allowed to access the resource or not. If so, SAM generates a 263 Client-Token used for the authorization and for securing the 264 communication between C and RS. 266 For explicit access control, SAM adds the detailed access permissions 267 to the token in a way that C (or his CAM) can interpret and RS can 268 verify as authentically stemming from SAM. Then C presents the 269 Access-Token to RS, demonstrating his authorization, and C and RS can 270 establish a secure channel. 272 3. Protocol Overview 274 In PAT protocol, the token generation is similar to how Proof of 275 Possession tokens are constructed in [I-D.ietf-oauth-pop- 276 architecture]. In the discussed protocol, three actors RS, C, SAM 277 are involved and it may involve CAM as an intermediary for client 278 authentication but CAM is not taken into consideration in the 279 discussed version of PAT protocol. Notice that in comparison to [I- 280 D.ietf-oauth-pop-architecture], we propose a different method to 281 construct the token for C by SAM, and we introduce methods to resist 282 Denial-of-service (DoS) attacks on the resource constrained server 283 (RS). 285 In Figure 1 we show PAT protocol's interaction between RS, SAM and C. 287 +---------+ 288 (B) Access-Request | | 289 +--------------------------------> | 290 | | SAM | 291 | +-----------------------------+ | 292 | | (C) Ticket-Transfer | | 293 | | +---^-----+ 294 | | | 295 | | | 296 | | | 297 +----v+ PAT |(A) Shared-Secret 298 | | PROTOCOL | 299 | C | | 300 | | | 301 +-^---+ | 302 | | | 303 | | (D) Resource+Request +---v---+ 304 | +------------------------------+ | 305 | | RS | 306 +--------------------------------+ | 307 (E) Resource-Response +-------+ 309 Figure 1: PAT protocol 311 The SAM and RS share a long term secret (A). To determine SAM which 312 in charge of a resource hosted at the RS, C MAY send an initial 313 Resource-Request without valid access token to RS. RS denies the 314 request without valid access token and could possibly include the 315 address of its SAM back to C as a response. Or, instead of the 316 initial Resource-Request without valid access token, C MAY look up 317 the desired resource in a resource directory (see [I-D.ietf-core- 318 resource-directory]) that lists the available resources. 320 Once C knows SAM's address, it can send an (B) Access-Request for 321 authorization to SAM (directly, or indirectly using its own CAM). If 322 the access is to be authorized, SAM generates a (C) Ticket-Transfer 323 to C. It contains Key-material for generating all necessary tokens 324 and keys, and, if necessary, a representation of the permissions C 325 has for the resource. 327 Each time C sends RS a (D) Resource-Request, it generates and 328 presents an Access-Token to RS to prove its right to access. If the 329 access-token is valid, RS sends a (E) Resource-Response to the C. 330 Later with the common established secret C and RS can generate 331 derived keys which is described later in the draft. 333 The following section describes the message flow in more detail, 334 especially how the messages, tokens are constructed and how RS and C 335 can use their common knowledge to verify the authenticity of the ATs 336 and to derive the shared keys VerifK, PSK, IntK, and ConfK. 338 3.1. Message Flow Overview 340 In Figure 2, a PAT protocol flow is depicted (messages in square 341 brackets are optional). Notice that the DTLS channel between C and 342 RS is optional in comparison to [I-D.ietf-oauth-pop-architecture]. 343 The resource response from RS to C can be optionally secured by DTLS 344 or by other native PAT methods. 346 ,-. ,--. ,---. 347 |C| |RS| |SAM| 348 `+' `+-' `-+-' 349 | | 1 Security-Association-Setup | 350 | | <--------------------------->| 351 | | | 352 | 2 [Resource-REQ] | | 353 |-----------------------> | 354 | | | 355 |3 [Un-Auth-REQ(SAM-ID)]| | 356 |<----------------------- | 357 | | | 358 | 4 Security-Association-Setup | 359 |<---------------------------------------------------->| 360 | | | 361 | 5 Access-REQ | 362 |----------------------------------------------------->| 363 | | | 364 | 6 Ticket-Transfer | 365 |<-----------------------------------------------------| 366 | | | 367 | 7 Resource-REQ | | 368 |-----------------------> | 369 | | | 370 | 8 Resource-RSP | | 371 |<----------------------- | 372 ,+. ,+-. ,-+-. 373 |C| |RS| |SAM| 374 `-' `--' `---' 375 Figure 2: PAT Protocol message flow 377 4. Protocol Details 379 As CoAP [RFC7252] is the recommended application layer protocol for 380 constrained devices, the PAT protocol is designed to work with CoAP, 381 wherever necessary appropriate recommendations are made for using 382 CoAP parameters with the proposed protocol. 384 The following notation: 386 A->B: 388 represents the message with name Msg_Name, sent from A to B. 390 4.1. RS<->SAM : Security-association-Setup 392 We assume that the Resource Server RS and its Authentication Manager 393 SAM share a secure channel and share a long term shared secret, i.e., 394 a shared key K, which may be implemented via USB (and physical 395 security) or via DTLS, etc. We do not assume any particular concrete 396 secure channel, but it must be stressed that the security of the 397 protocol strongly depends on how this secure this channel is. We can 398 also assume that the CAM and SAM share a secure connection, say over 399 DTLS if CAM exist as an actor. 401 4.2. [C->RS: Resource-Request] 403 Initially, C may not have a valid access token to access the resource 404 hosted in RS. Initially, C performs a request (could be a CoAP GET 405 or POST message [RFC7252]) to RS for a resource, given by an URI. 406 The Resource Request message is OPTIONAL . 408 It is assumed that C does not have information about SAM but has 409 information about RS and the resource R it needs to access. 411 RS MUST treat any CoAP request as Unauthorized Resource Request 412 message when any of two following holds: 414 o If the sender does not present a valid access token for the 415 requested resource. 417 o If the sender does not present valid access token for the 418 requested action on the requested resource. 420 4.3. [RS->C : Un-Authorized-Request(SAM-ID)] 422 Once RS receives a request from a C, it checks the following: 424 o whether C has a valid access ticket. 426 * If not, it may respond to C with an un-authorized request 427 message which contains information about SAM (SAM-ID) which 428 includes additional parameters such as URI and other relevant 429 information to reach SAM. 431 * If C has a valid access ticket, but it does not include 432 appropriate rights to perform the requested action (i.e., C may 433 have a valid access ticket to perform a GET() but not POST()), 434 RS responds back with appropriate response (In CoAP, 4.05 435 Method Not Allowed [RFC7252] is sent as response) 437 Figure 3 shows the sequence of messages with detailed CoAP types 438 between C and RS for the above Unauthorized resource request: 440 ,-. ,--. 441 |C| |RS| 442 `+' `+-' 443 ,--------------------.| | 444 |Code: GET(Code=1) || 1 Res-REQ | 445 |Type: Confirmable ||----------->| 446 |Token: invalid-tkn || | 447 |URI-Path: test || | 448 `--------------------'| | 449 | | ,-------------------------. 450 | | |Code: 4.01 Unauthorized | 451 | 2 Res-RSP | |Type: Acknowledgement | 452 |<-----------| |Token: invalid-tkn | 453 | | |content-type: | 454 | | |application/cbor | 455 | | |Payload:{SAM-ID,params} | 456 ,+. ,+-.`-------------------------' 457 |C| |RS| 458 `-' `--' 459 Figure 3: C<->RS Resource-Request and Unauthorized-Request as response 461 4.4. C<->SAM : Security-Association-Setup 463 Once C receives SAM-ID which contains the information to reach SAM, C 464 or CAM (if involved) SHOULD establish a secure connection channel. 466 o The SAM may have an access control list for the clients, with that 467 SAM can verify if the client is allowed to establish a secure 468 connection or not. The methods to implement access control in 469 this regard are out of scope of this draft. 471 o If the client has valid access to the resource in RS, then SAM 472 establishes a confidential channel with C. This draft does not 473 specify how this secure connection should be established, it could 474 be a DTLS channel with pre-shared key. 476 Notice that, it is important to ensure that this connection is 477 reliable and secure as the remainder of this protocol lies on the 478 fact that the messages exchanged between C and SAM are protected. 480 4.5. C->SAM: Access-Request 482 Once C establishes a secure communication channel with SAM, C sends 483 an access request message to SAM. 485 The C includes the details about the resources (R) and operations it 486 needs to access / perform on RS to SAM as part of the Access-Request 487 Message. This depends on the infrastructure or services the RS 488 offers. For example, if RS exposes resources such as temperature and 489 humidity, a generic token may be granted by SAM to C to access both 490 resources on RS. On the other hand, the application developer or 491 administrator may decide to have fine grained (different) tokens for 492 temperature and humidity. 494 4.6. C<-SAM: Ticket-Transfer 496 When SAM receives an access-request from a C, it validates the 497 access-request message. If the access request from C is valid, SAM 498 creates and sends the Client-Token CT for C through a Ticket-Transfer 499 message. 501 The Figure 4 shows the Access request message from C to SAM and the 502 consequent Ticket Transfer as a response from SAM to C. 504 ,-. ,---. 505 |C| |SAM| 506 `+' `-+-' 507 | | 508 | ======== | 509 ================================= DTLS ============================== 510 | ======== | 511 | | 512 ,--------------------------.| | 513 |Code:POST || 1 Access-REQ | 514 |Content-Format:CBOR ||----------------->| 515 |URI-Path: authorize || | 516 |Payload:{RES,Operations} || | 517 `--------------------------'| | 518 | | ,------------------. 519 |2 Ticket-Transfer | |Code:Content | 520 |<-----------------| |content-type: | 521 | | |application/cbor | 522 | | |Payload:{CT} | 523 | | `------------------' 524 | | 525 | ======== | 526 ================================= DTLS ============================== 527 | ======== | 528 ,+. ,-+-. 529 |C| |SAM| 530 `-' `---' 531 Figure 4: Access-Request and Ticket-Transfer 533 4.6.1. Construction of CT 535 This sub-section describes how SAM generates the CT for C. SAM uses 536 PoP token method to construct CT and it is constructed using HMAC 537 algorithm instead of encryption as described in [I-D.ietf-oauth-pop- 538 architecture]. The CT includes a Face, a Verifier and some 539 additional information which isblazer described in detail below: 541 A Face is constructed as the following: 543 o Face: SAI, timestamp, time-to-live, random 545 * Server Authorization Information (SAI): It contains the 546 resource server URI with the allowed permissions. 548 * timestamp: It contains the timestamp information 550 * time-to-live: (or lifetime ) It is used to limit the validity 551 of the access tickets [optional] 553 * random: random seed on the token such that we make Face non- 554 deterministic, this random number can be generated by any 555 Pseudo-Random-Generator 557 The Face can be optionally encoded in CBOR format. Note that the 558 time-synchronization between SAM and RS may be implemented based on 559 the application requirements is out of scope of this draft. 561 o Verifier: G (K, Face) Notice that G takes two parameters (key, 562 data) as input and produced a keyed digest as the output 564 * G: the HMAC algorithm which is used to create the verifier, we 565 propose Poly1305 [RFC7539] 567 * K: the shared key between SAM and RS 569 * Face: it is obtained from the previous step 571 o Client-Token: Face, Verifier, Additional_Information 573 * Face: what we obtained from first step 575 * Verifier: what we obtained from previous step 577 * Additional-Information: it may contain information about 578 cryptographic algorithms such as AEAD, Hash and HMAC. 580 Notice that the Ticket transfer message and the verifier MUST be sent 581 to C through a secure channel. The client will use the Verifier as 582 the key material to communicate with the Resource Server. 584 4.7. C->RS : Resource-Request 586 When C receives the ticket-transfer from SAM, C can construct a valid 587 Access-Token, AT, which will demonstrate his authorization to RS that 588 he may access the resources he is requesting. 590 Regularly, the message Resource-Req with new AT has to be sent 591 afresh: Client C has to renew his Authorization status at the 592 Resource Server. The frequency in which the Client has to send a new 593 AT can be enforced by RS and is determined indirectly by the owner of 594 RS (or by SAM). This allows a fine-grained control on the service 595 level that the Resource Server will provide to the Client (for 596 instance, on the amount of information of sensor data). 598 Each time a Resource-Req is sent, a new Access-Token MAY be needed. 599 Optionally, communications between C and RS can be encrypted using a 600 part of the access ticket to enforce confidentiality if necessary. 602 o For example if C performs: 604 * a CoAP GET() request, C does not have any payload therefore no 605 need for encryption 607 * a CoAP POST() request with payload, C may create a authorized 608 resource request message by encrypting the "payload" using an 609 algorithm described in Face's Additional-Information. We 610 propose ChaCha20-Poly1305-AEAD authenticated encryption 611 mechanism, while using the Verifier as the key and CoAP-MID as 612 the nonce 614 The Resource-Request message with valid Access-Token shall be 615 constructed in one of two ways: 617 Option 1: 619 Request Message:{ 620 CoAP request: request type {GET/POST}, Message ID (MID) 621 Access-Token: Face, [params] 622 MSG_PAYLOAD: [optional encryption] 623 } 625 Option 2: 627 Request Message:{ 628 CoAP request: request type {GET/POST}, Message ID (MID) 629 Access-Token: Face, AuthenticationHash= Hash(verifier+nonce) 630 MSG_PAYLOAD: ChaCha20_Poly1305_AEAD(Verifier,nonce= MID, 631 AAD=null, payload) 632 } 634 In option 2, the AuthenticationHash (AH) contains the hash of the 635 verifier and a nonce, CoAP's MID may be used as the nonce. The AH 636 proves that the client is authenticated by the SAM because the 637 Verifier is a MAC constructed using the shared secret between SAM and 638 RS. 640 4.8. RS->C : Resource-Response 642 When RS receives resource-request from a C of type Option 1, RS 643 validates the request message from C and if the request is valid, RS 644 sends a response message to C. 646 If RS receives an Option 2 resource-request from C, RS checks the 647 following conditions before sending a response to C: 649 o look for an Access-Token in the request message and RS validates 650 if: 652 * Access-Token has valid a AutheticationHash and Face 654 * Access-Token is valid for the Resource Server 656 * Access-Token is valid for the resource (R) 658 * Access-Token has valid TimeStamp and Lifetime or time-to-live 660 * Access-Token covers the request operations 662 Notice that from the request message, RS is able to generate the 663 Verifier and it can validate the AuthenticationHash present in the 664 Resource-Request message. 666 o The RS MUST generate the verifier by computing HMAC(K, Face) 667 where, 669 * K: shared key between SAM and RS; Face is extracted from the 670 Access-Token attached by the C to each request. 672 * The Face is validated by computing Hash(verifier+MID) and 673 comparing it with the AuthenticationHash which is enclosed in 674 the Access-Token 676 If any one of the verification fails, RS responds to C with an 677 Unauthorized resource request or Method not allowed respectively, 678 with SAM-ID (optional). RS will respond to the requested action only 679 when all the above verifications are successful. 681 If the Access-Token is valid, RS prepares a valid response. If 682 request message's payload is encrypted, RS decrypts it using 683 ChaCha20_Poly1305_AEAD(key=verifier,nonce=MID,AAD=null,payload). The 684 response from RS may be encrypted so that only C with a valid key 685 (the Verifier or using derived keys for subsequent messages) can 686 decrypt the payload: 688 Encrypted Response payload:{ 689 CoAP request: request type {GET/POST}, Message ID (MID) 690 RSP_MSG_PAYLOAD: ChaCha20_Poly1305_AEAD (Key=Verifier, 691 nonce = MID++, AAD=null, payload) 692 } 694 Notice the difference in the nonce parameter. The MID is incremented 695 to avoid using the same key for encrypting twice. 697 Figure 5 shows Authorized resource request from C->RS and response 698 message RS->C. 700 ,-. ,--. 701 |C| |RS| 702 `+' `+-' 703 ,--------------------------.| | 704 |Code: POST || | 705 |URI-Path: test || 1 Res-REQ | 706 |token: Face, AuthHash ||----------->| 707 |Payload:{Enc(key=Verifier || | 708 |nonce=MID, AAD=null, || | 709 |payload_data)} || | 710 `--------------------------'| | 711 | | ,-------------------------. 712 | 2 Res-RSP | |Code: Content | 713 |<-----------| |Payload:{Enc(key=Verifier| 714 | | |nonce=MID++, AAD=null, | 715 | | |response_data)} | 716 ,+. ,+-.`-------------------------' 717 |C| |RS| 718 `-' `--' 719 Figure 5: [C<->RS] Authorized Resource Request and Response 721 5. Construction of derived Keys 723 Once C proves to RS that it is authorized to access a resource on RS, 724 RS and C may agree to generate keys based on the initial secret m 725 (Verifier), permissions available on the Face. 727 The main data structure used in this document may be represented as 728 table of values. Each value is a bit string of a fixed size, which 729 we denote m. Initially we choose m = 265 bits, but it is easy to 730 define extensions for other values of m. 732 A Pseudo-Random Generator, commonly used to generate Stream Ciphers 733 can be used as the key-derivation function G. In particular, we 734 propose to use the Pseudo-Random Generator (PRG) of ChaCha20 735 [RFC7539]. In other words, we use ChaCha20 block function as G, by 736 generating an arbitrarily long keystream. The stream cipher ChaCha20 737 takes as input a 256-bit key k, a 64-bit nonce v (unique per key, 738 message pair), and a 64-bit counter or block number. The ChaCha20 739 output stream can therefore be accessed randomly, and any number of 740 blocks can be computed in parallel. 742 It is easy to construct functions for example, G: K x I -> K, and g2, 743 g3, g4: K x I -> K, where K = the key space = {0,1}^265 and I 744 ={0,1,2,..N} where N is an appropriate integer (a parameter of the 745 construction) 747 The Token secrets (keys) thus can be constructed from the initial 748 secret (m) using G. Other functions g1, g2, g3, and g4 will be used 749 to generate the derived keys VerifK, PSK, IntK, and ConfK. 751 We assume that G, g1, g2, g3, and g4 are (or may be) all publicly 752 known functions. That is the security of the protocol SHOULD NOT 753 depend on the secrecy of those functions. 755 One way of using ChaCha20_block() function [RFC7539] is represented 756 in Table 1 where the counter parameter of ChaCha_block() is used as I 757 to generate the derived keys. 759 |-----------------------------+----------------| 760 | ChaCha_block (key=verifier, | Generated Keys | 761 | nonce=CoAP-MID, counter=#) | | 762 |-----------------------------+----------------| 763 | Counter_0 | VerifK | 764 | Counter_1 | PSK | 765 | Counter_2 | IntK | 766 | Counter_3 | ConfK | 767 |-----------------------------+----------------| 768 Table 1: Derived Keys 770 6. References 772 6.1. Normative References 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, March 1997. 777 [RFC7252] Shelby, Z., Hartke, K. and Borman, C., "The Constrained 778 Application Protocol (CoAP)", RFC 7252, June 2014. 780 [RFC6347] Rescorla E. and Modadugu N., "Datagram Transport Layer 781 Security Version 1.2", RFC 6347, January 2012. 783 [RFC4279] Eronen P. and Tschofenig H., "Pre-Shared Key Ciphersuites 784 for Transport Layer Security (TLS)", RFC 4279, December 2005. 786 [RFC7539] Y. Nir and A. Langley: ChaCha20 and Poly1305 for IETF 787 Protocols, RFC7539, May 2015 789 [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. 790 Bormann, "An architecture for authorization in constrained 791 environments", draft-ietf-ace-actors-03 (work in progress), September 792 2016. 794 [I-D.ietf-core-resource-directory] Shelby Z. and Bormann C., "CoRE 795 Resource Directory", draft-ietf-core-resource-directory-07 (work in 796 progress), March 2016. 798 [I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W., 799 Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) 800 Security Architecture", draft-ietf-oauth-pop-architecture-07 (work in 801 progress), December 2015. 803 [draft-ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., 804 Erdtman, S., and H. Tschofenig, "Authorization for the Internet of 805 Things using OAuth 2.0", draft-ietf-ace-oauth-authz-02 (work in 806 progress), December 2016. 808 6.2. Informative References 810 [KoMa2014] Kohnstamm, J. and Madhub, D., "Mauritius Declaration on 811 the Internet of Things", 36th International Conference of Data 812 Protection and Privacy Comissioners, October 2014. 814 7. Acknowledgement 816 This draft is the result of collaborative research in the RERUM EU 817 funded project and has been partly funded by the European Commission 818 (Contract No. 609094). 820 8. Appendix 822 8.1. Copyright Statement 824 Copyright (c) 2015 IETF Trust and the persons identified as authors 825 of the code. All rights reserved. 827 Redistribution and use in source and binary forms, with or without 828 modification, is permitted pursuant to, and subject to the license 829 terms contained in, the Simplified BSD License set forth in 830 Section 4.c of the IETF Trust's Legal Provisions Relating to IETF 831 Documents . 833 Authors' Addresses 834 Jorge Cuellar 835 Siemens AG 836 Otto-Hahn-Ring 6 837 Munich, Germany 81739 839 Email: jorge.cuellar@siemens.com 841 Prabhakaran Kasinathan 842 Siemens AG 843 Otto-Hahn-Ring 6 844 Munich, Germany 81739 846 Email: prabhakaran.kasinathan@siemens.com 848 Daniel Calvo 849 Atos Research and Innovation 850 Poligono Industrial Candina 851 Santander, Spain 39011 853 Email: daniel.calvo@atos.net