Authentication and Authorization for Constrained Environments Internet-Draft J. Cuellar Intended status: Informational P. Kasinathan Expires: October 21, 2016 Siemens AG D. Calvo Atos Research and Innovation April 19, 2016 Privacy-Enhanced Tokens for Authorization in ACE draft-cuellar-ace-pat-priv-enhanced-authz-tokens-02 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 October 21, 2016. 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 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. Cuellar, et al. Expires October 21, 2016 [Page 1] Internet-Draft PAT for Authorization in ACE 02 April 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Key words to Indicate Requirement Levels . . . . . . . . 3 1.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Actors and Terminology . . . . . . . . . . . . . . . . . 5 2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Message Flow Overview . . . . . . . . . . . . . . . . . . 8 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10 4.1. [C --> S: Unauthorized Resource Request: request_params] 10 4.2. [S --> SAM: Token Request] . . . . . . . . . . . . . . . 10 4.3. [SAM --> S: Token Response: ST = (St, paramS)] . . . . . 11 4.4. [S --> C: SAM Information: SAM-ID] . . . . . . . . . . . 11 4.5. C --> CAM: Access Request . . . . . . . . . . . . . . . . 11 4.6. CAM --> SAM: Ticket Request . . . . . . . . . . . . . . . 11 4.7. SAM --> CAM: Ticket Grant . . . . . . . . . . . . . . . . 11 4.8. CAM --> C: Ticket Transfer . . . . . . . . . . . . . . . 12 4.9. CAM --> C: Client Authorization Information (CAI) . . . . 12 4.10. C <==> S: Security Association . . . . . . . . . . . . . 12 4.11. C --> S: Authorized Resource Req.: AT = (At, param),[params] . . . . . . . . . . . . . . . . . . . . . 12 4.12. S --> C: Resource Response . . . . . . . . . . . . . . . 12 4.13. Construction of the Tokens . . . . . . . . . . . . . . . 12 4.14. Main data structure . . . . . . . . . . . . . . . . . . . 13 4.14.1. Traversing the Tree . . . . . . . . . . . . . . . . 14 4.15. Construction of St, Ct and At . . . . . . . . . . . . . . 15 5. Alternative Protocol . . . . . . . . . . . . . . . . . . . . 16 5.1. Alternative Message Flow . . . . . . . . . . . . . . . . 16 6. Alternative Protocol Details . . . . . . . . . . . . . . . . 17 6.1. Shared Key (K) between SAM and S . . . . . . . . . . . . 17 6.2. [C->S]: Resource Request without valid access token . . . 18 6.3. [S->C]: Unauthorized Request, SAI . . . . . . . . . . . . 18 6.4. [C<->SAM]: Security Association Set-up . . . . . . . . . 19 6.5. [C->SAM]: Access Request Message . . . . . . . . . . . . 19 6.6. [C<-SAM]: Ticket Transfer Message . . . . . . . . . . . . 19 6.6.1. Construction of Token and Ticket Transfer Message . . 20 6.7. [C->S] Authorized Resource Request . . . . . . . . . . . 22 6.8. [S->C] Valid Response . . . . . . . . . . . . . . . . . . 22 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . 25 12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 13. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Cuellar, et al. Expires October 21, 2016 [Page 2] Internet-Draft PAT for Authorization in ACE 02 April 2016 13.1. Copyright Statement . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction Three well-known problems in constrained environments are the authorization of clients to access resource on servers, the realization of secure communication between nodes, and the preservation of privacy. The reader is referred for instance to [I- D.gerdes-ace-dcaf-authorize] and [I-D.gerdes-ace-actors], and [KoMa2014]. This draft 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, provide authentication, in a context similar to ACE-DCAF Tickets. Moreover, the construction can be used to offer user consent (in the sense of privacy) and to create dynamically pseudonyms to enhance the unlinkability of the information, see Subsection "Features" below. This draft uses the same architecture of [I-D.gerdes-ace-actors], designed to help constrained nodes with authorization-related tasks via less-constrained nodes. As in DCAF, 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. 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. Cuellar, et al. Expires October 21, 2016 [Page 3] Internet-Draft PAT for Authorization in ACE 02 April 2016 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. 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 Cuellar, et al. Expires October 21, 2016 [Page 4] Internet-Draft PAT for Authorization in ACE 02 April 2016 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 S 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 S. This can be used to provide consent (in terms of privacy) from users (again, ROs). As DCAF, it has the following features: 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 same as in DCAF. Very briefly, for the purposes of this draft, the main actors are: Server (S): An endpoint that hosts and represents a CoAP (see [RFC7252]) resource. Client (C): An endpoint that attempts to access a CoAP resource on the Server. Server Authorization Manager (SAM): An entity that prepares and endorses authentication and authorization data for a Server. Client Authorization Manager (CAM): An entity that prepares and endorses authentication and authorization data for a Client. 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 order to avoid confusions, instead of redefining the terms of DCAF, we use additionally the following terms: Server Token (ST): The token which is generated by the SAM for the Server. Besides parameters, which may contain authorization Cuellar, et al. Expires October 21, 2016 [Page 5] Internet-Draft PAT for Authorization in ACE 02 April 2016 information that represents RO's authorization policies for C, it contains a secret, St, called the ST-secret. This one can be used to verify the Authorization Token and to generate other secrets to be discussed later. Client Token (CT): The token which is generated by the SAM for the Client. It contains a secret, Ct, which can be used to generate the Authorization Token, pus some other data used for PoP. Optionally CT may contain authorization information that represents RO's authorization policies for C. Authorization Token (AT): The token which is generated by the Client and presented by him to the Server. It contains a secret AT, which changes regularly (in a similar way to one-time passwords). The AT contains all information needed by the Server to verify that it was granted by SAM. VerifK, PSK, IntK, ConfK: Derived keys between C and S used respectively: o to verify that they are talking with the intended partner, for the Client C it is used as Proof of Possession of the (current) Authorization Token o as Pre-shared Key to establish a DTLS secure channel o for Integrity protection (in message authentication codes) o for Confidentiality Protection (to be elaborated in a future version of the document). 2. System Overview As in DCAF, each Server (S) has a Server Authorization Manger (SAM) which conducts the authentication and authorization for S. S and SAM are assumed to have a secure channel, probably a DTLS channel, but the current specification does not assume anything about it, except that it is two way secure, preserving integrity and confidentiality. Using this secure communication channel SAM provides to S the main secret x which is used within the initial version of the Server Token (ST). Thus ST = (St, paramS), where St is a "main secret" created by SAM (in a way that is outside of the scope of this draft), and paramS is a set of parameters, determining the functions G, g1, g2, g3, g4, etc. to be discussed later and, optionally, the authorization policies for the clients foreseen. To gain access to a specific resource on a Server S, a Client (C) requests a token from the SAM, either directly or using its CAM. In Cuellar, et al. Expires October 21, 2016 [Page 6] Internet-Draft PAT for Authorization in ACE 02 April 2016 the following, for simplicity, we only discuss the collocated CAM-C role; the separation of the roles should be clear to the reader (and will be detailed in subsequent versions of the ID). After SAM receives the request from C, he decides if C is allowed to access the resource. If so, it generates a Client-Id and a corresponding Client-Token used for the authorization and for securing the communication between C and S. For explicit access control, SAM adds the detailed access permissions to the token in a way that C (or his CAM) can interpret and S can verify as authentically stemming from SAM. Then C presents the Authorization Token to S, demonstrating his authorization, and C and S can establish a secure channel. As in DCAF, an Authorization Manager has to fulfill several requirements regarding enough storage, use interaction and processing power, see [I-D.gerdes-ace-a2a]. 3. Protocol Overview The PAT protocol is an instantiation of the generic ace-solution protocol presented in [I-D.cuellar-ace-solutions]. It comprises the following steps: 0) Security Context Setup Between CAM and SAM 1) Unauthorized Resource Request Message 2) Token Request Message 3) Token Response 4) SAM Information Message 5) Access Request Message 6) Ticket Request Message 7) Ticket Grant Message 8) Ticket Transfer Message 9) Client Authorization Information Message 10) Security Association between C and S 11) Authorized Resource Request Message 12) Resource Response Message PAT instantiates in particular the payload of messages (3), (7), (8) and (11). The main exchanges can be presented as in Fig. 1: 1. Transfer of ST = (St, paramS) form SAM to S. Cuellar, et al. Expires October 21, 2016 [Page 7] Internet-Draft PAT for Authorization in ACE 02 April 2016 This corresponds to the message (3) Token Response of [I-D.cuellar- ace-solutions] 1. The Client Token (CT) grant from SAM to C. This is the composition of messages (7) and (8). 2. Access Requests with their respective Authorization Tokens (AT) between C and S. _SAM _/ | (7) Ticket Grant Msg _/ | (8) Ticket Transfer Msg _/ | (3) Token Response _/ | CT = (Ct, paramC) _/ | ST = (St, paramS) _/ | / | v v C ------------> S (11) Authorized Resource Request Msg At1, At2,..., Atn Figure 1: The 3 main parts of the Protocol There are 3 main Tokens: ST, CT and AT, each of the form (nonce, param), where the nonce is St, Ct, and At, resp., and param = paramC/paramS/paramT is some additional information. (ParamT is not shown in the Figure, for readability). 3.1. Message Flow Overview In Figure 2, a PAT protocol flow is depicted (messages in square brackets are optional). Notice that in comparison to DCAF, rows 07 and 08 are in different order and the DTLS channel between C and S is optional. The resource response (09) can be optionally secured by DTLS or by other native PAT methods: Cuellar, et al. Expires October 21, 2016 [Page 8] Internet-Draft PAT for Authorization in ACE 02 April 2016 C CAM S SAM | | | | | |<=============== (0) Security Context Setup ===============>| | | | | |[---- (1) Unauth Resource Req ---->]| | | | | | | | |[---- (2) Token Request --->]| | | | | | | |<---- (3) Token Response --> | | | | | | [<---- (4) SAM Information -------]| | | | | | |-(5)>| | | | | | | | |----------------- (6) Ticket Request ---------------------->| | | | | | |<---------------- (7) Ticket Grant -----------------------| | | | | |<(8)-| | | | | | | |<(9)-| | | | | | | |[<==(10) Security Association ====>]| | | | | | |--- (11) Authorized Resource Req -->| | | | | | |<-- (12) Resource Response ---------| | Figure 1: Protocol Overview As in DCAF, to determine the SAM in charge of a resource hosted at the S, C MAY send an initial Unauthorized Resource Request message to S. S then denies the request and sends the address of its SAM back to C. Or, instead of the initial Unauthorized Resource Request message, C MAY look up the desired resource in a resource directory (cf. [I-D.ietf-core-resource-directory]) that lists the available resources. Once C knows SAM's address, it can send a request for authorization to SAM (directly, as in Fig. 1 or indirectly using its own CAM). If the access is to be authorized, SAM generates a Client Token (CT) for C. It contains keying 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 S a Resource Request, it generates and presents a (current) Authorization Token to S to prove its right to access. Cuellar, et al. Expires October 21, 2016 [Page 9] Internet-Draft PAT for Authorization in ACE 02 April 2016 With their common knowledge in St and Ct, C and S are able to establish a secure channel. The following sections specify the message flows in more detail, how the token secrets St, Ct and At are constructed, how the tokens can be revoked, and how S and C can use their common knowledge to verify the authenticity of the ATs and to obtain a the shared keys VerifK, PSK, IntK, and ConfK. 4. Protocol Details In the following descriptions the notation A --> B : payload represents the message with name Msg_Name, sent from A to B and with the given payload. We assume that the Server S and its Authentication Manager SAM share a secure channel, 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 security is designed and implemented. We also assume that the CAM nand the SAM share a secure connection, say over DTLS. 4.1. [C --> S: Unauthorized Resource Request: request_params] The optional Unauthorized Resource Request message is a request for a resource hosted by S for which no proper authorization is granted. S MUST treat any CoAP request as Unauthorized Resource Request message when any of two following holds: o S has no valid access token for the sender of the request regarding the requested resource. o S has a valid access token for the sender of the request, but this does not allow the requested action on the requested resource. 4.2. [S --> SAM: Token Request] Optionally, the server may ask for server tokens to the SAM. Cuellar, et al. Expires October 21, 2016 [Page 10] Internet-Draft PAT for Authorization in ACE 02 April 2016 4.3. [SAM --> S: Token Response: ST = (St, paramS)] The owner of the server determines a number N which is (probably) an upper bound on the number of Clients that the Server will simultaneously serve. This number N should not be too high, as the storage and computation effort of the server will increase (linearly) with N. (But the owner may decide any time later to increase or decrease the number N if necessary). Using the secure channel, SAM sends to S the initial value of ST = (St, paramS), where St is a (preferably, random) number that can't be guessed by an attacker, and paramS is a set of parameters that encode the number N, the choice of functions G, g1, g2, g3, g4, and the permissions Client Nr "i" has (for each Client i, or for a set of them). The permissions may remain undefined or incomplete and can be extended or modified later anytime. They may also contain validity periods or other restrictions in the Service Level Agreement. At any later point in time the SAM may change ST, or a part of it: send a new value for St, or change or extend the permissions or change N, the number of expected Clients. 4.4. [S --> C: SAM Information: SAM-ID] As in DCAF, the Server CAN instruct the Client about which SAM to contact. 4.5. C --> CAM: Access Request The Client contacts directly or indirectly via the CAM the SAM of his desired Server S, expressing the set of permissions it requests to the resources of the Server S. 4.6. CAM --> SAM: Ticket Request The Client contacts directly or indirectly via the CAM the SAM of his desired Server S, expressing the set of permissions it requests to the resources of the Server S. 4.7. SAM --> CAM: Ticket Grant SAM decides which Client Number "i" the Client C should have. Each Client will have a different number. The number "i" is an integer between 1 and N, the number of Clients. The choice of value for "i" will depend on which permissions the owner has foreseen and, more importantly, the SAM has encoded as parameters sent to S. In this message the Client Token CT and the number i are sent. Optionally, SAM can encode the permissions in this message in a way that the Cuellar, et al. Expires October 21, 2016 [Page 11] Internet-Draft PAT for Authorization in ACE 02 April 2016 Server S can verify the authenticity of the permission. (Details will be given in a later version of the draft). 4.8. CAM --> C: Ticket Transfer The CAM forwards the Client Token to the client C. 4.9. CAM --> C: Client Authorization Information (CAI) The CAM may restrict the operations C performs on S by transferring Client Authentication Information (CAI) to C. 4.10. C <==> S: Security Association Optionally, a DTLS channel is constructed using pre-shared key constructed from the common information held by C and S. 4.11. C --> S: Authorized Resource Req.: AT = (At, param),[params] In possession of the Client Token, CT, the Client can construct valid Authorization Tokens, AT, which demonstrates his authorization to access the resources he is requesting. Regularly, the message Resource_Req has to be sent afresh and a new AT must be used: Client C has to renew his Authorization status at the Server. The frequency in which the Client has to send a new AT can be enforced by C and is determined indirectly the owner of S (or by SAM). This allows a fine-grained control on the service level that the Server will provide to the Client (for instance, on the amount of information of sensor data). We assume that the frequency of renewal is the same for all Clients, but each Client has a different number of Authorization Tokens it can construct. Each time a new Resource_Req is sent, a new Authorization Token MAY be needed. 4.12. S --> C: Resource Response The server answers the request of the server, as stipulated by the service description. This message can be sent over the secure channel between C and S (established as described above), or can be secured directly, as discussed below. 4.13. Construction of the Tokens The main data structure used in this document may be represented as a tree 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. This data structure may be implemented in several different ways, for instance as a set of tables representing the currently relevant parts of the tree. Cuellar, et al. Expires October 21, 2016 [Page 12] Internet-Draft PAT for Authorization in ACE 02 April 2016 The tree is constructed based on a "root secret" which we denote by "x") and a Pseudo-Random Generator, commonly used to generate Stream Ciphers. In particular, we propose to use the Pseudo-Random Generator (PRG) of ChaCha20 [RFC7539]. In other words, we use ChaCha20 block function as a key-derivation function, by generating an arbitrarily long keystream. The stream cipher ChaCha20 takes as input a 256-bit key k, a 64-bit nonce v (unique message number), and a 64-bit block number. The ChaCha20 output stream can therefore be accessed randomly, and any number of blocks can be computed in parallel. Instead of ChaCha20, other PRG can be used as well, or even hash functions. With any of those building blocks, it is easy to construct functions G: K x I -> K, and g2, g3, g4: K x I -> K, where K = the key space = {0,1}^265 and I ={0,1,2,..N} where N is an appropriate integer (a parameter of the construction). Starting from a secret x, a tree of derived secrets (we use the words keys and secrets indiscriminately) is constructed. The main property of the secrets in the tree is that an attacker can't use the information of a secret to obtain information about other secrets in the tree except descendents. (The knowledge of secrets on the tree reveals nothing about any secret that is not a descendent of any of them). The children of any node are constructed using a function G ("generator") that takes a key k (of size m = 256 bits) and an index i (the "block number") and creates a new key of size m =256 bits. The Token secrets St, Ct and At are all values in the tree and thus can be constructed from x 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. 4.14. Main data structure The main data structure used in this document may be viewed abstractly as a tree of values. Each value is a bit string of a fixed size m (= 256 bits). But this data structure may be implemented in several different ways, for instance as a set of tables representing the currently relevant parts of the tree. We use a sequence of integer numbers as indexes for the nodes (values) in the tree. To avoid parentheses, commas, and semicolons Cuellar, et al. Expires October 21, 2016 [Page 13] Internet-Draft PAT for Authorization in ACE 02 April 2016 we write for instance: "123" for the sequence of 3 numbers "1", "2", and "3". In what follows, in all our examples of integer sequences, we will not use numbers that require 2 or more digits (that is, numbers > 9). The sequences of integers are used to index values in a tree: x_a is the value at the node with position (address) a. In other words, the nodes (and their values) are denoted as x_a, where a is a sequence of integer numbers. The tree has a root x (x_a where a = epsilon is the empty sequence). The children of x are x_1, x_2, x_3, ..., x_N, where k = 1..N is a singleton list, that is a list with only one number. If x_a is a node in the tree, then the children of x_a all have the form x_a', where a'=a;i is a the concatenation of a and an integer i. The value x_a'= x_a; i=x_(a;i) is calculated as G(x_a,i). In the case of a hash h: x_a' = x_a;i = h(f(x_a, i)). Where f is a fixed (publicly known) function such that for any fixed i the function f(.,i) is 1-1. The choice of G should not be regarded a secret: it is a publicly known parameter of the installation for S. It follows that if an entity knows x_a, the entity is able to calculate all descendants of it, that is, all nodes in the subtree with root x_a. But not vice-versa: since h is a one-way function, the knowledge of x_a;i is not enough to calculate x_a. Note: "x_a" is read as "x sub a" or "x subindex a". "a" is called the index or address of the node. Note: Since we also use concatenation of bit strings we need to use parenthesis in that case: x_a;i means x_(a;i), while (x_a);bs means the concatenation of the bit strings (x_a) and bs. 4.14.1. Traversing the Tree Now we describe a simple procedure for traversing part of the tree, which we now assume of a fixed degree. That is, each node of the tree has either no children or has exactly this amount of children. Assume that we have a certain "current parent node" x_a and a "current node", a child of x_a, which may be written as x_a;i. Thus, i is an index (an integer). For example: the fifth child of x_a is x_a;i, with i = "5". Traversing the tree with respect to the current parent node x_a, starting at x_a; i gives the following sequence of nodes (loop): - If x_a; i is the right-most child of x_a, stop here. - If x_a;(i+1) is the right-most child of x_a, then move to its first child (if it Cuellar, et al. Expires October 21, 2016 [Page 14] Internet-Draft PAT for Authorization in ACE 02 April 2016 exists): x_a;(i+1);1. If x_a;(i'+1) has no children, stop. - If x_a;(i'+1) is not right-most child of x_a, then move to it. 4.15. Construction of St, Ct and At The secret "x" is the "main secret". It is generated by the SAM as a random or pseudo-random number of m bits (m is taken to be 256). The method used to construct x is out of our scope, but it should be practically impossible to guess by an attacker, even if he knows in plaintext a sequence of previous or future choices of x. Initially, St = x St is sent by the SAM to the Server S in the message Server_Token_Transfer. The value of St at the Server may change if the current value of St is revoked by the SAM. For this, it is not necessary to send a new Server_Token_Transfer. (Details in a future version of the I.D). The root has N children, one for each foreseen Client. The value x_i, for i=1..N is a secret associated to Client number i, but it is not known by the Client. The values x, x_1, x_2, .., x_N are secrets that never leave the SAM or the Server S and should not be leaked. The first children of x_1, x_2, .., x_N are the initial values of CT. In other words, for Client number i: Initially, Ct = x_i1 Ct is sent by the SAM to C(i), the Client number i, in the message Client_Token_Grant. Also in this message, the SAM sends the "current node" (used by C to start a traversal), the depth and the degree of the sub-tree at the node Ct. The value of Ct at the Server may change if the current value of Ct is revoked by the SAM. If this happens, it is necessary for the Client to obtain a new Client_Token_Grant. (Details in a future version of the I.D). To create the sequence of Authentication Token secrets, At1, At2, ..., the Client traverses the tree starting at a "current node" (determined by the SAM in the parameters of the Client_Token_Grant message) with the current parent node being the current value of Ct. Cuellar, et al. Expires October 21, 2016 [Page 15] Internet-Draft PAT for Authorization in ACE 02 April 2016 5. Alternative Protocol This section briefly describes an alternative of the PAT protocol. The following method is similar to how Proof of Possession tokens are constructed in [I-D.ietf-oauth-pop-architecture]. The client(C), Server(S) and Server Authentication Manager (SAM) are the three actors involved in the following description. It may or may not involve Client Authentication Manager (CAM) as an intermediary for C authentication. Notice that in comparison to [I-D.ietf-oauth-pop- architecture] we propose to use a different way to construct the token for C by SAM. 5.1. Alternative Message Flow In Figure 3, we show the alternative PAT protocol message flow. Initially, the S and the SAM shares a long term secret key K. The key K is used by the S in the later stages to validate the tokens from C. Also, it is required to have a confidential channel between C and SAM and it could be DTLS. Notice that in comparison to [I- D.ietf-oauth-pop-architecture] it is not mandatory to have a confidential channel between C and S. Cuellar, et al. Expires October 21, 2016 [Page 16] Internet-Draft PAT for Authorization in ACE 02 April 2016 ,-. ,-. ,---. |C| |S|<==0(K)==>|SAM| `+' `+' `-+-' |1 Un-Auth Resource REQ | | |----------------------->| | | | | | 2 Un-auth REQ + SAI | | |<-----------------------| | | | | | 3 DTLS handshake | |<------------------------------------>| | | | | 4 Access REQ MSG | |------------------------------------->| | | | | 5 Ticket transfer MSG [F,V] | |<-------------------------------------| | | | |6 Auth resource REQ MSG | | |----------------------->| | | | | | 7 Resource RSP | | |<-----------------------| | ,+. ,+. ,-+-. |C| |S| |SAM| `-' `-' `---' Figure 3: Alternative Protocol message flow 6. Alternative Protocol Details 6.1. Shared Key (K) between SAM and S The SAM and S share a long term shared secret, i.e., a shared key K. The key K MAY be associated betweeyn the entities during the device set-up phase or through other key-exchange mechanisms, but it is assumed that none other than SAM and S knows the secret K. TODO: Is it good to mention the following? o The key exchange mechanism SHOULD be efficient o The S SHOULD have the capability to update the K in future, if K is compromised or becomes invalid. Cuellar, et al. Expires October 21, 2016 [Page 17] Internet-Draft PAT for Authorization in ACE 02 April 2016 6.2. [C->S]: Resource Request without valid access token It is assumed that the C does not have information about SAM, therefore it does not have valid access token to access the resource from S. But we assume that the C has the information about the resource server and the resource it needs to access. Initially, the C performs a request (could be a CoAP GET or POST message) to the resource server S for a resource, given by an URI. 6.3. [S->C]: Unauthorized Request, SAI Once the S receives a request from a C, it checks the following: o whether the C has valid access ticket. * If not, it replies back with un-authorized request message together with the SAM information message (SAI) with additional parameters such as URI, timestamp, and other relevant information to reach the SAM. * If the C has valid access ticket, it replies back to C with a valid response as described in the later stages of this draft. The above sequence of Unauthorized resource between C and S with detailed CoAP message types are shown in following figure 4: ,-. ,-. |C| |S| | | ,------------------!. | | |Code: GET(Code=1) |_\| 1 GET() | |Type: Confirmable ||----------->| |Token: invalid-tkn || | |URI-Path: test || | `--------------------'| | | | ,-----------------------------!. | | |Code: 4.01 Unauthorized |_\ | 2 4.01 | |Type: Acknowledgement | |<-----------| |Token: invalid-tkn | | | |content-type:application/cbor | | | |Payload:{SamURI:xxx,params} | ,+. ,+.`-------------------------------' |C| |S| `-' `-' Figure 4: C<->S Unauthorized resource request and response Cuellar, et al. Expires October 21, 2016 [Page 18] Internet-Draft PAT for Authorization in ACE 02 April 2016 6.4. [C<->SAM]: Security Association Set-up Once the C receives SAI, it should establish a secure connection channel with the SAM. o The SAM is assumed to maintain an access control list for the clients. If the client has valid access to the resource in S, then the SAM establishes the secure connection with C. This draft does not specify how this secure connection can be established, but it could be a DTLS channel with pre-shared key. Notice that, it is important to secure this connection as the remainder of this protocol lies on the fact that the messages exchanged between C and SAM are confidential. 6.5. [C->SAM]: Access Request Message Once the C establishes secure communication channel with SAM, the C requests access request message to the SAM using the SAI information with other parameters it received from the S. The C may or may not explicitly define the details of resources it needs to access from the S to the SAM. This depends on the infrastructure or services the S offers. For example, if the S exposes resources such as temperature and humidity, a single token/ permission can be granted by SAM to access those resources; in other case, to perform a firmware upgrade over the air, the C needs elevated access rights from the SAM. Therefore, the access token generated by SAM for the C can be fine grained based on the application requirements to be performed on the S. 6.6. [C<-SAM]: Ticket Transfer Message If SAM receives an access request message fro C, the SAM generates the token as described below in the ticket/token generation. The sequence of Access request message from C->SAM and the Ticket Transfer Message as response from SAM->C is shown in figure 5: Cuellar, et al. Expires October 21, 2016 [Page 19] Internet-Draft PAT for Authorization in ACE 02 April 2016 ,-. ,---. |C| |SAM| `+' `-+-' | | | ======== | ========================================== DTLS ================================== | ======== | | | ,-----------------------------.| | |Code: POST (2) || | |Content-Format: CBOR ||1 POST: Access REQ | |URI-Path: authorize ||------------------>| |Payload:{SAMInformationMsg, || | |SAIURI,SAIOperations} || | `-----------------------------'| | | | ,-----------------------------. | 2 2.01 | |Code: Content | |<------------------| |content-type:application/cbor| | | |Payload:{TicketTransferMSG} | | | `-----------------------------' | | | ======== | ========================================== DTLS =================================== | ======== | ,+. ,-+-. |C| |SAM| `-' `---' Figure 5: Access Request and Ticket Transfer Message (TTM) The Ticket Transfer Message (TTM) contains the token and other information based on which we show how the Proof-of-Possession (PoP) token can be generated. 6.6.1. Construction of Token and Ticket Transfer Message This sub-section describes how the SAM generates the token for the request made by C and how it is enclosed within the Ticket Transfer Message (TTM) which is sent to C. The PoP token is constructed using HMAC algorithm instead of encryption as described in [I-D.ietf-oauth- pop-architecture]. A token is generated with the following data-structure: o FaceData: SAI, timestamp, time-to-live, E, random Cuellar, et al. Expires October 21, 2016 [Page 20] Internet-Draft PAT for Authorization in ACE 02 April 2016 * SAI: server authorization information (SAI) contains resource server URI with allowed permissions * timestamp: contains the time when this FaceData is created * time-to-live: lifetime (optional) and it is used to limit the validity of the access tickets * E: the Encryption Algorithm that should be used to encrypt the payload that C is sending to S (optional) (will be described in future I.D of this draft); we propose to use ChaCha20_Poly1305_AEAD as the authenticated encryption algorithm as it is secure and efficient in resource constrained environments [RFC7539] * random: random seed on the token such that we make FaceData non-deterministic, this random number can be generated by any Pseudo-Random-Generator. Also The FaceData can be optionally be encoded in CBOR format. o Verifier: G (K, FaceData) Notice that G takes two parameters (key, data) as input and produced a keyed digest as the output * K: the shared key between the SAM and the resource server (S) * G: the HMAC algorithm which is used to create the verifier, we propose to use the Poly1305 [RFC7539] o Face: FaceData, G (K, Verifier) * FaceData: it is obtained from the previous step * K: the shared key between the SAM and the resource server (S) * Verifier: obtained from the previous step o Ticket Transfer Message (TTM): Face, Verifier * Face: what we obtained from previous step * Verifier: what we obtained from previous step Notice that the Ticket transfer message and the verifier MUST be sent to the C through a secure channel. The client will use the Verifier as the key material to generate further keys to communicate with the Server. Cuellar, et al. Expires October 21, 2016 [Page 21] Internet-Draft PAT for Authorization in ACE 02 April 2016 6.7. [C->S] Authorized Resource Request Once the C has the TTM from SAM it performs a resource request message to S, in this case with a valid access token. In this alternative protocol flow, it is not required to create a secure channel between C and S. The S only verifies if the request from C is valid and if it is valid sends a valid response. Optionally, the S can encrypt the response back to C from the common secret extracted from the Request message. For example, if C performs a CoAP GET() request, then C does not have any payload to encrypt. In a CoAP POST() request the C might need to encrypt the payload. In the second case, where the C needs to encrypt the payload. The C prepares the authorized resource request message by the encrypting the "payload" using encryption algorithm described in FaceData option E (ChaCha20_Poly1305_AEAD authenticated encryption mechanism) and uses the Verifier as the key. The resource request message is constructed as the following: Request Message:{ CoAP request: request type {GET/POST}, Message ID (MID) Face: FaceData, HMAC (K, Verifier) MSG_PAYLOAD: ChaCha20_Poly1305_AEAD(Verifier,nonce = MID, AAD=null, payload) } As Verifier was generated from the FaceData which is enclosed in the Face, which is sent to the S, the S should be able to extract the Verifier as it knows the common secret key K (shared between S and SAM). 6.8. [S->C] Valid Response When the S receives a resource request from a C, the S checks for following before sending a valid response to C: o look for access ticket in the request message * is access ticket has valid hash * is access ticket valid for server * is access ticket valid for resource * is ticket timestamp valid If any one of the verification is not successful, then S responds to C with Unauthorized resource request with SAI information. If all Cuellar, et al. Expires October 21, 2016 [Page 22] Internet-Draft PAT for Authorization in ACE 02 April 2016 the above verifications are successful, then S performs the action requested and response message generated. Optionally, the response is encrypted with the Verifier obtained from the access ticket, thus only the C with the valid Verifier can read the response. Notice that from the request message, S is able to extract the Verifier and can validate the following: o The verifier is first validated by comparing the HMAC (K, FaceData). o Later the FaceData is validated by HMAC (Verifier, FaceData) After validating the Verifier and FaceData, the S extract the payload and prepares the necessary response. The optional encrypted response can be generated as: Response Message:{ CoAP request: request type {GET/POST}, Message ID (MID) RSP_MSG_PAYLOAD: ChaCha20_Poly1305_AEAD (Key=Verifier, nonce = MID+1, AAD=null, payload) } Notice the difference in the nonce parameter. The MID is incremented to avoid using the same key for encrypting twice. The Figure 6, shows Authorized resource request from C->S and response message S->C. ,-. ,-. |C| |S| `+' `+' ,----------------------------.| | |Code: POST (2) || | |URI-Path: test ||1 POST: Auth REQ | |token: Face ||---------------->| |Payload:{Enc(key=Verifier, || | |nonce=MID, AAD=null, || | |payload_data)} || | `----------------------------'| | | | ,-------------------------. | 2 2.05 | |Code: Content | |<----------------| |Payload:{Enc(key=Verifier| | | |nonce=MID+1, AAD=null, | | | |response_data)} | ,+. ,+.`-------------------------' |C| |S| `-' `-' Figure 6: [C<->S] Authorized Resource Request and Response Cuellar, et al. Expires October 21, 2016 [Page 23] Internet-Draft PAT for Authorization in ACE 02 April 2016 7. Formal Syntax tbd 8. Security Considerations tbd 9. IANA Considerations tbd. 10. Conclusions tbd 11. References 11.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.cuellar-ace-solutions] S. Gerdes, J. Cuellar and O. Bergmann: Solutions for the authorization in constrained environments, draft- cuellar-ace-solutions-00 (work in progress), October 2015. [I-D.gerdes-ace-a2a] Gerdes S., "Managing the Authorization to Authorize in the Lifecycle of a Constrained Device", draft-gerdes- ace-a2a-00 (work in progress), September 2015. [I-D.gerdes-ace-actors] Gerdes, S., "Actors in the ACE Architecture", draft-gerdes-ace-actors-05 (work in progress), October 2015. [I-D.gerdes-ace-dcaf-authorize] Gerdes, S., Bergmann, O., and Bormann C., "Delegated CoAP Authentication and Authorization Framework Cuellar, et al. Expires October 21, 2016 [Page 24] Internet-Draft PAT for Authorization in ACE 02 April 2016 (DCAF)", draft-gerdes-ace-dcaf- authorize-02 (work in progress), September 2015. [I-D.ietf-core-resource-directory] Shelby Z. and Bormann C., "CoRE Resource Directory", draft-ietf-core-resource-directory-02 (work in progress), November 2014. [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. 11.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. 12. 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). 13. Appendix 13.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 Jorge Cuellar Siemens AG Otto-Hahn-Ring 6 Munich, Germany 81739 Email: jorge.cuellar@siemens.com Cuellar, et al. Expires October 21, 2016 [Page 25] Internet-Draft PAT for Authorization in ACE 02 April 2016 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 October 21, 2016 [Page 26]