ACE Working Group J. Cuellar Internet-Draft P. Kasinathan Intended status: Standards Track Siemens AG Expires: January 1, 2017 D. Calvo Atos Research and Innovation June 30, 2016 Privacy-Enhanced Tokens for Authorization in ACE draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03 Abstract This specification defines PAT, "Privacy-Enhanced-Authorization- Tokens" or "Pseudonym-based Authorization Tokens", a protocol and a token construction procedure for client authorization in a constrained environment. The tokens can be also used to establish a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 1, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Cuellar, et al. Expires January 1, 2017 [Page 1] Internet-Draft PAT for Authorization in ACE 03 June 2016 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Key words to Indicate Requirement Levels . . . . . . . . 3 1.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Actors and Terminology . . . . . . . . . . . . . . . . . 5 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Message Flow Overview . . . . . . . . . . . . . . . . . . 8 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 8 4.1. RS<->SAM : Security-association-Setup . . . . . . . . . . 9 4.2. [C->RS: Resource-Request] . . . . . . . . . . . . . . . . 9 4.3. [RS->C : Un-Authorized-Request(SAM-ID)] . . . . . . . . . 9 4.4. C<->SAM : Security-Association-Setup . . . . . . . . . . 10 4.5. C->SAM: Access-Request . . . . . . . . . . . . . . . . . 11 4.6. C<-SAM: Ticket-Transfer . . . . . . . . . . . . . . . . . 11 4.6.1. Construction of CT . . . . . . . . . . . . . . . . . 12 4.7. C->RS : Resource-Request . . . . . . . . . . . . . . . . 13 4.8. RS->C : Resource-Response . . . . . . . . . . . . . . . . 14 5. Construction of derived Keys . . . . . . . . . . . . . . . . 16 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.2. Informative References . . . . . . . . . . . . . . . . . 18 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 8. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Copyright Statement . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Three well-known problems in constrained environments are the authorization of clients to access resources on servers, the realization of secure communication between nodes, and the preservation of privacy. The reader is referred for instance to [draft-ietf-ace-actors] and [KoMa2014]. The Internet tackles certain aspects of those three problems. It describes a way of constructing Token Material (Key Material) that can be used by clients and servers (or in some cases, more generally by arbitrary nodes) to create secure channels and provide authentication. Moreover, the construction can be used to offer user consent (in the sense of privacy) and to create dynamically Cuellar, et al. Expires January 1, 2017 [Page 2] Internet-Draft PAT for Authorization in ACE 03 June 2016 pseudonyms to enhance the unlinkability of the information, see Subsection "Features" below. This draft uses the same architecture of [draft-ietf-ace-actors], designed to help constrained nodes with authorization-related tasks via less-constrained nodes. PAT supports an implicit authorization mode where no authorization information is exchanged and uses access tokens to implement this architecture. A device that wants to access an item of interest on a constrained node first has to gain permission in the form of a token from the node's Authorization Manager. A main goal of PAT is to securely transmit authorization tokens. A by-product is the setup of a Datagram Transport Layer Security (DTLS) [RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279] between two nodes. Notice that the DTLS channel is not needed to securely transmit the authorization tokens, the authorization tokens may also be exchanged as described in [draft-ietf-ace-oauth-authz] which will be discussed in the future version of the ID. In some cases, relevant in constrained environments, it is also not necessary for a secure transmission of the payload data from server to client. 1.1. Key words to Indicate Requirement Levels The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. In this document, the characters ">>" preceding an indented line(s) indicates a compliance requirement statement using the key words listed above. This convention aids reviewers in quickly identifying or finding the explicit compliance requirements of this RFC 1.2. Features o The method allows a User, or an Authentication/Authorization Manager on its behalf, to authorize one (or several) client(s) to access resources on a server. The client and/or the server can be constrained devices. The authorization is implemented by distributing purpose-built Key Material (which we generically call "Tokens") to the server and clients. This SHOULD be done by secure channels. Cuellar, et al. Expires January 1, 2017 [Page 3] Internet-Draft PAT for Authorization in ACE 03 June 2016 o The Client Tokens are crafted in such a way that the clients can construct authorization tokens that allow them to demonstrate to the server their authorization claims. The message exchange between client and server for the presentation of the tokens MAY be performed via insecure channels. o Further, the purpose-built Key material and tokens can be used for establishing a secret shared key between a client and the server, which can be then used to establish a DTLS communication with pre- shared keys. o The tokens do not provide any information about any associated identities or identifiers of the clients nor of the server. In particular, the method can be used in context where unlinkability (privacy) is a main goal: the tokens convey only the assurance of the authorization claims of the clients. This means that the payloads of our protocol, and in particular, the Authentication Token secrets used, can be constructed in such a way that they not leak information about the correspondence of messages to the same Client. In other words: if an eavesdropper observes the messages from the different Clients to and from the server, the protocol does not give him information about which messages correspond to the same Client. Of course, other information, like the IP-addresses or the contents themselves of the requests/responses may leak some information in this regard, but that is not information leaked by our protocol and can be treated separately. o The tokens may be supported by a "proof-of-possession" (PoP) method. PoP allows an authorized entity (a client) to prove to the verifier (here, the server), that he is indeed the intended authorized owner of the token and not simply the bearer of the token. (Notice that the Authorization Token may be sent in the clear, and thus, it could be stolen by an intruder. A PoP would hinder the attacker to use the token pretending to be authorized). o The Key Material can be used to generate and coordinate pseudonyms between C and RS and potentially further parties. o The user (more precisely, the Resource Owner, RO, see Section "Actors and Terminology" below) is able to decide (if he wishes: in a fine-grained way and in real-time) which client under which circumstances may access his data stored in RS. This can be used to provide consent (in terms of privacy) from users (again, ROs). The PAT protocol has the following features: Cuellar, et al. Expires January 1, 2017 [Page 4] Internet-Draft PAT for Authorization in ACE 03 June 2016 o Simplified authentication on constrained nodes by handing the more sophisticated authentication over to less-constrained devices o Support of secure communication between constrained devices o Authorization policies of the principals of both participating parties are ensured o Simplified authorization mechanism for cases where implicit authorization is sufficient o Using only symmetric encryption on constrained nodes 1.3. Actors and Terminology The actors and terminology are the similar to [I-D.ietf-ace-actors]. Very briefly, for the purposes of this draft, the main actors are: o Resource Server (RS): An endpoint which is a constrained device that hosts and represents a Resource (R). o Client (C): An endpoint that attempts to access a resource on RS. o Server Authorization Manager (SAM): An entity that prepares and endorses authentication and authorization data for a RS. o Client Authorization Manager (CAM): An optional entity that prepares and endorses authentication and authorization data for a C. o Resource Owner (RO): The principal that is in charge of the resource and controls its access permissions. The RO is often the data subject of the protected resource. In addition to the terms defined in [I-D.ietf-ace-actors], we use additionally the following terms: o Client Token (CT): The token which is generated by the SAM for the Client. It contains a secret, which can be used to generate the Access-Token, plus some other data used for PoP. Optionally CT may contain authorization information that represents RO's authorization policies for C. o Access-Token (AT): The token which is generated by the Client and presented by him to the RS. It contains a secret, which changes regularly (in a similar way to one-time passwords). The AT contains all information needed by the RS to verify that it was Cuellar, et al. Expires January 1, 2017 [Page 5] Internet-Draft PAT for Authorization in ACE 03 June 2016 granted by SAM. The Access-Tokens can also be interpreted as Authentication Tokens in this context. Further, C and RS may derive keys from the initial secret: o VerifK: to verify that they are talking with the intended partner, for the Client C it is used as Proof of Possession of the (current) Access-Token o PSK: as Pre-shared Key to establish a DTLS secure channel o IntK: for Integrity protection (in message authentication codes) o ConfK: for Confidentiality Protection (to be elaborated in a future version of the document). 2. System Overview Each Resource Server (RS) has a Server Authorization Manger (SAM) which provides the authentication and authorization for RS. To gain access to a specific resource on a Resource Server RS, a Client (C) requests a token from SAM, either directly or using its CAM. In the following, for simplicity, we avoid Client Authorization Manager's (CAM) role. After SAM receives the request from C, he decides if C is allowed to access the resource or not. If so, SAM generates a Client-Token used for the authorization and for securing the communication between C and RS. For explicit access control, SAM adds the detailed access permissions to the token in a way that C (or his CAM) can interpret and RS can verify as authentically stemming from SAM. Then C presents the Access-Token to RS, demonstrating his authorization, and C and RS can establish a secure channel. 3. Protocol Overview In PAT protocol, the token generation is similar to how Proof of Possession tokens are constructed in [I-D.ietf-oauth-pop- architecture]. In the discussed protocol, three actors RS, C, SAM are involved and it may involve CAM as an intermediary for client authentication but CAM is not taken into consideration in the discussed version of PAT protocol. Notice that in comparison to [I- D.ietf-oauth-pop-architecture], we propose a different method to construct the token for C by SAM, and we introduce methods to resist Denial-of-service (DoS) attacks on the resource constrained server (RS). In Figure 1 we show PAT protocol's interaction between RS, SAM and C. Cuellar, et al. Expires January 1, 2017 [Page 6] Internet-Draft PAT for Authorization in ACE 03 June 2016 +---------+ (B) Access-Request | | +--------------------------------> | | | SAM | | +-----------------------------+ | | | (C) Ticket-Transfer | | | | +---^-----+ | | | | | | | | | +----v+ PAT |(A) Shared-Secret | | PROTOCOL | | C | | | | | +-^---+ | | | | | | (D) Resource+Request +---v---+ | +------------------------------+ | | | RS | +--------------------------------+ | (E) Resource-Response +-------+ Figure 1: PAT protocol The SAM and RS share a long term secret (A). To determine SAM which in charge of a resource hosted at the RS, C MAY send an initial Resource-Request without valid access token to RS. RS denies the request without valid access token and could possibly include the address of its SAM back to C as a response. Or, instead of the initial Resource-Request without valid access token, C MAY look up the desired resource in a resource directory (see [I-D.ietf-core- resource-directory]) that lists the available resources. Once C knows SAM's address, it can send an (B) Access-Request for authorization to SAM (directly, or indirectly using its own CAM). If the access is to be authorized, SAM generates a (C) Ticket-Transfer to C. It contains Key-material for generating all necessary tokens and keys, and, if necessary, a representation of the permissions C has for the resource. Each time C sends RS a (D) Resource-Request, it generates and presents an Access-Token to RS to prove its right to access. If the access-token is valid, RS sends a (E) Resource-Response to the C. Later with the common established secret C and RS can generate derived keys which is described later in the draft. The following section describes the message flow in more detail, especially how the messages, tokens are constructed and how RS and C Cuellar, et al. Expires January 1, 2017 [Page 7] Internet-Draft PAT for Authorization in ACE 03 June 2016 can use their common knowledge to verify the authenticity of the ATs and to derive the shared keys VerifK, PSK, IntK, and ConfK. 3.1. Message Flow Overview In Figure 2, a PAT protocol flow is depicted (messages in square brackets are optional). Notice that the DTLS channel between C and RS is optional in comparison to [I-D.ietf-oauth-pop-architecture]. The resource response from RS to C can be optionally secured by DTLS or by other native PAT methods. ,-. ,--. ,---. |C| |RS| |SAM| `+' `+-' `-+-' | | 1 Security-Association-Setup | | | <--------------------------->| | | | | 2 [Resource-REQ] | | |-----------------------> | | | | |3 [Un-Auth-REQ(SAM-ID)]| | |<----------------------- | | | | | 4 Security-Association-Setup | |<---------------------------------------------------->| | | | | 5 Access-REQ | |----------------------------------------------------->| | | | | 6 Ticket-Transfer | |<-----------------------------------------------------| | | | | 7 Resource-REQ | | |-----------------------> | | | | | 8 Resource-RSP | | |<----------------------- | ,+. ,+-. ,-+-. |C| |RS| |SAM| `-' `--' `---' Figure 2: PAT Protocol message flow 4. Protocol Details As CoAP [RFC7252] is the recommended application layer protocol for constrained devices, the PAT protocol is designed to work with CoAP, wherever necessary appropriate recommendations are made for using CoAP parameters with the proposed protocol. Cuellar, et al. Expires January 1, 2017 [Page 8] Internet-Draft PAT for Authorization in ACE 03 June 2016 The following notation: A->B: represents the message with name Msg_Name, sent from A to B. 4.1. RS<->SAM : Security-association-Setup We assume that the Resource Server RS and its Authentication Manager SAM share a secure channel and share a long term shared secret, i.e., a shared key K, which may be implemented via USB (and physical security) or via DTLS, etc. We do not assume any particular concrete secure channel, but it must be stressed that the security of the protocol strongly depends on how this secure this channel is. We can also assume that the CAM and SAM share a secure connection, say over DTLS if CAM exist as an actor. 4.2. [C->RS: Resource-Request] Initially, C may not have a valid access token to access the resource hosted in RS. Initially, C performs a request (could be a CoAP GET or POST message [RFC7252]) to RS for a resource, given by an URI. The Resource Request message is OPTIONAL . It is assumed that C does not have information about SAM but has information about RS and the resource R it needs to access. RS MUST treat any CoAP request as Unauthorized Resource Request message when any of two following holds: o If the sender does not present a valid access token for the requested resource. o If the sender does not present valid access token for the requested action on the requested resource. 4.3. [RS->C : Un-Authorized-Request(SAM-ID)] Once RS receives a request from a C, it checks the following: o whether C has a valid access ticket. * If not, it may respond to C with an un-authorized request message which contains information about SAM (SAM-ID) which includes additional parameters such as URI and other relevant information to reach SAM. Cuellar, et al. Expires January 1, 2017 [Page 9] Internet-Draft PAT for Authorization in ACE 03 June 2016 * If C has a valid access ticket, but it does not include appropriate rights to perform the requested action (i.e., C may have a valid access ticket to perform a GET() but not POST()), RS responds back with appropriate response (In CoAP, 4.05 Method Not Allowed [RFC7252] is sent as response) Figure 3 shows the sequence of messages with detailed CoAP types between C and RS for the above Unauthorized resource request: ,-. ,--. |C| |RS| `+' `+-' ,--------------------.| | |Code: GET(Code=1) || 1 Res-REQ | |Type: Confirmable ||----------->| |Token: invalid-tkn || | |URI-Path: test || | `--------------------'| | | | ,-------------------------. | | |Code: 4.01 Unauthorized | | 2 Res-RSP | |Type: Acknowledgement | |<-----------| |Token: invalid-tkn | | | |content-type: | | | |application/cbor | | | |Payload:{SAM-ID,params} | ,+. ,+-.`-------------------------' |C| |RS| `-' `--' Figure 3: C<->RS Resource-Request and Unauthorized-Request as response 4.4. C<->SAM : Security-Association-Setup Once C receives SAM-ID which contains the information to reach SAM, C or CAM (if involved) SHOULD establish a secure connection channel. o The SAM may have an access control list for the clients, with that SAM can verify if the client is allowed to establish a secure connection or not. The methods to implement access control in this regard are out of scope of this draft. o If the client has valid access to the resource in RS, then SAM establishes a confidential channel with C. This draft does not specify how this secure connection should be established, it could be a DTLS channel with pre-shared key. Notice that, it is important to ensure that this connection is reliable and secure as the remainder of this protocol lies on the fact that the messages exchanged between C and SAM are protected. Cuellar, et al. Expires January 1, 2017 [Page 10] Internet-Draft PAT for Authorization in ACE 03 June 2016 4.5. C->SAM: Access-Request Once C establishes a secure communication channel with SAM, C sends an access request message to SAM. The C includes the details about the resources (R) and operations it needs to access / perform on RS to SAM as part of the Access-Request Message. This depends on the infrastructure or services the RS offers. For example, if RS exposes resources such as temperature and humidity, a generic token may be granted by SAM to C to access both resources on RS. On the other hand, the application developer or administrator may decide to have fine grained (different) tokens for temperature and humidity. 4.6. C<-SAM: Ticket-Transfer When SAM receives an access-request from a C, it validates the access-request message. If the access request from C is valid, SAM creates and sends the Client-Token CT for C through a Ticket-Transfer message. The Figure 4 shows the Access request message from C to SAM and the consequent Ticket Transfer as a response from SAM to C. Cuellar, et al. Expires January 1, 2017 [Page 11] Internet-Draft PAT for Authorization in ACE 03 June 2016 ,-. ,---. |C| |SAM| `+' `-+-' | | | ======== | ================================= DTLS ============================== | ======== | | | ,--------------------------.| | |Code:POST || 1 Access-REQ | |Content-Format:CBOR ||----------------->| |URI-Path: authorize || | |Payload:{RES,Operations} || | `--------------------------'| | | | ,------------------. |2 Ticket-Transfer | |Code:Content | |<-----------------| |content-type: | | | |application/cbor | | | |Payload:{CT} | | | `------------------' | | | ======== | ================================= DTLS ============================== | ======== | ,+. ,-+-. |C| |SAM| `-' `---' Figure 4: Access-Request and Ticket-Transfer 4.6.1. Construction of CT This sub-section describes how SAM generates the CT for C. SAM uses PoP token method to construct CT and it is constructed using HMAC algorithm instead of encryption as described in [I-D.ietf-oauth-pop- architecture]. The CT includes a Face, a Verifier and some additional information which isblazer described in detail below: A Face is constructed as the following: o Face: SAI, timestamp, time-to-live, random * Server Authorization Information (SAI): It contains the resource server URI with the allowed permissions. * timestamp: It contains the timestamp information * time-to-live: (or lifetime ) It is used to limit the validity of the access tickets [optional] Cuellar, et al. Expires January 1, 2017 [Page 12] Internet-Draft PAT for Authorization in ACE 03 June 2016 * random: random seed on the token such that we make Face non- deterministic, this random number can be generated by any Pseudo-Random-Generator The Face can be optionally encoded in CBOR format. Note that the time-synchronization between SAM and RS may be implemented based on the application requirements is out of scope of this draft. o Verifier: G (K, Face) Notice that G takes two parameters (key, data) as input and produced a keyed digest as the output * G: the HMAC algorithm which is used to create the verifier, we propose Poly1305 [RFC7539] * K: the shared key between SAM and RS * Face: it is obtained from the previous step o Client-Token: Face, Verifier, Additional_Information * Face: what we obtained from first step * Verifier: what we obtained from previous step * Additional-Information: it may contain information about cryptographic algorithms such as AEAD, Hash and HMAC. Notice that the Ticket transfer message and the verifier MUST be sent to C through a secure channel. The client will use the Verifier as the key material to communicate with the Resource Server. 4.7. C->RS : Resource-Request When C receives the ticket-transfer from SAM, C can construct a valid Access-Token, AT, which will demonstrate his authorization to RS that he may access the resources he is requesting. Regularly, the message Resource-Req with new AT has to be sent afresh: Client C has to renew his Authorization status at the Resource Server. The frequency in which the Client has to send a new AT can be enforced by RS and is determined indirectly by the owner of RS (or by SAM). This allows a fine-grained control on the service level that the Resource Server will provide to the Client (for instance, on the amount of information of sensor data). Each time a Resource-Req is sent, a new Access-Token MAY be needed. Optionally, communications between C and RS can be encrypted using a part of the access ticket to enforce confidentiality if necessary. Cuellar, et al. Expires January 1, 2017 [Page 13] Internet-Draft PAT for Authorization in ACE 03 June 2016 o For example if C performs: * a CoAP GET() request, C does not have any payload therefore no need for encryption * a CoAP POST() request with payload, C may create a authorized resource request message by encrypting the "payload" using an algorithm described in Face's Additional-Information. We propose ChaCha20-Poly1305-AEAD authenticated encryption mechanism, while using the Verifier as the key and CoAP-MID as the nonce The Resource-Request message with valid Access-Token shall be constructed in one of two ways: Option 1: Request Message:{ CoAP request: request type {GET/POST}, Message ID (MID) Access-Token: Face, [params] MSG_PAYLOAD: [optional encryption] } Option 2: Request Message:{ CoAP request: request type {GET/POST}, Message ID (MID) Access-Token: Face, AuthenticationHash= Hash(verifier+nonce) MSG_PAYLOAD: ChaCha20_Poly1305_AEAD(Verifier,nonce= MID, AAD=null, payload) } In option 2, the AuthenticationHash (AH) contains the hash of the verifier and a nonce, CoAP's MID may be used as the nonce. The AH proves that the client is authenticated by the SAM because the Verifier is a MAC constructed using the shared secret between SAM and RS. 4.8. RS->C : Resource-Response When RS receives resource-request from a C of type Option 1, RS validates the request message from C and if the request is valid, RS sends a response message to C. If RS receives an Option 2 resource-request from C, RS checks the following conditions before sending a response to C: Cuellar, et al. Expires January 1, 2017 [Page 14] Internet-Draft PAT for Authorization in ACE 03 June 2016 o look for an Access-Token in the request message and RS validates if: * Access-Token has valid a AutheticationHash and Face * Access-Token is valid for the Resource Server * Access-Token is valid for the resource (R) * Access-Token has valid TimeStamp and Lifetime or time-to-live * Access-Token covers the request operations Notice that from the request message, RS is able to generate the Verifier and it can validate the AuthenticationHash present in the Resource-Request message. o The RS MUST generate the verifier by computing HMAC(K, Face) where, * K: shared key between SAM and RS; Face is extracted from the Access-Token attached by the C to each request. * The Face is validated by computing Hash(verifier+MID) and comparing it with the AuthenticationHash which is enclosed in the Access-Token If any one of the verification fails, RS responds to C with an Unauthorized resource request or Method not allowed respectively, with SAM-ID (optional). RS will respond to the requested action only when all the above verifications are successful. If the Access-Token is valid, RS prepares a valid response. If request message's payload is encrypted, RS decrypts it using ChaCha20_Poly1305_AEAD(key=verifier,nonce=MID,AAD=null,payload). The response from RS may be encrypted so that only C with a valid key (the Verifier or using derived keys for subsequent messages) can decrypt the payload: Encrypted Response payload:{ CoAP request: request type {GET/POST}, Message ID (MID) RSP_MSG_PAYLOAD: ChaCha20_Poly1305_AEAD (Key=Verifier, nonce = MID++, AAD=null, payload) } Notice the difference in the nonce parameter. The MID is incremented to avoid using the same key for encrypting twice. Cuellar, et al. Expires January 1, 2017 [Page 15] Internet-Draft PAT for Authorization in ACE 03 June 2016 Figure 5 shows Authorized resource request from C->RS and response message RS->C. ,-. ,--. |C| |RS| `+' `+-' ,--------------------------.| | |Code: POST || | |URI-Path: test || 1 Res-REQ | |token: Face, AuthHash ||----------->| |Payload:{Enc(key=Verifier || | |nonce=MID, AAD=null, || | |payload_data)} || | `--------------------------'| | | | ,-------------------------. | 2 Res-RSP | |Code: Content | |<-----------| |Payload:{Enc(key=Verifier| | | |nonce=MID++, AAD=null, | | | |response_data)} | ,+. ,+-.`-------------------------' |C| |RS| `-' `--' Figure 5: [C<->RS] Authorized Resource Request and Response 5. Construction of derived Keys Once C proves to RS that it is authorized to access a resource on RS, RS and C may agree to generate keys based on the initial secret m (Verifier), permissions available on the Face. The main data structure used in this document may be represented as table of values. Each value is a bit string of a fixed size, which we denote m. Initially we choose m = 265 bits, but it is easy to define extensions for other values of m. A Pseudo-Random Generator, commonly used to generate Stream Ciphers can be used as the key-derivation function G. In particular, we propose to use the Pseudo-Random Generator (PRG) of ChaCha20 [RFC7539]. In other words, we use ChaCha20 block function as G, by generating an arbitrarily long keystream. The stream cipher ChaCha20 takes as input a 256-bit key k, a 64-bit nonce v (unique per key, message pair), and a 64-bit counter or block number. The ChaCha20 output stream can therefore be accessed randomly, and any number of blocks can be computed in parallel. It is easy to construct functions for example, G: K x I -> K, and g2, g3, g4: K x I -> K, where K = the key space = {0,1}^265 and I Cuellar, et al. Expires January 1, 2017 [Page 16] Internet-Draft PAT for Authorization in ACE 03 June 2016 ={0,1,2,..N} where N is an appropriate integer (a parameter of the construction) The Token secrets (keys) thus can be constructed from the initial secret (m) using G. Other functions g1, g2, g3, and g4 will be used to generate the derived keys VerifK, PSK, IntK, and ConfK. We assume that G, g1, g2, g3, and g4 are (or may be) all publicly known functions. That is the security of the protocol SHOULD NOT depend on the secrecy of those functions. One way of using ChaCha20_block() function [RFC7539] is represented in Table 1 where the counter parameter of ChaCha_block() is used as I to generate the derived keys. |-----------------------------+----------------| | ChaCha_block (key=verifier, | Generated Keys | | nonce=CoAP-MID, counter=#) | | |-----------------------------+----------------| | Counter_0 | VerifK | | Counter_1 | PSK | | Counter_2 | IntK | | Counter_3 | ConfK | |-----------------------------+----------------| Table 1: Derived Keys 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7252] Shelby, Z., Hartke, K. and Borman, C., "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC6347] Rescorla E. and Modadugu N., "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC4279] Eronen P. and Tschofenig H., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC7539] Y. Nir and A. Langley: ChaCha20 and Poly1305 for IETF Protocols, RFC7539, May 2015 [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained Cuellar, et al. Expires January 1, 2017 [Page 17] Internet-Draft PAT for Authorization in ACE 03 June 2016 environments", draft-ietf-ace-actors-03 (work in progress), September 2016. [I-D.ietf-core-resource-directory] Shelby Z. and Bormann C., "CoRE Resource Directory", draft-ietf-core-resource-directory-07 (work in progress), March 2016. [I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", draft-ietf-oauth-pop-architecture-07 (work in progress), December 2015. [draft-ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authorization for the Internet of Things using OAuth 2.0", draft-ietf-ace-oauth-authz-02 (work in progress), December 2016. 6.2. Informative References [KoMa2014] Kohnstamm, J. and Madhub, D., "Mauritius Declaration on the Internet of Things", 36th International Conference of Data Protection and Privacy Comissioners, October 2014. 7. Acknowledgement This draft is the result of collaborative research in the RERUM EU funded project and has been partly funded by the European Commission (Contract No. 609094). 8. Appendix 8.1. Copyright Statement Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents . Authors' Addresses Cuellar, et al. Expires January 1, 2017 [Page 18] Internet-Draft PAT for Authorization in ACE 03 June 2016 Jorge Cuellar Siemens AG Otto-Hahn-Ring 6 Munich, Germany 81739 Email: jorge.cuellar@siemens.com Prabhakaran Kasinathan Siemens AG Otto-Hahn-Ring 6 Munich, Germany 81739 Email: prabhakaran.kasinathan@siemens.com Daniel Calvo Atos Research and Innovation Poligono Industrial Candina Santander, Spain 39011 Email: daniel.calvo@atos.net Cuellar, et al. Expires January 1, 2017 [Page 19]