ACE Working Group J. Cuellar Internet Draft S. Suppan Intended status: Standards Track Siemens AG Expires: April 2016 Henrich Poehls Univ. Passau October 19, 2015 Privacy-Enhanced Tokens for Authorization in ACE draft-cuellar-ace-pat-priv-enhanced-authz-tokens-01 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 19, 2009. Copyright Notice Copyright (c) 2015 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 Cuellar, et al Expires April 19, 2016 [Page 1] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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, similar to DCAF [I-D.gerdes-ace-dcaf- authorize]. The tokens can be also used to establish a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. 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..............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 5. Construction of the Tokens....................................13 5.1. Main data structure......................................14 5.1.1. Traversing the Tree.................................15 5.2. Construction of St, Ct and At............................15 6. Formal Syntax.................................................16 7. Security Considerations.......................................16 8. IANA Considerations...........................................16 9. Conclusions...................................................16 10. References...................................................16 Cuellar, et al Expires April 19, 2016 [Page 2] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 10.1. Normative References....................................16 Informative References........................................17 11. Acknowledgments..............................................17 Appendix A.......................................................18 A.1. Copyright Statement......................................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 [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]. Cuellar, et al Expires April 19, 2016 [Page 3] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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. 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. Cuellar, et al Expires April 19, 2016 [Page 4] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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 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. Cuellar, et al Expires April 19, 2016 [Page 5] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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 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: . 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 . as Pre-shared Key to establish a DTLS secure channel . for Integrity protection (in message authentication codes) . 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 Cuellar, et al Expires April 19, 2016 [Page 6] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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 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 Cuellar, et al Expires April 19, 2016 [Page 7] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 (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. This corresponds to the message (3) Token Response of [I-D.cuellar-ace-solutions] 2. The Client Token (CT) grant from SAM to C. This is the composition of messages (7) and (8). 3. 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 April 19, 2016 [Page 8] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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. Cuellar, et al Expires April 19, 2016 [Page 9] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 Each time C sends S a Resource Request, it generates and presents a (current) Authorization Token to S to prove its right to access. 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 April 19, 2016 [Page 10] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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. Cuellar, et al Expires April 19, 2016 [Page 11] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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 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. Cuellar, et al Expires April 19, 2016 [Page 12] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 5. 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. 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. Cuellar, et al Expires April 19, 2016 [Page 13] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 5.1. 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 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. Cuellar, et al Expires April 19, 2016 [Page 14] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 5.1.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 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. 5.2. 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 Cuellar, et al Expires April 19, 2016 [Page 15] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 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. 6. Formal Syntax tbd 7. Security Considerations tbd 8. IANA Considerations tbd. 9. Conclusions tbd 10. References 10.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. Cuellar, et al Expires April 19, 2016 [Page 16] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 [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 (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. 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. 11. Acknowledgments 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). This document was prepared using 2-Word-v2.0.template.dot. Cuellar, et al Expires April 19, 2016 [Page 17] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 Appendix A. A.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 (http://trustee.ietf.org/license-info). Cuellar, et al Expires April 19, 2016 [Page 18] Internet-Draft ace-pat-priv-enhanced-authz-tokens October 2015 Authors' Addresses Jorge Cuellar Siemens AG CT RTC ITS Email: jorge.cuellar @ siemens.com Cuellar, et al Expires April 19, 2016 [Page 19]