Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-00
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".
|
|
|---|---|---|---|
| Authors | Jorge R Cuellar , Santiago Suppan , Henrich Poehls | ||
| Last updated | 2015-06-15 | ||
| 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-00
ACE Working Group J. Cuellar
Internet Draft S. Suppan
Intended status: Standards Track Siemens AG
Expires: December 2015 Henrich Poehls
Univ. Passau
June 15, 2015
Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-00
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 December 15, 2015.
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 December 15, 2015 [Page 1]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 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. Secure [DTLS] channel: S <==> SAM.......................10
4.2. <Server_Token_Transfer> SAM --> S: ST = (St, paramS)....10
4.3. [<Resource_Req> C --> S: request_params].................10
4.4. [<SAM_Info> S --> C: SAM-ID].............................11
4.5. <Client_Token_Req> C --> SAM: req_permissions_list.......11
4.6. <Client_Token_Grant> SAM --> C: CT = (CT, i [, perm])...11
4.7. <Resource_Req> C -> S: AT = (At, param),[request_params].11
4.8. [DTLS channel: C <==> S]................................12
4.9. <Resource_Resp> S --> C..................................12
5. Construction of the Tokens....................................12
5.1. Main data structure......................................12
5.1.1. Traversing the Tree.................................13
5.2. Construction of St, Ct and At............................14
6. Formal Syntax.................................................15
7. Security Considerations.......................................15
8. IANA Considerations...........................................15
9. Conclusions...................................................15
10. References...................................................15
10.1. Normative References....................................15
Informative References........................................16
11. Acknowledgments..............................................16
Appendix A.......................................................17
Cuellar, et al Expires December 15, 2015 [Page 2]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
A.1. Copyright Statement......................................17
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].
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 December 15, 2015 [Page 3]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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
Cuellar, et al Expires December 15, 2015 [Page 4]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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.
Client Authorization Manager (CAM): An entity that prepares and
endorses authentication and authorization data for a Client.
Cuellar, et al Expires December 15, 2015 [Page 5]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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
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
Cuellar, et al Expires December 15, 2015 [Page 6]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
draft), and paramS is a set of parameters, determining the functions
h, f, r, 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 comprises three parts, see Fig. 1:
1. Transfer of ST = (St, paramS) form SAM to S.
2. Client Token Request from C to SAM and the respective Client Token
(CT) grant from SAM to C.
3. Access Requests with their respective Authorization Tokens (AT)
between C and S.
Cuellar, et al Expires December 15, 2015 [Page 7]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
_SAM
_/ |
_/ |
_/ |
CT = (initially) _/ | ST = (initially)
(Ct, paramC) _/ | (St, paramS)
_/ |
/ |
v v
C ----------> S
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 December 15, 2015 [Page 8]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
CAM/C S SAM
| | |
01 | | <== secure [DTLS] chan. ==>|
02 | | <- Server_Token_Transfer --|
| | |
03 |[--- Resource_Req ---->]| |
| | |
04 |[<------ SAM_Info -----]| |
| | |
05 |------------- Client_Token_Request ----------------->|
| | |
06 |<------------- Client_Token_Grant -------------------|
| | |
07 |---- Resource_Req ----->| |
| | |
08 |[<==== DTLS chan. ====>]| |
| | |
09 |<-- Resource_Resp ------| |
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.
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
Cuellar, et al Expires December 15, 2015 [Page 9]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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.
4.1. Secure [DTLS] channel: S <==> SAM
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.
4.2. <Server_Token_Transfer> SAM --> S: 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 h, f, r, 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.3. [<Resource_Req> C --> S: request_params]
The optional Unauthorized Resource Request message is a request for
a resource hosted by S for which no proper authorization is granted.
Cuellar, et al Expires December 15, 2015 [Page 10]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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.4. [<SAM_Info> S --> C: SAM-ID]
As in DCAF, the Server CAN instruct the Client about which SAM to
contact.
4.5. <Client_Token_Req> C --> SAM: req_permissions_list
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. <Client_Token_Grant> SAM --> C: CT = (CT, i [, perm])
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 Server S can verify the authenticity of the permission.
(Details will be given in a later version of the draft).
4.7. <Resource_Req> C -> S: AT = (At, param),[request_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
Cuellar, et al Expires December 15, 2015 [Page 11]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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.8. [DTLS channel: C <==> S]
Optionally, a DTLS channel is constructed using pre-shared key
constructed from the common information held by C and S.
4.9. <Resource_Resp> S --> C
The server answers the request of the server, as stipulated by the
service description. This message can be
5. Construction of the Tokens
The main construction is an infinite tree with a root, denoted by x.
The children of any node are constructed using two functions: a hash
function h and a 1-1 function f. The Token secrets St, Ct and At
are all values in the tree and thus can be constructed from x using
h and f. New versions of any of these secrets, including x, can be
constructed in a similar way, but additionally using another
function r ("revert") instead of f. Other functions g1, g2, g3, and
g4 will be used to generate the derived keys VerifK, PSK, IntK, and
ConfK. We assume that h, f, r, 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.
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, which we denote m. 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,
Cuellar, et al Expires December 15, 2015 [Page 12]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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 a hash h of a function f of a and i:
x_a' = x_a;i = h(f(x_a, i)).
The choice of h and f should not be regarded a secret: they are
publicly known parameters 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.
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 proper descendent of x_a, which may be written as
x_a;b. Thus, b is a non empty sequence of integers. For example:
the fifth child of the second child of x_a is x_a;b, with b = "25".
Traversing the tree with respect to the current parent node x_a,
starting at x_a;b gives the following sequence of nodes (loop):
- First, move up from x_a;b until reaching x_a;b', a direct child of
x_a. Thus b' is an integer (or, the same: a sequence of only one
integer).
- If x_a;b' is the right-most child of x_a, stop here.
- If x_a;(b'+1) is the right-most child of x_a, then move to its
first child (if it exists): x_a;(b'+1);1. If x_a;(b'+1) has no
children, stop.
- If x_a;(b'+1) is not right-most child of x_a, then move to it.
Cuellar, et al Expires December 15, 2015 [Page 13]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
Example: assume that the "current parent node" is x_31 and the
current node is x_31543. Notice that x_31543 is a descendent of
x_31 simply because 31 is a prefix of 31543. Assume that the degree
of the tree is 7.
- First, move up: this produces the sequence of values:
o x_31543, x_3154, x_315
- x_315 is a child of the current parent node and x_316 is not the
right-most. Thus we move to it:
o x_316
- x_316 is a child of the current parent node and the right sibling,
x_317, is the right-most. Thus we move to its first child:
o x_3171
- From there we move to the right until we find the last but one:
o x_3172, x_3173, x_3174, x_3175, x_3176
- From there we move to the first child of the right sibling and
then move right:
o x_31771, x_31772, x_31773, x_31774, x_31775, x_31776.
- Etc. If the degree of the tree is not one, and each node has
children, the sequence is infinite. In any case the sequence can
be calculated knowing the current node, the current parent node, h
and f. If the degree is one, this corresponds to the one-time-
passwords construction scheme.
5.2. Construction of St, Ct and At
The root x of the data structure is the "main secret". It is
generated by the SAM as a random or pseudo-random number of m bits
(m is a parameter of the system installation and can be chosen by
SAM; m is also the length of bit strings that the hash h generates).
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.
Cuellar, et al Expires December 15, 2015 [Page 14]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
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.
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.
Cuellar, et al Expires December 15, 2015 [Page 15]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
[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.
[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 December 15, 2015 [Page 16]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 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 December 15, 2015 [Page 17]
Internet-Draft ace-pat-priv-enhanced-authz-tokens June 2015
Authors' Addresses
Jorge Cuellar
Siemens AG
CT RTC ITS
Email: jorge.cuellar @ siemens.com
Cuellar, et al Expires December 15, 2015 [Page 18]