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, [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. 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 . 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]