Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Jorge R Cuellar | ||
| Last updated | 2015-10-19 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-01
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
<Msg_Name> 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]