ACE Working Group J. Cuellar
Internet-Draft P. Kasinathan
Intended status: Standards Track Siemens AG
Expires: July 2, 2017 D. Calvo
Atos Research and Innovation
December 29, 2016
Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-04
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.
This memo also specifies a profile for ACE framework for
Authentication and Authorization for constrained environments. This
draft uses CBOR Web Token (CWT) and CBOR Object Signing and
Encryption (COSE) to encode PAT messages.
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 July 2, 2017.
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
Cuellar, et al. Expires July 2, 2017 [Page 1]
Internet-Draft PAT profile of ACE 04 December 2016
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RS<-> AS: Security-association-Setup . . . . . . . . . . 8
4.2. [C->RS : Resource-Request] . . . . . . . . . . . . . . . 9
4.3. [RS->C : Un-Authorized-Request(AS-Info)] . . . . . . . . 9
4.4. C<->AS : Security-Association-Setup . . . . . . . . . . . 11
4.5. C->AS : Access-Request . . . . . . . . . . . . . . . . . 11
4.6. C<-AS : Access-Response . . . . . . . . . . . . . . . . . 12
4.7. C->RS : Resource-Request . . . . . . . . . . . . . . . . 15
4.8. RS->C : Resource-Response . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24
9. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1. ACE profile Registration . . . . . . . . . . . . . . . . 24
9.2. Copyright Statement . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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
[draft-ietf-ace-actors], [I-D.ietf-ace-oauth-authz] and [KoMa2014].
This memo 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 and
provide authentication. Moreover, the construction can be used to
offer user consent (in the sense of privacy) and to dynamically
Cuellar, et al. Expires July 2, 2017 [Page 2]
Internet-Draft PAT profile of ACE 04 December 2016
create pseudonyms to enhance the unlinkability of the information,
see section [Features] below.
This draft uses the architecture of [draft-ietf-ace-actors] and [I-
D.ietf-ace-oauth-authz], designed to help constrained nodes in
authorization-related tasks via less-constrained nodes. Terminology
for constrained nodes is described in [RFC7228]. 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 Server. This memo also specifies a profile for ACE
framework (Authentication and Authorization for constrained
environments).
One of the goal of PAT is to securely transmit authorization tokens.
A by-product is the set-up of a Datagram Transport Layer Security
(DTLS) [RFC6347] channel with symmetric pre-shared keys (PSK)
[RFC4279] between two nodes. The main goal of the PAT is to present
methods for constructing authorization tokens and to securely
transmit them to the parties involved with privacy features such as
unlinkability. The CoAP protocol [RFC7252] is used as the
application layer protocol together with CWT.
Note that DTLS channel [I.D-draft-gerdes-ace-dtls-authorize] or
Object security of CoAP (OSCOAP) [I-D.selander-ace-object-security]
can be used 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.
Further details will be presented in future versions of this draft.
2. Terminology
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 [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.
Terminology for entities in the architecture is defined in OAuth 2.0
[RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource
server (RS), resource owner (RO), resources (R) and authorization
server (AS).
In addition to the terms defined in [I-D.ietf-ace-actors], we use
additionally the following terms:
Cuellar, et al. Expires July 2, 2017 [Page 3]
Internet-Draft PAT profile of ACE 04 December 2016
o Client Token (CT): The token which is generated by the AS for the
Client. It contains a secret, which can be used to generate the
Token, plus other data used for "Proof-of-Possesion" (PoP).
Optionally CT may contain authorization information that
represents RO's authorization policies for C. Note: this Client
Token is not to be confused with the tentative Client Token
introduced in [I-D.ietf-ace-oauth-authz].
o Access-Token (AT): The token which is generated by the Client and
presented by him to the RS to access the resources (R) on RS. It
contains a secret, which changes regularly (in a similar way to
one-time passwords). The AT contains all information needed by
the RS to verify that it was granted by AS. Note: this access-
token is different from the access token described in [I-D.ietf-
ace-oauth-authz] which is generated by AS and sent to C.
In future versions of this draft, the differences in token names and
its purposes will be harmonized with [I-D.ietf-ace-oauth-authz].
3. Overview
This specification defines the PAT protocol and the PAT profile for
ACE framework for authorization in the Internet of Things
environment. The PAT protocol is built around the building blocks
described in [I-D.ietf-ace-oauth-authz].
In this specification we assume the following:
o a Resource Server (RS) has one or more resources (R) and is
registered with an Authorization Server (AS)
o the Authorization Server (AS) provides the authentication and
authorization for the RS. The corresponding Resource Owner (RO)
of the RS has set permissions in AS for allowed Clients.
o a Client (C) is either registered with an AS or it knows how to
reach the RS for accessing the required resource.
o to access a resource on a Resource Server RS, a Client (C) should
request a token from AS, either directly or using its Client
Authorization Server (CAS). For the sake of better understanding,
this memo does not include the CAS actor.
For instance, the C may or may not know the corresponding AS to
request a CT for the resource it would like to access from RS. Based
on the knowledge C has, the first message from C can be either to RS
or to AS. This draft assumes that RS is offline after commissioning,
Cuellar, et al. Expires July 2, 2017 [Page 4]
Internet-Draft PAT profile of ACE 04 December 2016
i.e., RS cannot make any introspective queries to the AS to verify
the authorization information provided by the C.
Based on the above assumption, the simple message flow can be
described as follows: a C may request a resource on RS without valid
access token, the RS will reject and may provide AS information to
the C. Then C may perform an Access-Request to AS for the required
resource on RS. Then AS decides if C is allowed to access the
resource or not based on permissions set by the RO. If so, AS
generates a Client-Token (CT) used for the authorization with the
symmetric proof-of-possession key between AS and RS. The C uses CT
to construct Access-Token (AT) through which a security context (PAT
secret) can be established between C and RS.
3.1. Features
o The method allows a User, or an Authentication/Authorization
Server (AS) on its behalf, to authorize one or several clients to
access resources (R) on a RS. The client and/or the Resource
server can be constrained devices. The authorization is
implemented by distributing purpose-built Key Material (which we
generically call "Tokens") to the RS and C. This SHOULD be done
by secure channels.
o The Client Tokens are crafted in such a way that the client can
construct authorization tokens that allow them to demonstrate to
RS its authorization claims. The message exchange between C and
RS for the presentation of the tokens MAY be performed via
insecure channels.
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 can be treated separately via other methods.
o The tokens are supported by a "proof-of-possession" (PoP) method.
PoP allows an authorized entity (a client) to prove to the
Cuellar, et al. Expires July 2, 2017 [Page 5]
Internet-Draft PAT profile of ACE 04 December 2016
verifier (here, the RS), 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 RS 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 RS. This can be
used to provide consent (in terms of privacy) from users (again,
ROs).
o To be coherent with ACE Authorization framework [I-D.ietf-ace-
oauth-authz], this draft also specifies an ACE profile to use PAT
and for efficient encoding it uses CWT and COSE. The PAT profile
is signalled when the C requests token from the AS.
In short, the PAT protocol presents as the most important 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
o Specifies an ACE profile to cohere with ACE framework
4. Protocol overview
The PAT protocol includes three actors: the RS, the C, and the AS.
The PAT message flow is shown in Figure 1. Messages in [square
brackets] mean they are optional.
Cuellar, et al. Expires July 2, 2017 [Page 6]
Internet-Draft PAT profile of ACE 04 December 2016
,-. ,--. ,--.
|C| |RS| |AS|
`+' `+-' `+-'
| | 1 Security-Association-Setup|
| | <--------------------------->
| | |
| 2 [Resource-REQ] | |
|------------------------> |
| | |
|3 [Un-Auth-REQ(AS-Info)]| |
|<------------------------ |
| | |
| 4 Security-Association-Setup |
|<----------------------------------------------------->
| | |
| 5 Access-REQ |
|------------------------------------------------------>
| | |
| 6 Access-RSP |
|<------------------------------------------------------
| | |
| 7 Resource-REQ | |
|------------------------> |
| | |
| 8 Resource-RSP | |
|<------------------------ |
,+. ,+-. ,+-.
|C| |RS| |AS|
`-' `--' `--'
Figure 1: PAT protocol message flow
The AS and RS share a long term secret (K). To determine AS which in
charge of a resource hosted at the RS, C MAY send an initial
Resource-Request without valid access token to RS. RS denies the
request without valid access token and could possibly include the
address of its AS (AS-Info) to C in the response. Or, instead of the
initial Resource-Request without valid access token, C MAY look up
the desired resource in a resource directory as described in [I-
D.ietf-core-resource-directory] that lists the available resources.
Once C knows AS's address, it can send an Access-Request for
authorization to AS (directly, or indirectly using its own CAS). If
the access is to be authorized, AS generates an Access-Request
Response to C. It contains client token and a symmetric PoP key (the
verifier) which is necessary for the C to create valid access tokens
for RS.
Cuellar, et al. Expires July 2, 2017 [Page 7]
Internet-Draft PAT profile of ACE 04 December 2016
Each time C sends RS a Resource-Request, it generates and presents an
Access-Token to RS to prove its right to access. If the access-token
is valid, RS sends a Resource-Response to the C. Later with the
common established secret C and RS can generate derived keys which
are described later in the draft.
The following section describes the message flow in more detail,
especially how the messages, tokens are constructed and how RS and C
can use their common knowledge i.e., initial PAT secret to verify the
authenticity of the ATs.
Further, C and RS may derive keys from the initial PAT secret:
o VerifK: to verify that C and RS are talking with the intended
partner, for the Client C it is used as Proof of Possession of the
Access-Token
o PSK: as a symmetric Key to establish a DTLS secure channel or for
other purposes (by product of PAT)
o IntK: for Integrity protection (in message authentication codes)
o ConfK: for Confidentiality Protection (to be elaborated in a
future version of the document).
As CoAP [RFC7252] is the recommended application layer protocol for
constrained devices, the PAT protocol is designed to work with CoAP.
The following notation:
A -> B : <Msg_Name>
represents the message with name Msg_Name, sent from A to B.
4.1. RS<-> AS: Security-association-Setup
This memo assumes that the Resource Server RS and its Authentication
Server AS share a secure channel and share a long term shared secret,
i.e., a shared key (K), which MAY be implemented via USB (and
physical security) or when commissioning the devices or by other
means (out of scope). The shared secret (K) is used both by the AS
and the RS to create a proof-of-possession keys (verifiers).
It must be stressed that the security of the protocol strongly
depends on how secure this channel is. We can also assume that the
CAS and AS share a secure connection, say over DTLS if CAS exist as
an actor.
Cuellar, et al. Expires July 2, 2017 [Page 8]
Internet-Draft PAT profile of ACE 04 December 2016
Also, during this process RS registers the cryptographic algorithms
and parameters it can support validating the access-tokens for
authorization. The internal clock of RS can be synchronized with the
AS during the commissioning phase. How this time synchronization is
refreshed will be discussed in the future version of this draft.
4.2. [C->RS : Resource-Request]
Initially, a C may not have a valid access token to access a
protected resource hosted in RS or the corresponding AS-information
from which it needs to get the authorization token. In this
scenario, the Client may send a Resource-Request message to RS
without valid access-token.
To enable resource discovery, RS may expose the URI "/.well-known/
core" [RFC6690], but this resource itself MAY be protected. Thus, to
discover the resources available on RS, the C can optionally make a
CoAP GET request to the URI "/.well-known/core". As with any other
unauthorized GET request, the Client C is asked to access the AS.
4.3. [RS->C : Un-Authorized-Request(AS-Info)]
Once RS receives a request from a C, it checks the following:
o If C does not have valid access token, then RS MUST respond to C
with 4.01 (Unauthorized request). Optionally, RS may include
information about AS (AS-Info) which includes additional
information (AS address) to reach /token endpoint exposed by the
AS. Note: this message is sent to any unauthorized Client,
therefore it is recommended to include as less information as
possible to identify AS.
o If C has a valid access token, but not for the requested resource
then RS MUST respond with 4.03 (Forbidden)
o If C has a valid access token, but not for the method requested
then RS MUST respond with 4.05 (Method Not Allowed)
Figure 2 shows the sequence of messages with detailed CoAP types
between C and RS for the above Unauthorized resource request:
Cuellar, et al. Expires July 2, 2017 [Page 9]
Internet-Draft PAT profile of ACE 04 December 2016
,-. ,--.
|C| |RS|
`+' `+-'
| | ,---------------------------.
| 1 Res-REQ | |Header:GET |
|----------->| |Type:Confirmable |
| | |URI-Path:.well-known/core |
| | `---------------------------'
| | ,---------------------------.
| | |Header: 4.01 Unauthorized |
| 2 Res-RSP | |Type: Acknowledgement |
|<-----------| |content-type: |
| | |application/cbor |
| | |Payload:{AS-Info,params} |
,+. ,+-.`---------------------------'
|C| |RS|
`-' `--'
Figure 2: C<->RS Resource-Request and Unauthorized as response
TBD: together with AS-Info, the RS may also send params. To mitigate
attacks based on time synchronization the Lightweight Authenticated
Time (LATe) synchronization protocol for constrained environments as
described in [I.D-draft-navas-ace-secure-time-synchronization].
Figure 3 shows an example of the response message sent by RS to C
encoded using CBOR [RFC7049] with pat-type="UnAuthReq". The response
message might include key-reference ID of the shared secret between
RS and AS, nonce to prevent replay attacks of C. Further, in the
next versions of the draft time synchronization draft will be studied
and adopted if necessary. Examples of binary encoded representations
will available in the next versions of this draft.
Header: 4.01 (Unauthorized)
Content-Type: application/cbor+pat;
pat-type="UnAuthReq"
Payload:
{#Unprotected
AS-Info: "coaps://as.example.com/token",
params:
{
TBD: { ... }
}
}
Figure 3: AS information payload example
Cuellar, et al. Expires July 2, 2017 [Page 10]
Internet-Draft PAT profile of ACE 04 December 2016
4.4. C<->AS : Security-Association-Setup
If C is registered with the AS as described in [I-D.ietf.ace-oauth-
authz] or after C receives AS-Info, the C or CAS (if involved) MUST
establish a secure connection channel with the AS.
o The AS may have an access control list defined by the RO for the
clients, with that AS can verify if the client is allowed to
establish a secure connection or not. The methods to implement
access control in this regard are out of scope of this memo.
o If the client has valid access to the resource in RS, then AS
establishes a confidential channel with C. How this secure
connection (example: a DTLS channel) should be established is out
of scope of this memo.
Notice that, it is important to ensure that this connection is
reliable and secure as the remainder of this protocol relies on the
fact that the messages exchanged between C and AS are protected and
confidential.
4.5. C->AS : Access-Request
Once C establishes a secure communication channel with AS, C sends an
access-request (ACC-REQ) message to AS to the endpoint /token
requesting an access token for RS as described in [I-D.ietf.ace-
oauth-authz].
Optionally, the C includes the details about the resources (R) or the
corresponding URI with operations it needs to access or perform on RS
to AS as part of the Access-Request Message, if not AS should prepare
an access token with default permissions. Fine grained access to
resources (R) of RS depends on the infrastructure or services the RS
offers. For example, if RS exposes different resources such as
temperature and humidity, a generic token may be granted by AS to C
to access both resources on RS. On the other hand, the application
developer or administrator may decide to have fine grained
(different) tokens for each resource.
Figure 4 shows an access-request from C for a token to AS. The "aud"
represents a specific resource R ("tempSensor") and "scope"
represents the allowed actions that C is requesting to perform on the
requested resource R as described in [I-D.ietf-ace-oauth-authz] using
CWT [I-D.ietf-ace-cbor-web-token]. The Scope parameter can be
designed based on application requirements i.e., it can be "read" or
"write" or methods such as "GET|POST" etc. Note that we assume a
DTLS-based communication defined in the DTLS profile [I.D-draft-
gerdes-ace-dtls-authorize] for this example.
Cuellar, et al. Expires July 2, 2017 [Page 11]
Internet-Draft PAT profile of ACE 04 December 2016
How the client is authenticating itself to the AS is out of scope of
this draft, but in the following example the client presents its
credentials i.e., password based authentication by presenting its
client_secret (see section 2.3.1. of [RFC6749]).
Header: POST (Code=0.02)
Uri-Host: "coaps://as.example.com"
Uri-Path: "token"
Content-Type: "application/cbor+cwt"
Payload:
{
"grant_type" : "client_credentials",
"client_id": "client123",
"client_secret": "Secret123",
"aud" : "tempSensor",
"scope": "GET|POST",
... omitted for brevity ...
}
Figure 4: Example Client Access-Request message to AS
4.6. C<-AS : Access-Response
When AS receives an access-request from a C, AS validates and
performs the following:
o If the access request from C is valid, AS sends the Client-Token
CT with COAP response code 2.01 (Created).
o If the client request is invalid, or does not include required
parameters such as "aud" or "cnf", then AS MUST send appropriate
COAP error response code as specified in [I-D.ietf-ace-oauth-
authz].
The Figure 5 shows the Access request from C to AS and the access-
response from AS to C.
Cuellar, et al. Expires July 2, 2017 [Page 12]
Internet-Draft PAT profile of ACE 04 December 2016
,-. ,--.
|C| |AS|
`+' `+-'
| 1 DTLS |
|<----------->
| |
| | ,------------------------.
| | |Header:POST(code=0.02) |
|2 Access-REQ| |content-type: |
|------------> |application/cbor |
| | |URI-Path: token |
| | |Payload:{ACC-REQ} |
| | `------------------------'
| | ,-----------------------------.
|3 Access-RSP| |Header: Created (code=2.01) |
|<------------ |content-type: |
| | |application/cbor |
| | |Payload:{ACC-RSP} |
,+. ,+-.`-----------------------------'
|C| |AS|
`-' `--'
Figure 5: Access-Request and Access-Response
The Access Request payload is already shown in Figure 4. How AS
constructs the Client-Token (CT) and the verifier (the symmetric PoP
key) for the C is described in the following:
The contents of the access-response (ACC-RSP) payload is logically
spit into two major parts, the Client-Token (CT) and the Verifier
(Symmetric PoP key). When the Client makes the authorized request to
RS, the C will not send the verifier, but only the Client-Token with
some additional parameters such as AuthenticationHash to prove RS
that C holds the proof-of-possession (PoP) key.
The Verifier is constructed in such a way that with the Client-Token
the RS is able to construct the Verifier with the shared key (K)
between AS and RS.
Client-Token construction:
o Client-Token is constructed using the CWT claim parameters by AS
* "aud" It contains the resource server URI
* "scope" (application specific) allowed methods such as GET,
POST, PUT or DELETE or permissions such as "read" or "write"
Cuellar, et al. Expires July 2, 2017 [Page 13]
Internet-Draft PAT profile of ACE 04 December 2016
* "iat" timestamp of AS: token issued
* "iss" issuer: AS identity
* "exp" token expires after this many seconds
* "cti" CWT ID should be unique for every Client-Token can be a
sequence number
* TBD:".."
Verifier construction:
o Verifier (Symmetric PoP key): G (K, Client-Token)
* G: the MAC algorithm which is used to create the verifier, we
propose Poly1305 [RFC7539]. Notice that G is a function which
takes two parameters (key, data) as input and produces a keyed
digest as the output
* K: the shared key between AS and RS
* Client-Token: constructed using CWT claims as explained before
Important Note:
o The Access-Response message with the verifier MUST be sent to C
through a secure channel.
o The Client will use the Verifier as the key material (symmetric
PoP key) to communicate with the RS
o The time-synchronization between AS and RS may be implemented
based on the application requirements using [I.D-draft-navas-ace-
secure-time-synchronization] or other methods and is out of scope
of this draft.
Figure 6 shows the example Access-Response from AS to C after
successful validation of C's credentials presented in Access-Request
message by C. The AS MUST include client_token, the verifier encoded
in COSE-key using "cnf" parameter. The AS should specify required
parameters as described in [I-D.ietf-ace-oauth-authz] such as the
type of token, etc. Also, if the Access-Request from C does not
include any profile, AS MUST signal the C to use appropriate or
default profile that RS uses in the Access-Response payload.
Cuellar, et al. Expires July 2, 2017 [Page 14]
Internet-Draft PAT profile of ACE 04 December 2016
Header: 2.01 (Created)
Content-Type: application/cbor+cwt+pat; pat-type="ct"
Location-Path: token/...
Payload:
{
"client_token": b64'SlAV32hkKG ...
{
"token_type": pop,
"aud": "tempSensor",
"scope": "read",
"seq": 1..,
"iat": 1...,
"nbf": 0...,
"cti": "..", # Unique can be a Sequence Number
"exp": 5...,
"alg": "chacha20/poly1305",
"profile": "ace_pat"
}
"cnf":
{
COSE_Key: {
"kty": "symmetric",
"kid": h'...
"k": b64'jb3yjn... #[verifier]
}
}
optional(TBD):{
"LATE time sync"
}
}
Figure 6: Example Access-Response message from AS to C
with detailed CWT params and payload info
4.7. C->RS : Resource-Request
Once C receives the Access-Response from AS, C can construct an
Access-Token (AT) which will demonstrate that C has got the
authorization to access resources (R) in RS. The message Resource-
Request (RES-REQ) with new AT has to be sent afresh: Client C has to
renew his Authorization status at the Resource Server.
The frequency in which the Client has to send a new AT can be
enforced by RS and is determined indirectly by the owner of RS (or by
AS). This allows a fine-grained control on the service level that
the Resource Server will provide to the Client (for instance, on the
amount of information of sensor data)
Cuellar, et al. Expires July 2, 2017 [Page 15]
Internet-Draft PAT profile of ACE 04 December 2016
Each time a RES-REQ is sent from C to RS, a new Access-Token (AT) MAY
be needed. Optionally, communications between C and RS can be
encrypted to protect the payload and to enforce confidentiality if
necessary. PAT profile provides necessary recommendations by using
chach20/poly1305 AEAD algorithm.
o For example if C performs:
* a CoAP GET() or any other request without any payload may be
unprotected. Note: the request from C MAY be unprotected, but
the response from RS with payload MUST be always protected and
only the valid C can decrypt the response.
* a CoAP POST() or a CoAP PUT() or a CoAP DELETE() request with
payload MUST be protected by using AEAD algorithm presented in
Client Token (CT). We propose to use ChaCha20-Poly1305-AEAD
authenticated encryption mechanism, while using the Verifier
(symmetric PoP key) as the key and a nonce, the
AuthenticationHash MAY be integrity protected by using it as
Additional Authentication Data (AAD).
The RS MUST implement /authz-info endpoint to allow any Client to
transfer the access-token as described in [I-D.ietf-ace-oauth-authz].
The Resource-Request message with valid Access-Token shall be
constructed by C and can be transported to RS in one of the following
ways:
option1:
Request Message:{
CoAP request: POST
endpoint: /authz-info
payload:{
Access-Token:{ Client-Token,
AuthenticationHash=Hash(verifier+nonce)
}
}
Figure 7: option1: RES-REQ using /authz-info implemented at RS
o Figure 7 shows the option1 that specifies the endpoint /authz-info
implemented at RS as described in [I-D.ietf-ace-oauth-authz], this
option enables the C to transport the access-token to the RS.
After receiving the request, RS verifies the access-token, if the
access-token is valid a security context is established between RS
and C using the verifier. With verifier (a shared symmetric
secret) a DTLS channel or OSCOAP or native PAT methods could be
used to establish a secure channel between RS and C. Note: more
Cuellar, et al. Expires July 2, 2017 [Page 16]
Internet-Draft PAT profile of ACE 04 December 2016
details about native PAT methods will be presented in future
versions of this draft.
o Figure 8 presents representation of POST resource-request from C
to RS described in [I-D.ietf-ace-oauth-authz] with pat-
type="AuthReq".
Header: POST (Code=0.02)
Content-Type: application/cose+cbor+pat;
pat-type="AuthReq";
Uri-Host: "coap://rs.example"
Uri-Path: /authz-info
Payload:
{ # Unprotected
access_token: {
"client_token": b64'SlAV32hkKG {
"aud": "tempSensor"
"scope": "read"
... CWT omitted for brevity.
}
"nonce": "C_nonce"
"auth_hash": b64'v4Sugr7.. #[Hash=(verifier+nonce)]
}
}
Figure 8: Example of valid option1 request from C to RS
using endpoint /authz-info.
option2:
Request Message:{
CoAP request: GET/POST/PUT/DELETE
Access-Token: Client-Token,
AuthenticationHash= Hash(verifier+C_nonce)
MSG_PAYLOAD: Chach20/Poly1305(Verifier,C_nonce,
AAD=null, payload)
}
Figure 9: Example of option2 RES-REQ with native
PAT token transfer method
o Figure 9 shows the alternative native PAT method for transporting
the tokens from C to RS. In the example presented, the C may
request the known URI path where the resource is available with
the access-token which includes the Client-Token and the
AuthenticationHash which is the result of the Hash function of
(verifier + the C_nonce). TBD: if a CoAP message does not have
Cuellar, et al. Expires July 2, 2017 [Page 17]
Internet-Draft PAT profile of ACE 04 December 2016
any payload to carry, the access token shall be presented to RS
using CoAP option.
o Figure 10 shows the detailed description of the option2 PAT method
to transfer access-tokens from C to RS. In the presented example,
the Uri-Path "/firmware" allows the authorized client to perform
firmware upgrade on the RS. PAT recommends to protect sensitive
information payload using chacha20/poly1305 AEAD algorithm and the
symmetric PoP key (the Verifier), the result will generate a
Cipher text and a tag which is enclosed in the payload. TBD: as
part of additional authenticated data (AAD) the client may include
"auth_hash".
Header: POST (Code=0.02)
Content-Type: application/cose+cbor+pat;
cose-type="encrypt0";
"pat-type="AuthReq";
Uri-Host: "coap://rs.example"
Uri-Path: /firmware
Payload:
{# COSE Unprotected
access_token: {
"client_token": b64'SlAV32hkKG {
"aud": "firmwareUpd"
"scope": "write"
... CWT omitted for brevity,
}
"nonce": .. # C_nonce
"auth_hash": h'bfa03.. #[Hash=(verifier+nonce)]
}
# COSE_Encrypt0 + COSE_MAC0 Protected
ciphertext:{
#Chacha20/Poly1305 AEAD payload using
# key=verifier,
# nonce=C_nonce,
# AAD=auth_hash
h'....omitted for brevity
},
tag: h'... omitted for brevity
}
Figure 10: Example of valid POST request from C to RS
4.8. RS->C : Resource-Response
When the request with access-token arrives the RS from a C, RS MUST
evaluate the resource request and its access-token in the following
order:
Cuellar, et al. Expires July 2, 2017 [Page 18]
Internet-Draft PAT profile of ACE 04 December 2016
o Step1: extract the client-token, nonce and AuthenticationHash from
the access-token.
o Step1.1: (if available) verify the freshness of the sequence
number in the client token presented by AS.
o Step2: generate the verifier by computing MAC(K, client-token)
where K is shared key between AS and RS.
o Step2.1: compute verificationHash as Hash(verifier+nonce) and
compare the result with AuthenticationHash.
o Step3: check if the client-token has right CWT parameters such as
"aud", "scope", "exp", "nbf", etc for the requested resource or
action to be performed.
o Step4: TBD: (if available) synchronize RS internal clock with AS
as described in [I.D-draft-navas-ace-secure-time-synchronization]
Response to request option1:
When RS receives resource-request from a C of type option1, RS
validates the access-token as described above,
o If the access-token is valid, the RS MUST respond to the POST
request with code 2.04 (changed).
o If the access-token is invalid, then RS MUST respond to the POST
request with code 4.01 (Unauthorized)
Figure 11 shows an example of successful request and response for
option1 to the endpoint /authz-info implemented in RS, RS should
maintain a security context to enable subsequent communication
channel with RS. RS could establish a secure channel with the
initial PAT secret (the Verifier) i.e., the symmetric PoP key between
C and RS using the DTLS profile described in [I.D-draft-gerdes-ace-
dtls-authorize]. Further information about other methods of
establishing secure channel will be presented in the future version
of this draft.
Cuellar, et al. Expires July 2, 2017 [Page 19]
Internet-Draft PAT profile of ACE 04 December 2016
,-. ,--.
|C| |RS|
`+' `+-'
| | ,-----------------------------.
| | |Code: POST |
| 1 Res-REQ | |URI-Path: /authz-info |
|----------->| |Payload:{ |
| | |access-token:{client-token, |
| | | auth_hash |
| | | } |
| | `-----------------------------'
| 2 Res-RSP | ,----------------------.
|<-----------| |Code: 2.04 (changed) |
,+. ,+-.`----------------------'
|C| |RS|
`-' `--'
Figure 11: Example RS response to C request on /authz-info
Response to request option2: If RS receives an option2 resource-
request from C, RS should verify the following conditions before
sending a response to C:
o If the access-token is valid, the RS MUST respond to the POST
request with 2.01 (created) or 2.04 (changed).
o If the access-token is invalid, then RS MUST respond to the POST
request with code 4.01 (Unauthorized)
o If the token is valid but does not match the "aud" or resource C
is requesting for then RS MUST respond with code 4.03 (Forbidden)
If the Access-Token is valid for every condition, then RS prepares a
valid response. If request message's payload is encrypted, RS
decrypts it using ChaCha20/Poly1305 AEAD algorithm using
(key=verifier, nonce=C_nonce, AAD, payload). The response from RS
MUST be encrypted so that only C with a valid key (the Verifier or
using derived keys for subsequent messages) can decrypt the payload:
Encrypted Response payload:{
CoAP request: request type
RSP_MSG_PAYLOAD: Chach20/Poly1305(Key=verifier,
nonce = nonce++, AAD, payload)
}
Figure 12: Example of RS response payload with Encryption
for native PAT request option2
Cuellar, et al. Expires July 2, 2017 [Page 20]
Internet-Draft PAT profile of ACE 04 December 2016
Notice the difference in the nonce parameter. A difference nonce
MUST be used while encrypting the response, generally incrementing
the nonce parameter is acceptable.
Figure 13 shows Authorized resource request from C->RS and response
message RS->C.
,-. ,--.
|C| |RS|
`+' `+-'
| | ,-----------------------.
| | |Code: POST |
| | |URI-Path: /firmware |
| | |Payload: |
| | |{ |
| 1 Res-REQ | | access-token: |
|----------->| | {Client-Token, |
| | | AuthHash} |
| | | chacha20/poly1305( |
| | | key=Verifier, |
| | | nonce=C_nonce, |
| | | AAD, |
| | | data=firmware)} |
| | `-----------------------'
| | ,--------------------------.
| | |Code:2.01(Created) |
| | |Location-Path:/... |
| 2 Res-RSP | |Payload: |
|<-----------| |{ chacha20/poly1305 |
| | | (key=Verifier, |
| | | nonce=nonce++, AAD, |
| | | data=value)} |
,+. ,+-.`--------------------------'
|C| |RS|
`-' `--'
Figure 13: [C<->RS] Authorized Resource Request and Response
for native PAT request option2
Figure 14 shows the valid response from RS to C for the request type
option2 presented in previous section. The chacha20/poly1305
function produces a ciphertext and a tag. It is important to note
that "cks" means that C and RS understand the parameters for
cryptographic operations that they use for communication.
Cuellar, et al. Expires July 2, 2017 [Page 21]
Internet-Draft PAT profile of ACE 04 December 2016
Header: 2.01/2.04 (Created/Changed)
Content-Type: application/cose;
Payload:
{ cks: # COSE_Encrypt0 + COSE_MAC0 Protected
{
ciphertext:{ # Chacha20/Poly1305
# key=verifier, nonce=nonce++, payload
....omitted for brevity...
}
tag: ...omitted for brevity..
}
}
Figure 14: Example of valid response from RS to C
for native PAT request option2
5. Security Considerations
TBD
5.1. Privacy Considerations
The CoAP messaging layer parameters such as token and message-id can
be used for matching a specific request and response.
TBD
6. IANA Considerations
TBD
7. References
7.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 July 2, 2017 [Page 22]
Internet-Draft PAT profile of ACE 04 December 2016
[RFC7539] Y. Nir and A. Langley: ChaCha20 and Poly1305 for IETF
Protocols, RFC7539, May 2015
[I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C.
Bormann, "An architecture for authorization in constrained
environments", draft-ietf-ace-actors-04 (work in progress), March
2017.
[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.
[I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E.,
Erdtman, S., and H. Tschofenig, "Authorization for the Internet of
Things using OAuth 2.0", draft-ietf-ace-oauth-authz-04 (work in
progress), October 2016.
[I-D.ietf-core-object-security] Selander, G., Mattsson, J.,
Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)",
draft-ietf-core-object-security-00 (work in progress), october 2016.
[I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption
(COSE)", draft-ietf-cose-msg-24 (work in progress), November 2016.
7.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.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<http://www.rfc-editor.org/info/rfc6690>.
[I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann,
C., Van der Stok, P., "CoRE Resource Directory", draft-ietf-core-
resource-directory-08 (work in progress), July 2016.
[I.D-draft-navas-ace-secure-time-synchronization] Navas, G.,
Selander, G., Seitz, L., "Lightweight Authenticated Time (LATe)
Synchronization Protocol", draft-navas-ace-secure-time-
synchronization-00 (work in progress), October 2016.
Cuellar, et al. Expires July 2, 2017 [Page 23]
Internet-Draft PAT profile of ACE 04 December 2016
[I.D-draft-gerdes-ace-dtls-authorize] Gerdes, S., Begmann, O.,
Bormann, C., Selander, G., Seitz, L. Datagram Transport Layer
Security (DTLS) Profile for Authentication and Authorization for
Constrained Environments (ACE),draft-gerdes-ace-dtls-authorize-00,
October 2016
[I-D.ietf-ace-cbor-web-token] Jones, M., Tschofenig, H., Erdtman, S.,
CBOR Web Token (CWT), draft-ietf-ace-cbor-web-token-01 (work in
progress), July 2016.
8. 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).
The authors thank Ludwig Seitz for reviewing previous version of the
draft.
9. Appendix A
9.1. ACE profile Registration
TBD
|----------------------+-----|
| ACE profile template | PAT |
|----------------------+-----|
| Profile name | TBD |
| Profile Description | TBD |
| Profile ID | TBD |
|----------------------+-----|
Table2: ACE profile registration template
9.2. 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 July 2, 2017 [Page 24]
Internet-Draft PAT profile of ACE 04 December 2016
Authors' Addresses
Jorge Cuellar
Siemens AG
Otto-Hahn-Ring 6
Munich, Germany 81739
Email: jorge.cuellar@siemens.com
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 July 2, 2017 [Page 25]