Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-02
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 , Prabhakaran Kasinathan , Daniel Calvo | ||
| Last updated | 2016-04-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-02
Authentication and Authorization for Constrained Environments
Internet-Draft J. Cuellar
Intended status: Informational P. Kasinathan
Expires: October 21, 2016 Siemens AG
D. Calvo
Atos Research and Innovation
April 19, 2016
Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-02
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Cuellar, et al. Expires October 21, 2016 [Page 1]
Internet-Draft PAT for Authorization in ACE 02 April 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key words to Indicate Requirement Levels . . . . . . . . 3
1.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Actors and Terminology . . . . . . . . . . . . . . . . . 5
2. System Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Message Flow Overview . . . . . . . . . . . . . . . . . . 8
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10
4.1. [C --> S: Unauthorized Resource Request: request_params] 10
4.2. [S --> SAM: Token Request] . . . . . . . . . . . . . . . 10
4.3. [SAM --> S: Token Response: ST = (St, paramS)] . . . . . 11
4.4. [S --> C: SAM Information: SAM-ID] . . . . . . . . . . . 11
4.5. C --> CAM: Access Request . . . . . . . . . . . . . . . . 11
4.6. CAM --> SAM: Ticket Request . . . . . . . . . . . . . . . 11
4.7. SAM --> CAM: Ticket Grant . . . . . . . . . . . . . . . . 11
4.8. CAM --> C: Ticket Transfer . . . . . . . . . . . . . . . 12
4.9. CAM --> C: Client Authorization Information (CAI) . . . . 12
4.10. C <==> S: Security Association . . . . . . . . . . . . . 12
4.11. C --> S: Authorized Resource Req.: AT = (At,
param),[params] . . . . . . . . . . . . . . . . . . . . . 12
4.12. S --> C: Resource Response . . . . . . . . . . . . . . . 12
4.13. Construction of the Tokens . . . . . . . . . . . . . . . 12
4.14. Main data structure . . . . . . . . . . . . . . . . . . . 13
4.14.1. Traversing the Tree . . . . . . . . . . . . . . . . 14
4.15. Construction of St, Ct and At . . . . . . . . . . . . . . 15
5. Alternative Protocol . . . . . . . . . . . . . . . . . . . . 16
5.1. Alternative Message Flow . . . . . . . . . . . . . . . . 16
6. Alternative Protocol Details . . . . . . . . . . . . . . . . 17
6.1. Shared Key (K) between SAM and S . . . . . . . . . . . . 17
6.2. [C->S]: Resource Request without valid access token . . . 18
6.3. [S->C]: Unauthorized Request, SAI . . . . . . . . . . . . 18
6.4. [C<->SAM]: Security Association Set-up . . . . . . . . . 19
6.5. [C->SAM]: Access Request Message . . . . . . . . . . . . 19
6.6. [C<-SAM]: Ticket Transfer Message . . . . . . . . . . . . 19
6.6.1. Construction of Token and Ticket Transfer Message . . 20
6.7. [C->S] Authorized Resource Request . . . . . . . . . . . 22
6.8. [S->C] Valid Response . . . . . . . . . . . . . . . . . . 22
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . 25
12. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
13. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Cuellar, et al. Expires October 21, 2016 [Page 2]
Internet-Draft PAT for Authorization in ACE 02 April 2016
13.1. Copyright Statement . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Three well-known problems in constrained environments are the
authorization of clients to access resource on servers, the
realization of secure communication between nodes, and the
preservation of privacy. The reader is referred for instance to [I-
D.gerdes-ace-dcaf-authorize] and [I-D.gerdes-ace-actors], and
[KoMa2014].
This draft tackles certain aspects of those three problems. It
describes a way of constructing Token Material (Key Material) that
can be used by clients and servers (or in some cases, more generally
by arbitrary nodes) to create secure channels, provide
authentication, in a context similar to ACE-DCAF Tickets. Moreover,
the construction can be used to offer user consent (in the sense of
privacy) and to create dynamically pseudonyms to enhance the
unlinkability of the information, see Subsection "Features" below.
This draft uses the same architecture of [I-D.gerdes-ace-actors],
designed to help constrained nodes with authorization-related tasks
via less-constrained nodes. As in DCAF, PAT supports an implicit
authorization mode where no authorization information is exchanged
and uses access tokens to implement this architecture. A device that
wants to access an item of interest on a constrained node first has
to gain permission in the form of a token from the node's
Authorization Manager.
A main goal of PAT is to securely transmit authorization tokens. A
by-product is the setup of a Datagram Transport Layer Security (DTLS)
[RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279]
between two nodes. Notice that the DTLS channel is not needed to
securely transmit the authorization tokens. In some cases, relevant
in constrained environments, it is also not necessary for a secure
transmission of the payload data from server to client.
1.1. Key words to Indicate Requirement Levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
Cuellar, et al. Expires October 21, 2016 [Page 3]
Internet-Draft PAT for Authorization in ACE 02 April 2016
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC
1.2. Features
o The method allows a User, or an Authentication/Authorization
Manager on its behalf, to authorize one (or several) client(s) to
access resources on a server. The client and/or the server can be
constrained devices. The authorization is implemented by
distributing purpose-built Key Material (which we generically call
"Tokens") to the server and clients. This SHOULD be done by
secure channels.
o The Client Tokens are crafted in such a way that the clients can
construct authorization tokens that allow them to demonstrate to
the server their authorization claims. The message exchange
between client and server for the presentation of the tokens MAY
be performed via insecure channels.
o Further, the purpose-built Key material and tokens can be used for
establishing a secret shared key between a client and the server,
which can be then used to establish a DTLS communication with pre-
shared keys.
o The tokens do not provide any information about any associated
identities or identifiers of the clients nor of the server.
In particular, the method can be used in context where unlinkability
(privacy) is a main goal: the tokens convey only the assurance of the
authorization claims of the clients. This means that the payloads of
our protocol, and in particular, the Authentication Token secrets
used, can be constructed in such a way that they not leak information
about the correspondence of messages to the same Client. In other
words: if an eavesdropper observes the messages from the different
Clients to and from the server, the protocol does not give him
information about which messages correspond to the same Client. Of
course, other information, like the IP-addresses or the contents
themselves of the requests/responses may leak some information in
this regard, but that is not information leaked by our protocol and
can be treated separately.
o The tokens may be supported by a "proof-of-possession" (PoP)
method. PoP allows an authorized entity (a client) to prove to
the verifier (here, the server), that he is indeed the intended
authorized owner of the token and not simply the bearer of the
token. (Notice that the Authorization Token may be sent in the
Cuellar, et al. Expires October 21, 2016 [Page 4]
Internet-Draft PAT for Authorization in ACE 02 April 2016
clear, and thus, it could be stolen by an intruder. A PoP would
hinder the attacker to use the token pretending to be authorized).
o The Key Material can be used to generate and coordinate pseudonyms
between C and S and potentially further parties.
o The user (more precisely, the Resource Owner, RO, see
Section "Actors and Terminology" below) is able to decide (if he
wishes: in a fine-grained way and in real-time) which client under
which circumstances may access his data stored in S. This can be
used to provide consent (in terms of privacy) from users (again,
ROs).
As DCAF, it has the following features:
o Simplified authentication on constrained nodes by handing the more
sophisticated authentication over to less-constrained devices.
o Support of secure communication between constrained devices
o Authorization policies of the principals of both participating
parties are ensured.
o Simplified authorization mechanism for cases where implicit
authorization is sufficient.
o Using only symmetric encryption on constrained nodes.
1.3. Actors and Terminology
The actors and terminology are the same as in DCAF. Very briefly,
for the purposes of this draft, the main actors are:
Server (S): An endpoint that hosts and represents a CoAP (see
[RFC7252]) resource. Client (C): An endpoint that attempts to access
a CoAP resource on the Server. Server Authorization Manager (SAM):
An entity that prepares and endorses authentication and authorization
data for a Server. Client Authorization Manager (CAM): An entity
that prepares and endorses authentication and authorization data for
a Client. Resource Owner (RO): The principal that is in charge of
the resource and controls its access permissions. The RO is often
the data subject of the protected resource.
In order to avoid confusions, instead of redefining the terms of
DCAF, we use additionally the following terms:
Server Token (ST): The token which is generated by the SAM for the
Server. Besides parameters, which may contain authorization
Cuellar, et al. Expires October 21, 2016 [Page 5]
Internet-Draft PAT for Authorization in ACE 02 April 2016
information that represents RO's authorization policies for C, it
contains a secret, St, called the ST-secret. This one can be used to
verify the Authorization Token and to generate other secrets to be
discussed later.
Client Token (CT): The token which is generated by the SAM for the
Client. It contains a secret, Ct, which can be used to generate the
Authorization Token, pus some other data used for PoP. Optionally CT
may contain authorization information that represents RO's
authorization policies for C.
Authorization Token (AT): The token which is generated by the Client
and presented by him to the Server. It contains a secret AT, which
changes regularly (in a similar way to one-time passwords). The AT
contains all information needed by the Server to verify that it was
granted by SAM.
VerifK, PSK, IntK, ConfK: Derived keys between C and S used
respectively:
o to verify that they are talking with the intended partner, for the
Client C it is used as Proof of Possession of the (current)
Authorization Token
o as Pre-shared Key to establish a DTLS secure channel
o for Integrity protection (in message authentication codes)
o for Confidentiality Protection (to be elaborated in a future
version of the document).
2. System Overview
As in DCAF, each Server (S) has a Server Authorization Manger (SAM)
which conducts the authentication and authorization for S. S and SAM
are assumed to have a secure channel, probably a DTLS channel, but
the current specification does not assume anything about it, except
that it is two way secure, preserving integrity and confidentiality.
Using this secure communication channel SAM provides to S the main
secret x which is used within the initial version of the Server Token
(ST). Thus ST = (St, paramS), where St is a "main secret" created by
SAM (in a way that is outside of the scope of this draft), and paramS
is a set of parameters, determining the functions G, g1, g2, g3, g4,
etc. to be discussed later and, optionally, the authorization
policies for the clients foreseen.
To gain access to a specific resource on a Server S, a Client (C)
requests a token from the SAM, either directly or using its CAM. In
Cuellar, et al. Expires October 21, 2016 [Page 6]
Internet-Draft PAT for Authorization in ACE 02 April 2016
the following, for simplicity, we only discuss the collocated CAM-C
role; the separation of the roles should be clear to the reader (and
will be detailed in subsequent versions of the ID).
After SAM receives the request from C, he decides if C is allowed to
access the resource. If so, it generates a Client-Id and a
corresponding Client-Token used for the authorization and for
securing the communication between C and S.
For explicit access control, SAM adds the detailed access permissions
to the token in a way that C (or his CAM) can interpret and S can
verify as authentically stemming from SAM.
Then C presents the Authorization Token to S, demonstrating his
authorization, and C and S can establish a secure channel. As in
DCAF, an Authorization Manager has to fulfill several requirements
regarding enough storage, use interaction and processing power, see
[I-D.gerdes-ace-a2a].
3. Protocol Overview
The PAT protocol is an instantiation of the generic ace-solution
protocol presented in [I-D.cuellar-ace-solutions].
It comprises the following steps:
0) Security Context Setup Between CAM and SAM
1) Unauthorized Resource Request Message
2) Token Request Message
3) Token Response
4) SAM Information Message
5) Access Request Message
6) Ticket Request Message
7) Ticket Grant Message
8) Ticket Transfer Message
9) Client Authorization Information Message
10) Security Association between C and S
11) Authorized Resource Request Message
12) Resource Response Message
PAT instantiates in particular the payload of messages (3), (7), (8)
and (11).
The main exchanges can be presented as in Fig. 1:
1. Transfer of ST = (St, paramS) form SAM to S.
Cuellar, et al. Expires October 21, 2016 [Page 7]
Internet-Draft PAT for Authorization in ACE 02 April 2016
This corresponds to the message (3) Token Response of [I-D.cuellar-
ace-solutions]
1. The Client Token (CT) grant from SAM to C. This is the
composition of messages (7) and (8).
2. Access Requests with their respective Authorization Tokens (AT)
between C and S.
_SAM
_/ |
(7) Ticket Grant Msg _/ |
(8) Ticket Transfer Msg _/ | (3) Token Response
_/ |
CT = (Ct, paramC) _/ | ST = (St, paramS)
_/ |
/ |
v v
C ------------> S
(11) Authorized Resource
Request Msg
At1, At2,..., Atn
Figure 1: The 3 main parts of the Protocol
There are 3 main Tokens: ST, CT and AT, each of the form (nonce,
param), where the nonce is St, Ct, and At, resp., and param =
paramC/paramS/paramT is some additional information. (ParamT is not
shown in the Figure, for readability).
3.1. Message Flow Overview
In Figure 2, a PAT protocol flow is depicted (messages in square
brackets are optional). Notice that in comparison to DCAF, rows 07
and 08 are in different order and the DTLS channel between C and S is
optional. The resource response (09) can be optionally secured by
DTLS or by other native PAT methods:
Cuellar, et al. Expires October 21, 2016 [Page 8]
Internet-Draft PAT for Authorization in ACE 02 April 2016
C CAM S SAM
| | | |
| |<=============== (0) Security Context Setup ===============>|
| | | |
|[---- (1) Unauth Resource Req ---->]| |
| | | |
| | |[---- (2) Token Request --->]|
| | | |
| | |<---- (3) Token Response --> |
| | | |
| [<---- (4) SAM Information -------]| |
| | | |
|-(5)>| | |
| | | |
| |----------------- (6) Ticket Request ---------------------->|
| | | |
| |<---------------- (7) Ticket Grant -----------------------|
| | | |
|<(8)-| | |
| | | |
|<(9)-| | |
| | | |
|[<==(10) Security Association ====>]| |
| | | |
|--- (11) Authorized Resource Req -->| |
| | | |
|<-- (12) Resource Response ---------| |
Figure 1: Protocol Overview
As in DCAF, to determine the SAM in charge of a resource hosted at
the S, C MAY send an initial Unauthorized Resource Request message to
S. S then denies the request and sends the address of its SAM back
to C. Or, instead of the initial Unauthorized Resource Request
message, C MAY look up the desired resource in a resource directory
(cf. [I-D.ietf-core-resource-directory]) that lists the available
resources.
Once C knows SAM's address, it can send a request for authorization
to SAM (directly, as in Fig. 1 or indirectly using its own CAM). If
the access is to be authorized, SAM generates a Client Token (CT) for
C. It contains keying material for generating all necessary tokens
and keys, and, if necessary, a representation of the permissions C
has for the resource.
Each time C sends S a Resource Request, it generates and presents a
(current) Authorization Token to S to prove its right to access.
Cuellar, et al. Expires October 21, 2016 [Page 9]
Internet-Draft PAT for Authorization in ACE 02 April 2016
With their common knowledge in St and Ct, C and S are able to
establish a secure channel.
The following sections specify the message flows in more detail, how
the token secrets St, Ct and At are constructed, how the tokens can
be revoked, and how S and C can use their common knowledge to verify
the authenticity of the ATs and to obtain a the shared keys VerifK,
PSK, IntK, and ConfK.
4. Protocol Details
In the following descriptions the notation
<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 October 21, 2016 [Page 10]
Internet-Draft PAT for Authorization in ACE 02 April 2016
4.3. [SAM --> S: Token Response: ST = (St, paramS)]
The owner of the server determines a number N which is (probably) an
upper bound on the number of Clients that the Server will
simultaneously serve. This number N should not be too high, as the
storage and computation effort of the server will increase (linearly)
with N. (But the owner may decide any time later to increase or
decrease the number N if necessary). Using the secure channel, SAM
sends to S the initial value of ST = (St, paramS), where St is a
(preferably, random) number that can't be guessed by an attacker, and
paramS is a set of parameters that encode the number N, the choice of
functions G, g1, g2, g3, g4, and the permissions Client Nr "i" has
(for each Client i, or for a set of them). The permissions may
remain undefined or incomplete and can be extended or modified later
anytime. They may also contain validity periods or other
restrictions in the Service Level Agreement.
At any later point in time the SAM may change ST, or a part of it:
send a new value for St, or change or extend the permissions or
change N, the number of expected Clients.
4.4. [S --> C: SAM Information: SAM-ID]
As in DCAF, the Server CAN instruct the Client about which SAM to
contact.
4.5. C --> CAM: Access Request
The Client contacts directly or indirectly via the CAM the SAM of his
desired Server S, expressing the set of permissions it requests to
the resources of the Server S.
4.6. CAM --> SAM: Ticket Request
The Client contacts directly or indirectly via the CAM the SAM of his
desired Server S, expressing the set of permissions it requests to
the resources of the Server S.
4.7. SAM --> CAM: Ticket Grant
SAM decides which Client Number "i" the Client C should have. Each
Client will have a different number. The number "i" is an integer
between 1 and N, the number of Clients. The choice of value for "i"
will depend on which permissions the owner has foreseen and, more
importantly, the SAM has encoded as parameters sent to S. In this
message the Client Token CT and the number i are sent. Optionally,
SAM can encode the permissions in this message in a way that the
Cuellar, et al. Expires October 21, 2016 [Page 11]
Internet-Draft PAT for Authorization in ACE 02 April 2016
Server S can verify the authenticity of the permission. (Details
will be given in a later version of the draft).
4.8. CAM --> C: Ticket Transfer
The CAM forwards the Client Token to the client C.
4.9. CAM --> C: Client Authorization Information (CAI)
The CAM may restrict the operations C performs on S by transferring
Client Authentication Information (CAI) to C.
4.10. C <==> S: Security Association
Optionally, a DTLS channel is constructed using pre-shared key
constructed from the common information held by C and S.
4.11. C --> S: Authorized Resource Req.: AT = (At, param),[params]
In possession of the Client Token, CT, the Client can construct valid
Authorization Tokens, AT, which demonstrates his authorization to
access the resources he is requesting. Regularly, the message
Resource_Req has to be sent afresh and a new AT must be used: Client
C has to renew his Authorization status at the Server. The frequency
in which the Client has to send a new AT can be enforced by C and is
determined indirectly the owner of S (or by SAM). This allows a
fine-grained control on the service level that the Server will
provide to the Client (for instance, on the amount of information of
sensor data). We assume that the frequency of renewal is the same
for all Clients, but each Client has a different number of
Authorization Tokens it can construct. Each time a new Resource_Req
is sent, a new Authorization Token MAY be needed.
4.12. S --> C: Resource Response
The server answers the request of the server, as stipulated by the
service description. This message can be sent over the secure
channel between C and S (established as described above), or can be
secured directly, as discussed below.
4.13. Construction of the Tokens
The main data structure used in this document may be represented as a
tree of values. Each value is a bit string of a fixed size, which we
denote m. Initially we choose m = 265 bits, but it is easy to define
extensions for other values of m. This data structure may be
implemented in several different ways, for instance as a set of
tables representing the currently relevant parts of the tree.
Cuellar, et al. Expires October 21, 2016 [Page 12]
Internet-Draft PAT for Authorization in ACE 02 April 2016
The tree is constructed based on a "root secret" which we denote by
"x") and a Pseudo-Random Generator, commonly used to generate Stream
Ciphers. In particular, we propose to use the Pseudo-Random
Generator (PRG) of ChaCha20 [RFC7539]. In other words, we use
ChaCha20 block function as a key-derivation function, by generating
an arbitrarily long keystream. The stream cipher ChaCha20 takes as
input a 256-bit key k, a 64-bit nonce v (unique message number), and
a 64-bit block number. The ChaCha20 output stream can therefore be
accessed randomly, and any number of blocks can be computed in
parallel.
Instead of ChaCha20, other PRG can be used as well, or even hash
functions. With any of those building blocks, it is easy to
construct functions G: K x I -> K, and g2, g3, g4: K x I -> K, where
K = the key space = {0,1}^265 and I ={0,1,2,..N} where N is an
appropriate integer (a parameter of the construction).
Starting from a secret x, a tree of derived secrets (we use the words
keys and secrets indiscriminately) is constructed. The main property
of the secrets in the tree is that an attacker can't use the
information of a secret to obtain information about other secrets in
the tree except descendents. (The knowledge of secrets on the tree
reveals nothing about any secret that is not a descendent of any of
them).
The children of any node are constructed using a function G
("generator") that takes a key k (of size m = 256 bits) and an index
i (the "block number") and creates a new key of size m =256 bits.
The Token secrets St, Ct and At are all values in the tree and thus
can be constructed from x using G. Other functions g1, g2, g3, and
g4 will be used to generate the derived keys VerifK, PSK, IntK, and
ConfK.
We assume that G, g1, g2, g3, and g4 are (or may be) all publicly
known functions. That is the security of the protocol SHOULD NOT
depend on the secrecy of those functions.
4.14. Main data structure
The main data structure used in this document may be viewed
abstractly as a tree of values. Each value is a bit string of a
fixed size m (= 256 bits). But this data structure may be
implemented in several different ways, for instance as a set of
tables representing the currently relevant parts of the tree.
We use a sequence of integer numbers as indexes for the nodes
(values) in the tree. To avoid parentheses, commas, and semicolons
Cuellar, et al. Expires October 21, 2016 [Page 13]
Internet-Draft PAT for Authorization in ACE 02 April 2016
we write for instance: "123" for the sequence of 3 numbers "1", "2",
and "3". In what follows, in all our examples of integer sequences,
we will not use numbers that require 2 or more digits (that is,
numbers > 9).
The sequences of integers are used to index values in a tree: x_a is
the value at the node with position (address) a. In other words, the
nodes (and their values) are denoted as x_a, where a is a sequence of
integer numbers. The tree has a root x (x_a where a = epsilon is the
empty sequence). The children of x are x_1, x_2, x_3, ..., x_N,
where k = 1..N is a singleton list, that is a list with only one
number. If x_a is a node in the tree, then the children of x_a all
have the form x_a', where a'=a;i is a the concatenation of a and an
integer i. The value x_a'= x_a; i=x_(a;i) is calculated as G(x_a,i).
In the case of a hash h:
x_a' = x_a;i = h(f(x_a, i)).
Where f is a fixed (publicly known) function such that for any fixed
i the function f(.,i) is 1-1. The choice of G should not be regarded
a secret: it is a publicly known parameter of the installation for S.
It follows that if an entity knows x_a, the entity is able to
calculate all descendants of it, that is, all nodes in the subtree
with root x_a. But not vice-versa: since h is a one-way function,
the knowledge of x_a;i is not enough to calculate x_a.
Note: "x_a" is read as "x sub a" or "x subindex a". "a" is called the
index or address of the node.
Note: Since we also use concatenation of bit strings we need to use
parenthesis in that case: x_a;i means x_(a;i), while (x_a);bs means
the concatenation of the bit strings (x_a) and bs.
4.14.1. Traversing the Tree
Now we describe a simple procedure for traversing part of the tree,
which we now assume of a fixed degree. That is, each node of the
tree has either no children or has exactly this amount of children.
Assume that we have a certain "current parent node" x_a and a
"current node", a child of x_a, which may be written as x_a;i. Thus,
i is an index (an integer). For example: the fifth child of x_a is
x_a;i, with i = "5".
Traversing the tree with respect to the current parent node x_a,
starting at x_a; i gives the following sequence of nodes (loop): - If
x_a; i is the right-most child of x_a, stop here. - If x_a;(i+1) is
the right-most child of x_a, then move to its first child (if it
Cuellar, et al. Expires October 21, 2016 [Page 14]
Internet-Draft PAT for Authorization in ACE 02 April 2016
exists): x_a;(i+1);1. If x_a;(i'+1) has no children, stop. - If
x_a;(i'+1) is not right-most child of x_a, then move to it.
4.15. Construction of St, Ct and At
The secret "x" is the "main secret". It is generated by the SAM as a
random or pseudo-random number of m bits (m is taken to be 256). The
method used to construct x is out of our scope, but it should be
practically impossible to guess by an attacker, even if he knows in
plaintext a sequence of previous or future choices of x.
Initially, St = x
St is sent by the SAM to the Server S in the message
Server_Token_Transfer. The value of St at the Server may change if
the current value of St is revoked by the SAM. For this, it is not
necessary to send a new Server_Token_Transfer. (Details in a future
version of the I.D).
The root has N children, one for each foreseen Client. The value
x_i, for i=1..N is a secret associated to Client number i, but it is
not known by the Client. The values x, x_1, x_2, .., x_N are secrets
that never leave the SAM or the Server S and should not be leaked.
The first children of x_1, x_2, .., x_N are the initial values of CT.
In other words, for Client number i:
Initially, Ct = x_i1
Ct is sent by the SAM to C(i), the Client number i, in the message
Client_Token_Grant. Also in this message, the SAM sends the "current
node" (used by C to start a traversal), the depth and the degree of
the sub-tree at the node Ct.
The value of Ct at the Server may change if the current value of Ct
is revoked by the SAM. If this happens, it is necessary for the
Client to obtain a new Client_Token_Grant. (Details in a future
version of the I.D).
To create the sequence of Authentication Token secrets, At1, At2,
..., the Client traverses the tree starting at a "current node"
(determined by the SAM in the parameters of the Client_Token_Grant
message) with the current parent node being the current value of Ct.
Cuellar, et al. Expires October 21, 2016 [Page 15]
Internet-Draft PAT for Authorization in ACE 02 April 2016
5. Alternative Protocol
This section briefly describes an alternative of the PAT protocol.
The following method is similar to how Proof of Possession tokens are
constructed in [I-D.ietf-oauth-pop-architecture]. The client(C),
Server(S) and Server Authentication Manager (SAM) are the three
actors involved in the following description. It may or may not
involve Client Authentication Manager (CAM) as an intermediary for C
authentication. Notice that in comparison to [I-D.ietf-oauth-pop-
architecture] we propose to use a different way to construct the
token for C by SAM.
5.1. Alternative Message Flow
In Figure 3, we show the alternative PAT protocol message flow.
Initially, the S and the SAM shares a long term secret key K. The
key K is used by the S in the later stages to validate the tokens
from C. Also, it is required to have a confidential channel between
C and SAM and it could be DTLS. Notice that in comparison to [I-
D.ietf-oauth-pop-architecture] it is not mandatory to have a
confidential channel between C and S.
Cuellar, et al. Expires October 21, 2016 [Page 16]
Internet-Draft PAT for Authorization in ACE 02 April 2016
,-. ,-. ,---.
|C| |S|<==0(K)==>|SAM|
`+' `+' `-+-'
|1 Un-Auth Resource REQ | |
|----------------------->| |
| | |
| 2 Un-auth REQ + SAI | |
|<-----------------------| |
| | |
| 3 DTLS handshake |
|<------------------------------------>|
| | |
| 4 Access REQ MSG |
|------------------------------------->|
| | |
| 5 Ticket transfer MSG [F,V] |
|<-------------------------------------|
| | |
|6 Auth resource REQ MSG | |
|----------------------->| |
| | |
| 7 Resource RSP | |
|<-----------------------| |
,+. ,+. ,-+-.
|C| |S| |SAM|
`-' `-' `---'
Figure 3: Alternative Protocol message flow
6. Alternative Protocol Details
6.1. Shared Key (K) between SAM and S
The SAM and S share a long term shared secret, i.e., a shared key K.
The key K MAY be associated betweeyn the entities during the device
set-up phase or through other key-exchange mechanisms, but it is
assumed that none other than SAM and S knows the secret K.
TODO: Is it good to mention the following?
o The key exchange mechanism SHOULD be efficient
o The S SHOULD have the capability to update the K in future, if K
is compromised or becomes invalid.
Cuellar, et al. Expires October 21, 2016 [Page 17]
Internet-Draft PAT for Authorization in ACE 02 April 2016
6.2. [C->S]: Resource Request without valid access token
It is assumed that the C does not have information about SAM,
therefore it does not have valid access token to access the resource
from S. But we assume that the C has the information about the
resource server and the resource it needs to access. Initially, the
C performs a request (could be a CoAP GET or POST message) to the
resource server S for a resource, given by an URI.
6.3. [S->C]: Unauthorized Request, SAI
Once the S receives a request from a C, it checks the following:
o whether the C has valid access ticket.
* If not, it replies back with un-authorized request message
together with the SAM information message (SAI) with additional
parameters such as URI, timestamp, and other relevant
information to reach the SAM.
* If the C has valid access ticket, it replies back to C with a
valid response as described in the later stages of this draft.
The above sequence of Unauthorized resource between C and S with
detailed CoAP message types are shown in following figure 4:
,-. ,-.
|C| |S|
| |
,------------------!. | |
|Code: GET(Code=1) |_\| 1 GET() |
|Type: Confirmable ||----------->|
|Token: invalid-tkn || |
|URI-Path: test || |
`--------------------'| |
| | ,-----------------------------!.
| | |Code: 4.01 Unauthorized |_\
| 2 4.01 | |Type: Acknowledgement |
|<-----------| |Token: invalid-tkn |
| | |content-type:application/cbor |
| | |Payload:{SamURI:xxx,params} |
,+. ,+.`-------------------------------'
|C| |S|
`-' `-'
Figure 4: C<->S Unauthorized resource request and response
Cuellar, et al. Expires October 21, 2016 [Page 18]
Internet-Draft PAT for Authorization in ACE 02 April 2016
6.4. [C<->SAM]: Security Association Set-up
Once the C receives SAI, it should establish a secure connection
channel with the SAM.
o The SAM is assumed to maintain an access control list for the
clients. If the client has valid access to the resource in S,
then the SAM establishes the secure connection with C.
This draft does not specify how this secure connection can be
established, but it could be a DTLS channel with pre-shared key.
Notice that, it is important to secure this connection as the
remainder of this protocol lies on the fact that the messages
exchanged between C and SAM are confidential.
6.5. [C->SAM]: Access Request Message
Once the C establishes secure communication channel with SAM, the C
requests access request message to the SAM using the SAI information
with other parameters it received from the S.
The C may or may not explicitly define the details of resources it
needs to access from the S to the SAM. This depends on the
infrastructure or services the S offers. For example, if the S
exposes resources such as temperature and humidity, a single token/
permission can be granted by SAM to access those resources; in other
case, to perform a firmware upgrade over the air, the C needs
elevated access rights from the SAM. Therefore, the access token
generated by SAM for the C can be fine grained based on the
application requirements to be performed on the S.
6.6. [C<-SAM]: Ticket Transfer Message
If SAM receives an access request message fro C, the SAM generates
the token as described below in the ticket/token generation.
The sequence of Access request message from C->SAM and the Ticket
Transfer Message as response from SAM->C is shown in figure 5:
Cuellar, et al. Expires October 21, 2016 [Page 19]
Internet-Draft PAT for Authorization in ACE 02 April 2016
,-. ,---.
|C| |SAM|
`+' `-+-'
| |
| ======== |
========================================== DTLS ==================================
| ======== |
| |
,-----------------------------.| |
|Code: POST (2) || |
|Content-Format: CBOR ||1 POST: Access REQ |
|URI-Path: authorize ||------------------>|
|Payload:{SAMInformationMsg, || |
|SAIURI,SAIOperations} || |
`-----------------------------'| |
| | ,-----------------------------.
| 2 2.01 | |Code: Content |
|<------------------| |content-type:application/cbor|
| | |Payload:{TicketTransferMSG} |
| | `-----------------------------'
| |
| ======== |
========================================== DTLS ===================================
| ======== |
,+. ,-+-.
|C| |SAM|
`-' `---'
Figure 5: Access Request and Ticket Transfer Message (TTM)
The Ticket Transfer Message (TTM) contains the token and other
information based on which we show how the Proof-of-Possession (PoP)
token can be generated.
6.6.1. Construction of Token and Ticket Transfer Message
This sub-section describes how the SAM generates the token for the
request made by C and how it is enclosed within the Ticket Transfer
Message (TTM) which is sent to C. The PoP token is constructed using
HMAC algorithm instead of encryption as described in [I-D.ietf-oauth-
pop-architecture].
A token is generated with the following data-structure:
o FaceData: SAI, timestamp, time-to-live, E, random
Cuellar, et al. Expires October 21, 2016 [Page 20]
Internet-Draft PAT for Authorization in ACE 02 April 2016
* SAI: server authorization information (SAI) contains resource
server URI with allowed permissions
* timestamp: contains the time when this FaceData is created
* time-to-live: lifetime (optional) and it is used to limit the
validity of the access tickets
* E: the Encryption Algorithm that should be used to encrypt the
payload that C is sending to S (optional) (will be described in
future I.D of this draft); we propose to use
ChaCha20_Poly1305_AEAD as the authenticated encryption
algorithm as it is secure and efficient in resource constrained
environments [RFC7539]
* random: random seed on the token such that we make FaceData
non-deterministic, this random number can be generated by any
Pseudo-Random-Generator. Also The FaceData can be optionally
be encoded in CBOR format.
o Verifier: G (K, FaceData) Notice that G takes two parameters (key,
data) as input and produced a keyed digest as the output
* K: the shared key between the SAM and the resource server (S)
* G: the HMAC algorithm which is used to create the verifier, we
propose to use the Poly1305 [RFC7539]
o Face: FaceData, G (K, Verifier)
* FaceData: it is obtained from the previous step
* K: the shared key between the SAM and the resource server (S)
* Verifier: obtained from the previous step
o Ticket Transfer Message (TTM): Face, Verifier
* Face: what we obtained from previous step
* Verifier: what we obtained from previous step
Notice that the Ticket transfer message and the verifier MUST be sent
to the C through a secure channel. The client will use the Verifier
as the key material to generate further keys to communicate with the
Server.
Cuellar, et al. Expires October 21, 2016 [Page 21]
Internet-Draft PAT for Authorization in ACE 02 April 2016
6.7. [C->S] Authorized Resource Request
Once the C has the TTM from SAM it performs a resource request
message to S, in this case with a valid access token. In this
alternative protocol flow, it is not required to create a secure
channel between C and S. The S only verifies if the request from C
is valid and if it is valid sends a valid response. Optionally, the
S can encrypt the response back to C from the common secret extracted
from the Request message.
For example, if C performs a CoAP GET() request, then C does not have
any payload to encrypt. In a CoAP POST() request the C might need to
encrypt the payload.
In the second case, where the C needs to encrypt the payload. The C
prepares the authorized resource request message by the encrypting
the "payload" using encryption algorithm described in FaceData option
E (ChaCha20_Poly1305_AEAD authenticated encryption mechanism) and
uses the Verifier as the key.
The resource request message is constructed as the following:
Request Message:{ CoAP request: request type {GET/POST}, Message ID
(MID) Face: FaceData, HMAC (K, Verifier) MSG_PAYLOAD:
ChaCha20_Poly1305_AEAD(Verifier,nonce = MID, AAD=null, payload) }
As Verifier was generated from the FaceData which is enclosed in the
Face, which is sent to the S, the S should be able to extract the
Verifier as it knows the common secret key K (shared between S and
SAM).
6.8. [S->C] Valid Response
When the S receives a resource request from a C, the S checks for
following before sending a valid response to C:
o look for access ticket in the request message
* is access ticket has valid hash
* is access ticket valid for server
* is access ticket valid for resource
* is ticket timestamp valid
If any one of the verification is not successful, then S responds to
C with Unauthorized resource request with SAI information. If all
Cuellar, et al. Expires October 21, 2016 [Page 22]
Internet-Draft PAT for Authorization in ACE 02 April 2016
the above verifications are successful, then S performs the action
requested and response message generated. Optionally, the response
is encrypted with the Verifier obtained from the access ticket, thus
only the C with the valid Verifier can read the response.
Notice that from the request message, S is able to extract the
Verifier and can validate the following:
o The verifier is first validated by comparing the HMAC (K,
FaceData).
o Later the FaceData is validated by HMAC (Verifier, FaceData)
After validating the Verifier and FaceData, the S extract the payload
and prepares the necessary response. The optional encrypted response
can be generated as:
Response Message:{ CoAP request: request type {GET/POST}, Message ID
(MID) RSP_MSG_PAYLOAD: ChaCha20_Poly1305_AEAD (Key=Verifier, nonce =
MID+1, AAD=null, payload) }
Notice the difference in the nonce parameter. The MID is incremented
to avoid using the same key for encrypting twice.
The Figure 6, shows Authorized resource request from C->S and
response message S->C.
,-. ,-.
|C| |S|
`+' `+'
,----------------------------.| |
|Code: POST (2) || |
|URI-Path: test ||1 POST: Auth REQ |
|token: Face ||---------------->|
|Payload:{Enc(key=Verifier, || |
|nonce=MID, AAD=null, || |
|payload_data)} || |
`----------------------------'| |
| | ,-------------------------.
| 2 2.05 | |Code: Content |
|<----------------| |Payload:{Enc(key=Verifier|
| | |nonce=MID+1, AAD=null, |
| | |response_data)} |
,+. ,+.`-------------------------'
|C| |S|
`-' `-'
Figure 6: [C<->S] Authorized Resource Request and Response
Cuellar, et al. Expires October 21, 2016 [Page 23]
Internet-Draft PAT for Authorization in ACE 02 April 2016
7. Formal Syntax
tbd
8. Security Considerations
tbd
9. IANA Considerations
tbd.
10. Conclusions
tbd
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7252] Shelby,
Z., Hartke, K. and Borman, C., "The Constrained Application Protocol
(CoAP)", RFC 7252, June 2014.
[RFC6347] Rescorla E. and Modadugu N., "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC4279] Eronen P. and Tschofenig H., "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", RFC 4279, December 2005.
[RFC7539] Y. Nir and A. Langley: ChaCha20 and Poly1305 for IETF
Protocols, RFC7539, May 2015
[I-D.cuellar-ace-solutions] S. Gerdes, J. Cuellar and O. Bergmann:
Solutions for the authorization in constrained environments, draft-
cuellar-ace-solutions-00 (work in progress), October 2015.
[I-D.gerdes-ace-a2a] Gerdes S., "Managing the Authorization to
Authorize in the Lifecycle of a Constrained Device", draft-gerdes-
ace-a2a-00 (work in progress), September 2015.
[I-D.gerdes-ace-actors] Gerdes, S., "Actors in the ACE Architecture",
draft-gerdes-ace-actors-05 (work in progress), October 2015.
[I-D.gerdes-ace-dcaf-authorize] Gerdes, S., Bergmann, O., and Bormann
C., "Delegated CoAP Authentication and Authorization Framework
Cuellar, et al. Expires October 21, 2016 [Page 24]
Internet-Draft PAT for Authorization in ACE 02 April 2016
(DCAF)", draft-gerdes-ace-dcaf- authorize-02 (work in progress),
September 2015.
[I-D.ietf-core-resource-directory] Shelby Z. and Bormann C., "CoRE
Resource Directory", draft-ietf-core-resource-directory-02 (work in
progress), November 2014.
[I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W.,
Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP)
Security Architecture", draft-ietf-oauth-pop-architecture-07 (work in
progress), December 2015.
11.2. Informative References
[KoMa2014] Kohnstamm, J. and Madhub, D., "Mauritius Declaration on
the Internet of Things", 36th International Conference of Data
Protection and Privacy Comissioners, October 2014.
12. Acknowledgement
This draft is the result of collaborative research in the RERUM EU
funded project and has been partly funded by the European Commission
(Contract No. 609094).
13. Appendix
13.1. Copyright Statement
Copyright (c) 2015 IETF Trust and the persons identified as authors
of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, is permitted pursuant to, and subject to the license
terms contained in, the Simplified BSD License set forth in
Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
Documents <http://trustee.ietf.org/license-info)>.
Authors' Addresses
Jorge Cuellar
Siemens AG
Otto-Hahn-Ring 6
Munich, Germany 81739
Email: jorge.cuellar@siemens.com
Cuellar, et al. Expires October 21, 2016 [Page 25]
Internet-Draft PAT for Authorization in ACE 02 April 2016
Prabhakaran Kasinathan
Siemens AG
Otto-Hahn-Ring 6
Munich, Germany 81739
Email: prabhakaran.kasinathan@siemens.com
Daniel Calvo
Atos Research and Innovation
Poligono Industrial Candina
Santander, Spain 39011
Email: daniel.calvo@atos.net
Cuellar, et al. Expires October 21, 2016 [Page 26]