ACE Working Group J. Cuellar
Internet-Draft P. Kasinathan
Intended status: Standards Track Siemens AG
Expires: July 6, 2018 D. Calvo
Atos Research and Innovation
January 2, 2018
Privacy-Enhanced-Tokens (PAT) profile for ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-06
Abstract
This specification defines PAT, "Privacy-Enhanced-Authorization-
Tokens", an efficient protocol and an unlinkable-token construction
procedure for client authorization in a constrained environment.
This memo also specifies a profile for ACE framework for
Authentication and Authorization. The PAT draft uses symmetric
cryptography, proof-of-possession (PoP) for a key owned by the client
that is bound to an OAuth 2.0 access-token.
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 6, 2018.
Copyright Notice
Copyright (c) 2018 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
Cuellar, et al. Expires July 6, 2018 [Page 1]
Internet-Draft PAT profile for ACE 06 January 2018
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. PAT Overview and Features . . . . . . . . . . . . . . . . . . 4
4. PAT Protocol . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. RS<->AS: Security-association-Setup . . . . . . . . . . . 7
4.2. [C->RS : Resource-Request] . . . . . . . . . . . . . . . 7
4.3. [RS->C : Un-Authorized-Request(AS-Info)] . . . . . . . . 7
4.4. C<->AS : Security-Association-Setup . . . . . . . . . . . 9
4.5. C->AS : Access-Request . . . . . . . . . . . . . . . . . 9
4.6. C<-AS : Access-Response . . . . . . . . . . . . . . . . . 11
4.6.1. Access-Token construction: . . . . . . . . . . . . . 12
4.6.2. Verifier or PoP key construction: . . . . . . . . . . 13
4.7. C->RS : Resource-Request . . . . . . . . . . . . . . . . 14
4.8. RS->C : Resource-Response . . . . . . . . . . . . . . . . 17
4.8.1. RS Response-codes to C RES-REQ: . . . . . . . . . . . 19
4.9. Construction of Derived-Tokens (DT) . . . . . . . . . . . 19
4.9.1. C->RS: Resource-Request via DT . . . . . . . . . . . 19
4.9.2. RS->C : Resource-Response to DT . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1. Normative References . . . . . . . . . . . . . . . . . . 22
7.2. Informative References . . . . . . . . . . . . . . . . . 23
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Copyright Statement . . . . . . . . . . . . . . . . . . . 23
Appendix A. ACE profile Registration . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
Three well-known problems in constrained environments are the
authorization of clients to access resources on servers, the
realization of secure communication between nodes, and the
preservation of privacy. The reader is referred for instance to [I-
D.ietf-ace-actors], [I-D.ietf-ace-oauth-authz] and [KoMa2014]. This
memo describes a way of constructing Tokens from an initial secret
that can be used by clients and resource servers (or in some cases,
more generally by arbitrary nodes) to delegate client authentication
and authorization in a constrained environment to trusted and
unconstrained authorization servers.
Cuellar, et al. Expires July 6, 2018 [Page 2]
Internet-Draft PAT profile for ACE 06 January 2018
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]. A device (Client)
that wants to access a protected resource on a constrained node
(Resource Server) first has to gain permission in the form of a token
from the Authorization Server. This memo also specifies a profile of
the ACE framework [I-D.ietf-ace-oauth-authz].
The main goal of the PAT is to present methods for constructing
authorization tokens efficiently with privacy features such as
unlinkability. The CoAP protocol [RFC7252] MAY be used as the
application layer protocol. The draft uses symmetric Proof-of-
Possession keys [I-D.ietf-oauth-pop-architecture], CBOR web tokens
(CWT) [draft-ietf-ace-cbor-web-token-05] claims to represent security
claims together with CBOR Object Signing and Encryption (COSE) [I-
D.ietf-cose-msg] and Concise Binary Object Representation (CBOR) [RFC
7049].
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 [RFC2119] 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 the authorization
server (AS).
o Access-Token (AT): the access token is a token prepared by the AS
for C. It represents the privileges granted by the RO to the C to
perform actions over the Resources (R) on an RS.
o Token (Tk): this token is prepared by the C, presented to the RS
to access the resources (R) on RS. The Tk contains all
information needed by the RS to verify that it was granted by AS.
The Client derives Tk from the AT.
In version-5 of PAT draft the token names -- AT and Tk -- and their
purposes were harmonized with [I-D.ietf-ace-oauth-authz].
Cuellar, et al. Expires July 6, 2018 [Page 3]
Internet-Draft PAT profile for ACE 06 January 2018
3. PAT Overview and Features
The PAT protocol is designed to work with ACE framework [I-D.ietf-
ace-oauth-authz] and ACE actors [I-D.ietf-ace-actors]. In this
specification we assume the following:
o A Resource Server (RS) has one or more resources (R) and it is
registered with an Authorization Server (AS)
o The Authorization Server (AS) provides access-tokens for the
clients to access resources of RS. The corresponding Resource
Owner (RO) of the RS MAY assign allowed-permissions for the
Clients in the AS.
o The RS is offline after commissioning, i.e., RS cannot make any
introspective queries to the AS to verify the authorization
information provided by the C.
o A Client (C) is either registered with an AS or it knows how to
reach the RS for accessing the required resources.
* To access a resource on a Resource Server (RS), a Client (C)
should request an access-token (AT) from AS, either directly or
using its Client Authorization Server (CAS). For the sake of
simplicity, this memo does not include the actor CAS.
Based on the above assumptions, a simple PAT message flow can be
described as follows: a C may perform a resource-request to RS
without a valid access-token, the RS will reject and it may provide
AS information to the C in the response. The C performs an Access-
Request to AS to ask for an AT that allows accessing the required
resource (R) on RS. The AS checks if C is allowed to access the
resource (R) on RS or not, based on permissions assigned by the RO.
If C has sufficient permissions, then AS generates an Access-Token
(AT) plus proof-of-possession (PoP) key bounded to the access-token
and a common secret (K) between AS and RS. AS sends both the AT and
the PoP key to C via a secure channel. How this secure channel is
created between AS and C is out of the scope of this draft. After
receiving AT and PoP key, C performs a resource-request to RS by
constructing token (Tk) from AT or by deriving Token. The RS can
construct its own version of the PoP key from the AT and verifies the
received AT. If it is valid, RS encrypts the response with the PoP
key. At the end of this phase, both C and RS has established a
common derived secret, the PoP key. Later, C can generate unlinkable
tokens (Tk) from the initial AT as described in Section 4.9.
In particular, PAT is designed to be used in contexts where
unlinkability (privacy) and efficiency are the main goals: the tokens
Cuellar, et al. Expires July 6, 2018 [Page 4]
Internet-Draft PAT profile for ACE 06 January 2018
(Tk) convey only the assurance of the authorization claims of the
clients. In particular, the procedure described in Section 4.9
enables the Tokens (Tk) to be constructed in such a way that they do
not leak information about the correspondence of messages to the same
Client or from the same access-token (AT). For example, if an
eavesdropper observes the messages from different Clients to and from
the Resource Servers, 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 from lower-layer protocols may leak some
information, and this can be treated separately via other methods.
The main features of PAT protocol are described below:
o The PAT method allows a RO, or an Authorization Server (AS) on its
behalf, to authorize one or several clients (C) to access
resources (R) on a constrained Resource Server (RS). The C can
also be constrained devices. The Access-Token (AT) response from
AS to C MUST be performed via secure channels.
o The RO is able to decide (if he wishes: in a fine-grained way)
which client under which circumstances may access the resources
exposed by the RS. This can be used to provide consent (in terms
of privacy) from RO.
o The Access-Tokens (AT) are crafted in such a way that the client
can derive Tokens (Tk) that allow demonstrating to RS its
authorization claims. The message exchange between C and RS for
the presentation of the tokens MAY be performed via insecure
channels to enforce efficiency. But the payload content -- if the
Client is performing a POST/PUT/DELETE request -- from C to RS or
the response payload from RS to C MUST be encrypted.
o The RS can derive the PoP key from the AT, which is received
attached to the Resource Request message, and it encrypts the
response using it.
o The tokens (Tk) do not provide any information about any
associated identities such as identifiers of the clients, of
access-tokens (AT) and of the resource-server.
o The tokens (Tk) are supported by a "proof-of-possession" (PoP) key
and the initial access-token (AT). The PoP key allows an
authorized entity (a client) to prove to the verifier (here, the
RS), that C is indeed the intended authorized owner of the token
and not simply the bearer of the token.
Cuellar, et al. Expires July 6, 2018 [Page 5]
Internet-Draft PAT profile for ACE 06 January 2018
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 signaled
when the C requests token from the AS or via RS in response to
unauthorized request response. The PAT profile will cover all the
requirements described in [I-D.ietf-ace-oauth-authz].
4. PAT Protocol
The detailed description of PAT protocol is presented in this
Section 4. The PAT protocol includes three actors: the RS, the C,
and the AS. PAT message flow is shown in Figure 1. Messages in
[square brackets] mean they are optional.
,-. ,--. ,--.
|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 following subsections describe the message flow in more detail,
especially how the messages and tokens with PoP are constructed.
Cuellar, et al. Expires July 6, 2018 [Page 6]
Internet-Draft PAT profile for ACE 06 January 2018
A PAT message sent from actor A to actor B is represented using the
following notation: "A -> B : Message Name"
4.1. RS<->AS: Security-association-Setup
This memo assumes that the Resource Server (RS) and its
Authentication Server (AS) share a long term shared secret (K), i.e.,
a shared key which MAY be implemented via USB (out of band methods)
when device commissioning -- out of scope --. The shared secret (K)
is used both by the AS and the RS to create proof-of-possession keys
(PoP keys or verifiers).
We can also assume that the CAS and AS share a secure connection if
CAS exist as an actor, e.g., DTLS. During the commissioning phase,
RS registers the cryptographic algorithms and the parameters it
supports. The internal clock of RS can be synchronized with the AS
during the commissioning phase. Also, PAT supports the use of
Lightweight Authenticated Time (LATe) Synchronization Protocol [I.D-
draft-navas-ace-secure-time-synchronization].
4.2. [C->RS : Resource-Request]
Initially, a C may not have a valid access-token (AT) to access a
protected resource (R) hosted in RS. The C might not also know the
corresponding AS-information to request AT from AS. In this
scenario, C may send a Resource-Request message to RS without a valid
Token (Tk).
To enable resource discovery, RS may expose the URI "/.well-known/
core" as described in [RFC6690], but this resource itself MAY be
protected. Thus, C can optionally make a CoAP GET request to the URI
"/.well-known/core".
4.3. [RS->C : Un-Authorized-Request(AS-Info)]
Once RS receives a resource request from a C, it checks:
o If C has attached a valid token (Tk) or not to the request. If C
does not have a valid token (Tk), then RS MUST respond to C with
4.01 (Unauthorized request). Optionally, RS may include
information about AS (AS-Info) which includes additional
parameters (AS address) to reach the /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)
Cuellar, et al. Expires July 6, 2018 [Page 7]
Internet-Draft PAT profile for ACE 06 January 2018
o If C has a valid access token, but not for the method requested
then RS MUST respond with 4.05 (Method Not Allowed)
o If C has a valid access token, then RS must follow the procedure
described in Section 4.8 to create a valid response to C.
Figure 2 shows the sequence of messages with detailed CoAP types
between C and RS for the above Un-Authorized-Request:
,-. ,--.
|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
The RS MAY send an Unauthorized response with additional information
such as AS-Info and parameters (params). To mitigate attacks based
on time synchronization, the Lightweight Authenticated Time (LATe)
synchronization protocol [I.D-draft-navas-ace-secure-time-
synchronization] MAY be used. In section 6.2 of [I.D-draft-navas-
ace-secure-time-synchronization] Possible Scenarios, the scenario 1.2
of suits PAT protocol, an example of it is shown in figure 3.
The response payload MAY include AS information (AS-info) and LATe
time synchronization's TIC information object such as key-reference
ID (kid) shared secret between RS and AS, a nonce to prevent replay
attacks and the message authentication codes (MAC) algorithm
[optional] used for producing the MAC. It is recommended for RS to
create a MAC tag for TIC parameters.
Figure 3 shows RS example response message to C encoded using CBOR
[RFC7049] with pat-type="UnAuthReq".
Cuellar, et al. Expires July 6, 2018 [Page 8]
Internet-Draft PAT profile for ACE 06 January 2018
Header: 4.01 (Unauthorized)
Content-Type: application/cbor+pat;
pat-type="UnAuthReq"
Payload:
{
AS-Info: "coaps://as.example.com/token",
#protected
TIC params:
{
nonce: 'rs-nonce..',
kid: '..',
[alg]: '..'
TAG: '..'
}
}
Figure 3: AS information + LATe time synchronization payload
4.4. C<->AS : Security-Association-Setup
Before sending an access-request message, C must establish a secure
channel with the AS. The C may be registered with the AS, as
described in [I-D.ietf.ace-oauth-authz] or the C MAY have received
AS-Info from RS as the answer to a previous Un-Authorized-Request.
The AS may have an access-control list defined by the RO for the
authorized clients. With this access-control list, AS can verify if
the client is allowed to establish a secure connection or not. If RO
granted enough privileges to the client to access the requested
resource (R) in RS, then AS establishes a confidential channel with
C. How this secure connection (e.g., a DTLS channel) should be
established is out of the scope of this memo.
Notice that, it is important to ensure that the connection between AS
and C MUST be reliable and secure since the PAT protocol relies on
the fact that the messages exchanged between C and AS are protected
and confidential. If the Client is also a constrained device, then C
may use DTLS-profile as described in [I.D-draft-gerdes-ace-dtls-
authorize] to create the secure channel with the AS.
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].
Cuellar, et al. Expires July 6, 2018 [Page 9]
Internet-Draft PAT profile for ACE 06 January 2018
Optionally, the C includes as part of the Access-Request Message the
details about the resources (R) or their corresponding URI with the
operations it needs to access or perform on RS. 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 access 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 the
access-rights based on application requirements.
Figure 4 shows an access-request message sent from C to AS to get an
access token. The "aud" represents a specific resource R
("tempSensor") and "scope" represents the allowed actions that C aims
to perform 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. If RS has included TIC
information for time synchronization, then the C MUST include TIC
object, including the MAC -- if included -- without any changes in
the payload for access request.
How the client authenticates itself against the AS is out of the
scope of this draft. Nevertheless, in the following example, the
client presents the Client_Credentials i.e., password based
authentication by presenting its client_secret (see section 2.3.1. of
[RFC6749]).
Cuellar, et al. Expires July 6, 2018 [Page 10]
Internet-Draft PAT profile for ACE 06 January 2018
Header: POST (Code=0.02)
Uri-Host: "coaps://as.example.com"
Uri-Path: "token"
Content-Type: "application/cbor+cwt+late ;
late-type=tic"
Payload:
{
"grant_type" : "client_credentials",
"client_id": "client123",
"client_secret": "Secret123",
"aud" : "tempSensor",
"scope": "GET|POST",
... omitted for brevity ...
TIC params:
{.. [if exist] ..
nonce:'rs-nonce..', # same rs-nonce sent by RS
kid: '..'
}
TAG: .. # TIC MAC tag produced by RS
using the shared key k with AS.
}
Figure 4: Example Client Access-Request message to AS
4.6. C<-AS : Access-Response
When AS receives an access-request message from a C, AS validates it
and performs the following actions:
o If the access request from C is valid (i.e., operations are
covered by the privileges defined by the RO), then AS prepares the
Access-Token (AT) and sends it with COAP response code 2.01
(Created).
o If the Access-Request from C contains LATe time synchronization
TIC information object, then an appropriate response with TOC
information object is included in the response as described in
[I.D-draft-navas-ace-secure-time-synchronization].
o If the client request is invalid 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 6, 2018 [Page 11]
Internet-Draft PAT profile for ACE 06 January 2018
,-. ,--.
|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 AS constructs the Access-Token (AT) and the verifier (the
symmetric PoP key) as the answer for a valid access request from C.
The contents of the access-response (ACC-RSP) payload are logically
split into two parts: the Access-Token (AT) and the Verifier
(Symmetric PoP key).
4.6.1. Access-Token construction:
o The Access-Token is constructed by AS using the CWT claim
parameters. It represents the permissions granted to the Client.
* "iss" (issuer): AS identity
* "aud" (audience): resource server URI or specific resource URI
for a fine-grained procedure.
* "exp" (Expiration Time): token expiration time
* "iat" (Issued At): token issued at time by AS
* "cti" CWT ID should be unique for every Access-Token.
* "scp" (Scope): Note that scp is not a CWT claim. It can
specify allowed methods such as GET, POST, PUT or DELETE.
Cuellar, et al. Expires July 6, 2018 [Page 12]
Internet-Draft PAT profile for ACE 06 January 2018
Other CWT claims are optional. It is recommended to avoid the CWT
claim "sub" (subject) as it exposes client identity.
4.6.2. Verifier or PoP key construction:
o Verifier (Symmetric PoP key): G (K, Access-Token). The Client
will use the Verifier as the key material to communicate with the
RS, i.e., if C wants to encrypt its payload, it uses the verifier
as the key.
* 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 it produces a
keyed digest as the output
* K: the shared key between AS and RS
* Access-Token: constructed using CWT claims as explained before
It is of special importance that the Access-Response message with the
access token and the verifier MUST be sent to C through a secure
channel -- in our example we considered a DTLS channel between C and
AS --.
The time-synchronization between AS and RS MAY be implemented based
on the application requirements using [I.D-draft-navas-ace-secure-
time-synchronization].
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 is supported by RS.
If the access-request message includes LATe TIC information, then AS
MUST prepare TOC information and included it in the response. A MAC
tag for TOC is created and appended in the response to prevent the
client from tampering TOC information.
Figure 6 shows the example of an Access-Response sent from AS to C
after successful validation of C's credentials which were presented
using an Access-Request message.
Cuellar, et al. Expires July 6, 2018 [Page 13]
Internet-Draft PAT profile for ACE 06 January 2018
Header: 2.01 (Created)
Content-Type: application/cbor+cwt+pat; pat-type="tk"
Location-Path: token/...
Payload:
{
"access token": b64'SlAV32hkKG ...
{
"iss": https://as.example.com
"aud": "tempSensor",
"scp": "read",
"iat": 1...,
"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]
}
}
TOC:{
as_time: '..',
nonce: 'rs-nonce..',
}
tag: '..' #TOC tag
}
Figure 6: Example Access-Response message sent 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 a token
(Tk) which will demonstrate that C has got the sufficient
authorization to access resources (R) in RS.
A new Token (Tk) MUST be attached to each RES-REQ sent to RS by C.
If payload data are included, then C should encrypt them using the
verifier as key and optionally it can include an Authentication Hash
(AuthHash= Hash(verifier+C_nonce)). PAT profile provides necessary
recommendations by using AEAD (e.g., chach20/poly1305) algorithm.
o As an example if C performs:
Cuellar, et al. Expires July 6, 2018 [Page 14]
Internet-Draft PAT profile for ACE 06 January 2018
* A CoAP GET() without payload. In this case, the request from C
MAY be sent un-encrypted since it does not include confidential
data, but the response from RS with payload MUST be always
encrypted and only the valid C MUST be able to decrypt it.
* A CoAP POST(), a CoAP PUT() or a CoAP DELETE() request with
payload MUST be protected and encrypted by using the AEAD
algorithm specified in the Access Token (AT). PAT profile
proposes to use ChaCha20-Poly1305-AEAD authenticated encryption
mechanism, while using the Verifier (PoP key) as the key and a
nonce. The AuthHash MAY be protected by using it as Additional
Authentication Data (AAD) in the AEAD algorithm.
The RS MUST implement /authz-info endpoint to allow any Client to
transfer the token (Tk) as described in [I-D.ietf-ace-oauth-authz].
The Resource-Request message with valid Token (Tk) shall be
constructed from AT by C and it should be sent to RS in the following
way:
o Figure 7 shows the example of Client Resource-Request:
Request:
Content-Type: application/cose+cbor+pat;
pat-type="AuthReq";
Message:
{ CoAP request: GET/POST/PUT/DELETE
Uri-Host "coap://rs.example.com"
uri-path: /authz-info
payload:
{
Token:
{
Access Token(AT), # Tk encapsulates the AT from AS
AuthHash=Hash(verifier+nonce), #optional for GET
nonce,
#Chach20/Poly1305(Verifier,nonce,
AAD=AuthHash, payload)
Payload:{
# if exist
}
}
}
}
Figure 7: RES-REQ from C using /authz-info implemented at RS
Figure 7 shows the detailed example of GET RES-REQ to the endpoint
/authz-info implemented at RS as described in [I-D.ietf-ace-oauth-
Cuellar, et al. Expires July 6, 2018 [Page 15]
Internet-Draft PAT profile for ACE 06 January 2018
authz]. This option enables the C to transport the token (Tk) to the
RS. After receiving the request, RS verifies the token (Tk): RS can
construct its own version of verifier or PoP-key by performing
G(K,AT) from the access-token (AT); and RS checks whether
AuthHash=Hash(verifier+nonce) is valid or not. If Tk and AuthHash
are valid, then RS sends an encrypted response using the verifier
(PoP key).
o Figure 8 shows the GET request from C to RS described in [I-
D.ietf-ace-oauth-authz], with pat-type="AuthReq".
Header: GET
Content-Type: application/cose+cbor+pat;
pat-type="AuthReq";
Uri-Host: "coap://rs.example.com"
Uri-Path: /authz-info
Payload:
{ token: {
"access token": .. {
"aud": "tempSensor"
"scp": "read"
... #CWT omitted for brevity.
}
"nonce": ..
"AuthHash": .. #[AuthHash=hash(verifier+nonce)]
}
TOC:{
time:'as-time',
nonce:'rs-nonce',# rs-nonce from RS TOC object
} tag: '..' #TOC tag
}
Figure 8: Example of valid GET RES-REQ from C to RS
including time-sync using endpoint /authz-info.
The C performs a GET request to "tempSensor" using CWT claim "aud",
and together C also transfers the Token (Tk) to the RS. PAT allows
performing both RES-REQ and transferring authorization information in
RES-REQ. In the next example we show how to perform a resource
request if the C performs a POST request with encrypted payload
information.
o Figure 9 shows an example of POST Resource-Request from C to RS
described in [I-D.ietf-ace-oauth-authz], with pat-type="AuthReq".
Cuellar, et al. Expires July 6, 2018 [Page 16]
Internet-Draft PAT profile for ACE 06 January 2018
Header: POST (Code=0.02)
Content-Type: application/cose+cbor+pat;
cose-type="encrypt0";
"pat-type="AuthReq";
Uri-Host: "coap://rs.example"
Uri-Path: /authz-info
Payload:
{# COSE
token: {
"access token": .. {
"aud": "firmwareUpd"
"scp": "write"
... CWT omitted for brevity,
}
"nonce": .. # nonce
"AuthHash": .. #[AuthHash=hash(verifier+nonce)]
TOC:{
time:'as-time',
nonce:'rs-nonce', # rs-nonce from RS TIC
} tag: '..' #TOC tag
}
# COSE_Encrypt0 + COSE_MAC0 Protected
ciphertext:{
#Chacha20/Poly1305 AEAD payload using
# key=verifier,
# nonce=..,
# AAD=AuthHash
},
tag: ..
}
Figure 9: Example of valid POST request from C to RS
Figure 9 shows the POST Resource-Request from C to RS where the Uri-
Path "/authz-info" allows the authorized client to perform firmware
upgrade on the RS using the CWT claim "aud:firmwareUpd". PAT
recommends protecting sensitive information such as the payload using
AEAD algorithm (chacha20/poly1305). The client should use Verifier
or PoP key as the key, a nonce, and AuthHash as AAD.
4.8. RS->C : Resource-Response
When the RES-REQ with a token (Tk) arrives from C to RS, RS MUST
evaluate the resource request and the token (Tk) in the following
order:
o Step 0: Check whether the contents of Tk are derived from an
access-token (AT) or not.
Cuellar, et al. Expires July 6, 2018 [Page 17]
Internet-Draft PAT profile for ACE 06 January 2018
o Step1: If Tk contains the access-token (AT) from AS, extract AT.
Extract nonce and Authentication Hash (AuthHash) from the request
message.
* Step1.1: (If available) Verify the freshness of the sequence
number (cti) in the access token presented by AS.
* Step1.2: Generate the verifier by computing G(K, access token)
where K is the shared key between AS and RS.
* Step1.3: Compute a verification hash as Hash(verifier+nonce)
and compare the result with AuthHash for correctness.
* Step1.4: Check if the access token has valid CWT parameters
such as "aud", "scp", "exp", "nbf", etc for the requested
resource or action to be performed.
* Step1.5: (IF available) Synchronize RS internal clock using TOC
object as described in [I.D-draft-navas-ace-secure-time-
synchronization].
o Step2: If the token is valid, RS should create a temporary
internal state as shown in table 1 below with details of CWT
claims "cti","exp","scp"", and the verifier (PoP key).
The RS internal state table which is shown in Table1 also includes
"next cti". The next cti (cti x) value is computed as the Hash of
previous cti (cti x-1) and the verifier. The purpose of this is
explained in the section Section 4.9.
|------------+-----------+-------+-------+-----------------------|
| Verifier | cti_x-1 | exp | scp | next cti (cti_x) |
|------------+-----------+-------+-------+-----------------------|
| G(k,AT) | cti_x0= | of AT | of AT | cti_x1= |
| | cti of AT | | | hash(cti_x0,Verifier) |
|------------+-----------+-------+-------+-----------------------|
Table 1: RS Internal state table of access-tokens and RS_nonce
o Step 3: If the token is valid, then RS decrypts the payload from
the client (if exist) Verifier (PoP key).
o Step 4: After that, RS prepares the response and encrypts the
payload with a fresh nonce, PoP key. Only the Client (C) with a
valid key (the Verifier) can decrypt the payload:
Cuellar, et al. Expires July 6, 2018 [Page 18]
Internet-Draft PAT profile for ACE 06 January 2018
4.8.1. RS Response-codes to C RES-REQ:
o If the token (Tk) is valid -- as discussed above --, then RS MUST
respond with payload-data as described above with the appropriate
response code as described in [RFC7252]. For example, to a POST
request with 2.01 (created) or 2.04 (changed).
o If the token (Tk) is invalid, then RS MUST respond with code 4.01
(Unauthorized)
o If the token (Tk) is valid but does not match the "aud" or
resource C is requesting for then RS MUST respond with code 4.03
(Forbidden)
4.9. Construction of Derived-Tokens (DT)
The objectives to create Derived-Tokens (DT) are:
o To produce Unlinkable Tokens (Tk). It is not efficient for the
client to request a new access-token (AT) from AS everytime.
Also, if C uses the same access-token (AT) from AS, the identity
of the client can be identified via the AT CWT claim "cti" (token
identity).
o To reduce token (Tk) size (efficiency in transport) that the
client must send to RS /authz-info in every resource request.
o To create tokens (Tk) that may have limited access to protected-
resources -- fine-grained resource access tokens -- from the
original access-tokens (AT) that could grant more privileges to
protected-resources on RS. For example, an access-token (AT)
could provide permissions to access all protected-resources on RS
via CWT claims audience "aud" and scope "scp". The client could
derive a Token (Tk) providing access to a reduced set of
protected-resources available on RS from the initial AT.
4.9.1. C->RS: Resource-Request via DT
The Client receives an encrypted response from RS after its first
RES-REQ with the access-token (AT) from AS.
The Client creates a new Derived-Token(DT) using CWT claims as
described below. In order to minimize the data size, we use only the
claims which are required.
o Client MAY prepare a DT with a subset of scope "scp" operations
that the client received from the initial Access-Token (AT). It
creates the first derived "cti_x1" by Hash("cti_x0 + verifier")
Cuellar, et al. Expires July 6, 2018 [Page 19]
Internet-Draft PAT profile for ACE 06 January 2018
from the CWT claim "cti" of the original access-token (AT). The
subsequent derivation of "cti_x" can be performed by a generic
function "cti_x = Hash(cti_x-1 + verifier)". Note that the
derived-token (DT) MUST include all the necessary CWT claims such
as "cti_x", "aud", "exp", "scp". All other CWT claims are
optional.
o Client creates the AuthHash=(verifer+nonce).
o Client prepares encrypted content using verifier as the key -- if
there is any payload --.
o Note: in the Additional Authenticated data (AAD), the C includes
AuthHash and the derived-token (DT), so that the payload cannot be
misused/exchanged with another RES-REQ or nonce.
Header: POST (Code=0.02)
Content-Type: application/cbor+cwt+cose++pat;
cose-type="encrypt0";
"pat-type="AuthReq";
Uri-Host: "coap://rs.example"
Uri-Path: /firmware
Payload:
{# COSE
token: {derived-token(DT):
"aud": "firmwareUpd",
"exp": ..
"scp": "write",
"cti": Hash(cti_x+verifier)
# cti_x=Hash(cti_x-1+verifier).
}
"nonce": .. # new nonce
"AuthHash": h'bfa03.. #[Hash=(verifier+nonce)]
# COSE_Encrypt0 + COSE_MAC0 Protected
ciphertext:{
#Chacha20/Poly1305 AEAD payload using
# key=verifier,
# nonce=..,
# AAD=AuthHash,DT
h'....omitted for brevity
},
tag: h'... omitted for brevity
}
Figure 12: Example of valid Resource-Request
from C to RS using a derived-token(DT)
Cuellar, et al. Expires July 6, 2018 [Page 20]
Internet-Draft PAT profile for ACE 06 January 2018
4.9.2. RS->C : Resource-Response to DT
After receiving the Token (Tk) which encapsulates the derived Token
(DT) from C, RS performs the following Steps. If any of them fails,
then RS must send an UnAuthorized response to C, and C must use the
first AT, which was received from the AS, or request a new AT based
on the resource owner (RO) configuration:
o RS extracts CWT claim cti (cti_x) from the Derived-Token (DT) and
checks if it exists in its internal state table. If RS finds the
cti_x, then RS uses the corresponding verifier, "cti_x-1, "exp",
and "scp" to perform the validation of next steps.
o RS checks that cti_x= Hash (cti_x-1+verifier)
o RS checks that AuthHash == Hash(verifier+nonce)
o RS checks that the permissions are valid using "scp" and
expiration time "exp"
o RS updates the new cti_x-1, cti_x in its internal state table
o RS creates an encrypted response to be sent to C with a payload
including payload-data.
|---------+--------------+---------+-------+-------+-----------------|
| msg# | Verifier (V) | cti_x-1 | exp | scp | cti_x= |
| | | | | | Hash(cti_x-1+V) |
|---------+--------------+---------+-------+-------+-----------------|
| 0 | G(K,AT) | 0x00 | of AT | of AT | 0xAB = |
| | | | | | Hash(0x00+V) |
|---------+--------------+---------+-------+-------+-----------------|
| 1 (upd) | G(k,AT) | 0xAB | of AT | of AT | 0xFF = |
| | | | | | Hash(0xAB+V) |
|---------+--------------+---------+-------+-------+-----------------|
Table 2: RS updating only two parameters in its
internal stating table 1
The Table 2 shows the RS internal state table with an example.
5. Security Considerations
TBD
Cuellar, et al. Expires July 6, 2018 [Page 21]
Internet-Draft PAT profile for ACE 06 January 2018
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.
[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-0 (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-08 (work in
progress), July 2016.
[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-06 (work in
progress), March 2017.
[I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption
(COSE)", draft-ietf-cose-msg-24 (work in progress), November 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 6, 2018 [Page 22]
Internet-Draft PAT profile for ACE 06 January 2018
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-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-01,
March 2017.
[I-D.ietf-ace-cbor-web-token] Jones, M., Tschofenig, H., Erdtman, S.,
CBOR Web Token (CWT), draft-ietf-ace-cbor-web-token-05 (work in
progress), June 2017..
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
the previous version of the draft.
8.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)>.
Appendix A. ACE profile Registration
TBD
Cuellar, et al. Expires July 6, 2018 [Page 23]
Internet-Draft PAT profile for ACE 06 January 2018
|----------------------+-----|
| ACE profile template | PAT |
|----------------------+-----|
| Profile name | TBD |
| Profile Description | TBD |
| Profile ID | TBD |
|----------------------+-----|
Table2: ACE profile registration template
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 6, 2018 [Page 24]