Privacy-Enhanced-Tokens (PAT) profile for ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-05
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 | 2017-07-02 | ||
| 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-05
ACE Working Group J. Cuellar
Internet-Draft P. Kasinathan
Intended status: Standards Track Siemens AG
Expires: January 3, 2018 D. Calvo
Atos Research and Innovation
July 2, 2017
Privacy-Enhanced-Tokens (PAT) profile for ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-05
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 January 3, 2018.
Copyright Notice
Copyright (c) 2017 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 January 3, 2018 [Page 1]
Internet-Draft PAT profile for ACE 05 July 2017
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 . . . . . . . . . . . . . . . . . . 3
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.7. C->RS : Resource-Request . . . . . . . . . . . . . . . . 14
4.8. RS->C : Resource-Response . . . . . . . . . . . . . . . . 18
4.9. Construction of Derived-Tokens (DT) . . . . . . . . . . . 20
4.9.1. RS->C: Resource-Response: . . . . . . . . . . . . . . 21
4.9.2. C->RS: Resource-Request via DT . . . . . . . . . . . 22
4.9.3. RS->C : Resource-Response to DT . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 25
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Copyright Statement . . . . . . . . . . . . . . . . . . . 26
Appendix A. ACE profile Registration . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 the initial secret
that can be used by clients and resource servers (or in some cases,
more generally by arbitrary nodes) to provide authentication and
authorization.
This draft uses the architecture of [draft-ietf-ace-actors] and [I-
D.ietf-ace-oauth-authz], designed to help constrained nodes in
Cuellar, et al. Expires January 3, 2018 [Page 2]
Internet-Draft PAT profile for ACE 05 July 2017
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
for ACE framework.
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.
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 are harmonized with [I-D.ietf-ace-oauth-authz].
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:
Cuellar, et al. Expires January 3, 2018 [Page 3]
Internet-Draft PAT profile for ACE 05 July 2017
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 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 assumption, 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 may provide AS
information to the C in the response. The C perform an Access-
Request to AS to access 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 AT and PoP key to C via a secure channel, and
how this secure channel is created between AS and C is out of 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 the PoP key from the AT and
verifies AT, if valid, RS encrypts the response with 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 can be used in context where unlinkability
(privacy) and efficiency is the main goal: the tokens (Tk) convey
only the assurance of the authorization claims of the clients. In
particular, the Token (Tk) used, can be constructed in such a way
that they not leak information about the correspondence of messages
to the same Client or from the same access-token (AT). In other
words: 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.
Cuellar, et al. Expires January 3, 2018 [Page 4]
Internet-Draft PAT profile for ACE 05 July 2017
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.
In the following, we describe the features of PAT protocol:
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 construct Tokens (Tk) that allow C 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. 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 initial secret (the PoP key) from AT and
encrypts the response using the PoP key.
o The tokens (Tk) do not provide any information about any
associated identities such as identifiers of the clients, 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). 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.
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].
Cuellar, et al. Expires January 3, 2018 [Page 5]
Internet-Draft PAT profile for ACE 05 July 2017
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 sub-sections describe the message flow in more detail,
especially how the messages, and tokens with PoP are constructed.
A PAT message sent from actor A to actor B is represented using the
following notation: "A -> B : Message Name"
Cuellar, et al. Expires January 3, 2018 [Page 6]
Internet-Draft PAT profile for ACE 05 July 2017
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 a proof-of-possession
keys (PoP key or verifiers).
We can also assume that the CAS and AS share a secure connection, say
over DTLS if CAS exist as an actor. During the commissioning phase
RS registers the cryptographic algorithms and 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 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 request from a C, RS checks:
o If C has valid token (Tk) or not. If C does not have 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 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)
Cuellar, et al. Expires January 3, 2018 [Page 7]
Internet-Draft PAT profile for ACE 05 July 2017
o If C has a valid access token, then RS must follow the detailed
procedure as 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 Unauthorized resource 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 January 3, 2018 [Page 8]
Internet-Draft PAT profile for ACE 05 July 2017
Header: 4.01 (Unauthorized)
Content-Type: application/cbor+pat;
pat-type="UnAuthReq"
Payload:
{#Unprotected
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 requesting access-request to AS, C must establish a secure
channel with AS. The C may be registered with the AS, as described
in [I-D.ietf.ace-oauth-authz] or C receives AS-Info from RS.
The AS may have an access control list defined by the RO for the
clients, and with the access-control list, AS can verify if the
client is allowed to establish a secure connection or not. If the
client has valid access to the requested resource(R) 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 the connection between AS
and C 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. 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 between 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].
Optionally, the C includes the details about the resources (R) or the
corresponding URI with operations it needs to access or perform on RS
Cuellar, et al. Expires January 3, 2018 [Page 9]
Internet-Draft PAT profile for ACE 05 July 2017
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 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 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. 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 is authenticating itself to the AS is out of scope of
this draft, but 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]).
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
Cuellar, et al. Expires January 3, 2018 [Page 10]
Internet-Draft PAT profile for ACE 05 July 2017
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 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 must be 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.
,-. ,--.
|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) for a valid access request from C. The contents
of the access-response (ACC-RSP) payload are logically split into two
Cuellar, et al. Expires January 3, 2018 [Page 11]
Internet-Draft PAT profile for ACE 05 July 2017
major parts, the Access-Token (AT) and the Verifier (Symmetric PoP
key).
Access-Token construction:
o Access-Token is constructed using the CWT claim parameters by AS:
* "iss" (issuer): AS identity
* "aud" (audience): resource server URI
* "exp" (Expiration Time):token expiration time
* "iat" (Issued At): token issued at time by AS
* "cti" CWT ID should be unique binary string. For every Access-
Token could be a sequence number
* "scp" (Scope): Note, scp is not a CWT claim. It can specify
allowed methods such as GET, POST, PUT or DELETE.
Other CWT claims can be optional. It is recommended to avoid the CWT
claim "sub" (subject) as it exposes the client identity exposed.
Verifier or PoP key construction:
o Verifier (Symmetric PoP key): G (K, Access-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
* Access-Token: constructed using CWT claims as explained before
Important Note:
o The Access-Response message with the access token, verifier using
CWT claims MUST be sent to C through a secure channel -- in our
example we considered a DTLS channel between C and AS --.
o 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 used verifier as the key.
Cuellar, et al. Expires January 3, 2018 [Page 12]
Internet-Draft PAT profile for ACE 05 July 2017
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].
o 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.
o 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 Access-Response from AS to C after
successful validation of C's credentials presented in Access-Request
message by C.
Cuellar, et al. Expires January 3, 2018 [Page 13]
Internet-Draft PAT profile for ACE 05 July 2017
Header: 2.01 (Created)
Content-Type: application/cbor+cwt+pat; pat-type="ct"
Location-Path: token/...
Payload:
{
"access token": b64'SlAV32hkKG ...
{
"token_type": pop,
"aud": "tempSensor",
"scp": "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]
}
}
TOC:{
as_time: '..',
nonce: 'rs-nonce..',
}
tag: '..' #TOC tag
}
Figure 6: Example Access-Response message from AS to C
with detailed CWT params and payload info
Note that when C performs the resource-request to RS, C will not send
the verifier, but only the Access-Token(AT) with some additional
parameters such as Authentication Hash (AuthHash) to prove RS that C
holds the proof-of-possession (PoP) key or Verifier. RS can
construct the verifier from the Access-Token and the key (K) it
shares with the AS and verifies the AuthHash.
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
Cuellar, et al. Expires January 3, 2018 [Page 14]
Internet-Draft PAT profile for ACE 05 July 2017
authorization to access resources (R) in RS. The message Resource-
Request (RES-REQ) with new token Tk has to be sent afresh to RS.
The frequency in which the Client has to send a new token (Tk) can be
enforced by RS and is determined indirectly by the owner of RS (or by
AS). Each time a RES-REQ is sent from C to RS, a new Token (Tk) MAY
be needed. Optionally, C can protect its payload by encrypting using
verifier as the key (if necessary). PAT profile provides necessary
recommendations by using chach20/poly1305 AEAD algorithm.
o As an example if C performs:
* A CoAP GET() may be unprotected with no payload. 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 from RS.
* A CoAP POST() or a CoAP PUT() or a CoAP DELETE() request with
payload MUST be protected by using AEAD algorithm presented in
Access Token (AT). We propose to use ChaCha20-Poly1305-AEAD
authenticated encryption mechanism, while using the Verifier
(PoP key) as the key and a nonce, the AuthHash 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 token (Tk) as described in [I-D.ietf-ace-oauth-authz].
The Resource-Request message with valid Token (Tk) from AT shall be
constructed by C and can be transported to RS in the following way:
o Figure 7 shows the example of Client Resource-Request:
Request Message:{
Cuellar, et al. Expires January 3, 2018 [Page 15]
Internet-Draft PAT profile for ACE 05 July 2017
CoAP request: GET/POST/PUT/DELETE
Uri-Host "coap://rs.example.com"
uri-path: /authz-info
payload:{
Token:
{#Unprotected:
Access Token(AT), # Tk encapsulates the AT from AS
#Protected:
AuthHash=Hash(verifier+C_nonce)
#Chach20/Poly1305(Verifier,nonce=C_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-
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 the verifier or PoP-key by performing MAC(K,AT) from the
access-token (AT); and RS checks whether
AuthHash=Hash(verifier+nonce) is valid or not. If Tk and AuthHash is
valid, then RS sends a 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".
Cuellar, et al. Expires January 3, 2018 [Page 16]
Internet-Draft PAT profile for ACE 05 July 2017
Header: GET (Code=xx)
Content-Type: application/cose+cbor+pat;
pat-type="AuthReq";
Uri-Host: "coap://rs.example.com"
Uri-Path: /authz-info
Payload:
{ #Unprotected
token: {
"access token": b64'SlAV32hkKG {
"aud": "tempSensor"
"scp": "read"
... CWT omitted for brevity.
}
"nonce": "C_nonce"
#Protected
"AuthHash": b64'v4Sugr7.. #[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.
In Figure 8, the C performs a GET request to "tempSensor" using CWT
claim "aud", and together C also transfers the Token (Tk) to the RS.
As PAT allows performing both RES-REQ and transferring authorization
information i.e., the token (Tk) we reduce one round-trip of
messages. In the next example we show how to perform a resource
request if the C performs a POST request with a payload information
protected.
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 January 3, 2018 [Page 17]
Internet-Draft PAT profile for ACE 05 July 2017
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 Unprotected
token: {
"access token": b64'SlAV32hkKG {
"aud": "firmwareUpd"
"scp": "write"
... CWT omitted for brevity,
}
"nonce": .. # C_nonce
"AuthHash": h'bfa03.. #[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=C_nonce,
# AAD=AuthHash
h'....omitted for brevity
},
tag: h'... omitted for brevity
}
Figure 9: Example of valid POST request from C to RS
Figure 9 shows the POST Resource-Request from C to RS. In the
presented example, 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
payload using chacha20/poly1305 AEAD algorithm: Verifier or PoP key
as the key, C_nonce as nonce, and AuthHash as the AAD. The generated
Cipher text and tag is enclosed in the payload.
4.8. RS->C : Resource-Response
When the request with token (Tk) arrives to RS from C, RS MUST
evaluate the resource request and the token (Tk) in the following
order:
Cuellar, et al. Expires January 3, 2018 [Page 18]
Internet-Draft PAT profile for ACE 05 July 2017
o Step 0: Check whether the contents of Tk is derived from access-
token (AT) or not.
o Step1: if Tk contains the access-token (AT) from AS, extract AT,
nonce and Authentication Hash (AuthHash) from the token (Tk).
o Step1.1: (if available) verify the freshness the Token.
o Step1.2: generate the verifier by computing MAC(K, access token)
where K is shared key between AS and RS.
o Step1.3: compute verificationHash as Hash(verifier+nonce) and
compare the result with AuthHash for correctness.
o Step1.4: check if the access token has right CWT parameters such
as "aud", "scp", "exp", "nbf", etc for the requested resource or
action to be performed.
o 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 Tk contains Derived-Tokens (DT), then RS should follow
the instructions described in Section 4.9.
If the Token is valid as discussed above, then RS decrypts the
message's payload if exist. RS decrypts the encrypted payload using
the agreed algorithm, i.e., in our example ChaCha20/Poly1305 AEAD
algorithm using (key=verifier, nonce, AAD, payload). The response
from RS MUST be encrypted with a fresh nonce. The response payload
along with the response MUST include a random nonce (RS_nonce)
generated using a Pseudo-Random-Function (PRF), RS_nonce is used to
derive the Token (TK) and it is explained in Section 4.9. Note that
RS_nonce is different from the nonce that is used to encrypt the
payload in chacha20. Only the Client (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,AAD,payload={payload_data,
RS_nonce}
)
}
Figure 10: Example of RS response with encrypted payload.
The payload contains payload-data and RS_nonce.
Cuellar, et al. Expires January 3, 2018 [Page 19]
Internet-Draft PAT profile for ACE 05 July 2017
Notice the difference in Figure 10, the nonce used in chacha20/
poly1305 and RS_nonce used in the payload. A new nonce MUST be used
while encrypting the response, generally using a PRF function to
create e nonce parameter is acceptable. The RS should keep an
internal state of the RS_nonce, verifier, and some CWT parameters as
described in Section 4.9.
RS Response-codes to C Resource-Request:
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)
In this section we describe the derived tokens (Tk) construction
procedure for clients from the access-tokens (AT) that it received
from AS. The objectives of this procedure are the following:
o To produce Unlinkable Tokens (Tk). It is not efficient for the
client to request new access-token (AT) from AS everytime. Also,
if we use 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 everytime.
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.
o A Challenge response method is enforced for every Resource-Request
via a nonce (RS_nonce) generated by the resource-server.
Cuellar, et al. Expires January 3, 2018 [Page 20]
Internet-Draft PAT profile for ACE 05 July 2017
Initially, the Client performs the steps needed to obtain a valid
Access-Token from the Authorization Server, following the exchanges
as described above in PAT-protocol. Then, the following procedure is
followed to access the resources of the RS enforcing efficiency and
unlinkability of the Tokens.
4.9.1. RS->C: Resource-Response:
RS validates the Token(Tk) from C, i.e., validating the enclosed
Access-Token (AS) issued by AS in the following order:
o Step 0: check whether the contents of Tk are derived from access-
token (AT) or not.
o Step1: if Tk contains the access-token (AT) from AS, extract AT,
nonce and Authentication Hash (AuthHash) from the token (Tk).
o Step1.1: (if available) verify the freshness of the sequence
number in the access token presented by AS.
o Step1.2: generate the verifier by computing MAC(K, access token)
where K is shared key between AS and RS.
o Step1.3: compute verificationHash as Hash(verifier+nonce) and
compare the result with AuthHash for correctness.
o Step1.4: check if the access token has right CWT parameters such
as "aud", "scp", "exp", "nbf", etc for the requested resource or
action to be performed.
o Step1.5: (if available) synchronize RS internal clock using TOC
object as described in [I.D-draft-navas-ace-secure-time-
synchronization].
o Step2.0: RS should create a TEMPORARY internal state as shown in
the table 1 below with details of CWT claims "cti","exp","scp"",
and the verifier (PoP key).
o Step2.1: RS creates a RS_nonce using a PRF function and updates it
in the internal table 1.
o Step2.2: RS creates an encrypted payload with payload-data as the
response and a RS_nonce using verifier as the key.
The internal state table of RS may look like below:
Cuellar, et al. Expires January 3, 2018 [Page 21]
Internet-Draft PAT profile for ACE 05 July 2017
|------------+------------------+-----------+-----------+----------|
| Verifier | cti | exp | scp | RS_nonce |
|------------+------------------+-----------+-----------+----------|
| Hash(k,AT) | cti_x0=cti of AT | exp of AT | scp of AT | RS_nonce |
|------------+------------------+-----------+-----------+----------|
Table 1: RS Internal state table of access-tokens and RS_nonce
This is very similar to client-server challenge-Response method with
a nonce, we use RS_nonce for this purposes. If the client is able to
decrypt the RS_nonce, he uses it as its C_nonce for next resource-
request. Thus C proves that it has the verifier (PoP key) from the
initial access-token (AS). The RS response is the same as shown in
figure 10.
4.9.2. C->RS: Resource-Request via DT
The Client receives an encrypted response from RS. It includes a
RS_nonce together with the response.
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 that are required and which are unlinkable.
o Client MAY prepare a DT with fine-grained allowed operations from
the initial Access-Token (AT) CWT claim parameter "scp" Scope,
etc., that it received from AS. The access-token (AT) contains
the CWT claim "cti", Client creates the first derived "cti_x" by
Hash("cti + RS_nonce"). The subsequent derivation of "cti_x" can
be performed by a generic function "cti_x = Hash(cti_x-1 +
RS_nonce)". Note that the derived-token (DT) MUST include
necessary CWT claims such as "cti_x", "aud", "exp", "scp". All
other CWT claims are optional.
o Client creates the AuthHash=(verifer+RS_nonce).
o Client prepares encrypted content using verifier as the key -- if
there is any payload --.
o Note: in the Additional Authenticated data, the C includes
AuthHash and the derived-token (DT), so that the payload cannot be
misused with another token or RS_nonce. Also, the client uses the
RS_nonce -- that the C received from RS in the previous response
-- to create new request.
Cuellar, et al. Expires January 3, 2018 [Page 22]
Internet-Draft PAT profile for ACE 05 July 2017
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 Unprotected
token: {derived-token(DT):
"aud": "firmwareUpd",
"exp": 10 sec
"scp": "write",
"cti": Hash(cti_x+RS_nonce)
# cti_x=Hash(cti_x-1+RS_nonce).
}
"nonce": .. # RS_nonce
"AuthHash": h'bfa03.. #[Hash=(verifier+RS_nonce)]
# COSE_Encrypt0 + COSE_MAC0 Protected
ciphertext:{
#Chacha20/Poly1305 AEAD payload using
# key=verifier,
# nonce=RS_nonce,
# AAD=AuthHash,DT
h'....omitted for brevity
},
tag: h'... omitted for brevity
}
Figure 12: Example of valid derived-token(DT) request from C to RS
4.9.3. 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 one of the
steps fails, then RS must send UnAuthorized response to C, and C must
use the first AT that it received from AS --:
o RS extracts RS_nonce from the Token (Tk) and checks if it exists
in its internal state table. If RS finds the RS_nonce, then RS
uses the corresponding verifier, "cti, "exp", and "scp" to perform
the validation of next steps.
o RS performs a check whether AuthHash == Hash(RS_nonce+verifer) or
not
o RS performs a check for new token identifier (cti_x) ==
Hash(cti_x-1+RS_nonce) or not
Cuellar, et al. Expires January 3, 2018 [Page 23]
Internet-Draft PAT profile for ACE 05 July 2017
o RS checks if the permissions are valid using "scp" and expiration
time "exp"
o RS creates a new RS_nonce and updates it in its internal state
table along with new cti_x
o RS creates an encrypted response to C with payload including
payload-data and new RS_nonce
The RS_nonce MUST be created using a PRF, and a separate random nonce
should be used to encrypt the response payload. The encrypted
payload contains payload-data and RS_nonce as shown in the figure 10.
|---------------------+---------------|
| cti | RS_nonce |
|---------------------+---------------|
| cti_x of latest Tk | RS_nonce =PRF |
|---------------------+---------------|
Table 2: RS updating only two parameters in its
internal stating table 1
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.
Cuellar, et al. Expires January 3, 2018 [Page 24]
Internet-Draft PAT profile for ACE 05 July 2017
[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.
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.
Cuellar, et al. Expires January 3, 2018 [Page 25]
Internet-Draft PAT profile for ACE 05 July 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
|----------------------+-----|
| 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
Cuellar, et al. Expires January 3, 2018 [Page 26]
Internet-Draft PAT profile for ACE 05 July 2017
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 January 3, 2018 [Page 27]