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, [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [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 . 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]