Privacy-Enhanced Tokens for Authorization in ACE

Three well-known problems in constrained environments are the authorization of clients to access resources on servers, the realization of secure communication between nodes, and the preservation of privacy. The reader is referred for instance to [draft-ietf-ace-actors], [I-D.ietf-ace-oauth-authz] and [KoMa2014]. This memo describes a way of constructing Token Material (Key Material) that can be used by clients and servers (or in some cases, more generally by arbitrary nodes) to create secure channels and provide authentication. Moreover, the construction can be used to offer user consent (in the sense of privacy) and to dynamically create pseudonyms to enhance the unlinkability of the information, see section [Features] below. This draft uses the architecture of [draft-ietf-ace-actors] and [I-D.ietf-ace-oauth-authz], designed to help constrained nodes in authorization-related tasks via less-constrained nodes. Terminology for constrained nodes is described in [RFC7228]. PAT supports an implicit authorization mode where no authorization information is exchanged and uses access tokens to implement this architecture. A device that wants to access an item of interest on a constrained node first has to gain permission in the form of a token from the node's Authorization Server. This memo also specifies a profile for ACE framework (Authentication and Authorization for constrained environments). One of the goal of PAT is to securely transmit authorization tokens. A by-product is the set-up of a Datagram Transport Layer Security (DTLS) [RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279] between two nodes. The main goal of the PAT is to present methods for constructing authorization tokens and to securely transmit them to the parties involved with privacy features such as unlinkability. The CoAP protocol [RFC7252] is used as the application layer protocol together with CWT. Note that DTLS channel [I.D-draft-gerdes-ace-dtls-authorize] or Object security of CoAP (OSCOAP) [I-D.selander-ace-object-security] can be used to securely transmit the authorization tokens. In some cases, relevant in constrained environments, it is also not necessary for a secure transmission of the payload data from server to client. Further details will be presented in future versions of this draft.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749] and [I-D.ietf-ace-actors], such as client (C), resource server (RS), resource owner (RO), resources (R) and authorization server (AS). In addition to the terms defined in [I-D.ietf-ace-actors], we use additionally the following terms: Client Token (CT): The token which is generated by the AS for the Client. It contains a secret, which can be used to generate the Token, plus other data used for "Proof-of-Possesion" (PoP). Optionally CT may contain authorization information that represents RO's authorization policies for C. Note: this Client Token is not to be confused with the tentative Client Token introduced in [I-D.ietf-ace-oauth-authz]. Access-Token (AT): The token which is generated by the Client and presented by him to the RS to access the resources (R) on RS. It contains a secret, which changes regularly (in a similar way to one-time passwords). The AT contains all information needed by the RS to verify that it was granted by AS. Note: this access-token is different from the access token described in [I-D.ietf-ace-oauth-authz] which is generated by AS and sent to C. In future versions of this draft, the differences in token names and its purposes will be harmonized with [I-D.ietf-ace-oauth-authz].

This specification defines the PAT protocol and the PAT profile for ACE framework for authorization in the Internet of Things environment. The PAT protocol is built around the building blocks described in [I-D.ietf-ace-oauth-authz]. In this specification we assume the following: a Resource Server (RS) has one or more resources (R) and is registered with an Authorization Server (AS) the Authorization Server (AS) provides the authentication and authorization for the RS. The corresponding Resource Owner (RO) of the RS has set permissions in AS for allowed Clients. a Client (C) is either registered with an AS or it knows how to reach the RS for accessing the required resource. to access a resource on a Resource Server RS, a Client (C) should request a token from AS, either directly or using its Client Authorization Server (CAS). For the sake of better understanding, this memo does not include the CAS actor. For instance, the C may or may not know the corresponding AS to request a CT for the resource it would like to access from RS. Based on the knowledge C has, the first message from C can be either to RS or to AS. This draft assumes that RS is offline after commissioning, i.e., RS cannot make any introspective queries to the AS to verify the authorization information provided by the C. Based on the above assumption, the simple message flow can be described as follows: a C may request a resource on RS without valid access token, the RS will reject and may provide AS information to the C. Then C may perform an Access-Request to AS for the required resource on RS. Then AS decides if C is allowed to access the resource or not based on permissions set by the RO. If so, AS generates a Client-Token (CT) used for the authorization with the symmetric proof-of-possession key between AS and RS. The C uses CT to construct Access-Token (AT) through which a security context (PAT secret) can be established between C and RS.

The method allows a User, or an Authentication/Authorization Server (AS) on its behalf, to authorize one or several clients to access resources (R) on a RS. The client and/or the Resource server can be constrained devices. The authorization is implemented by distributing purpose-built Key Material (which we generically call "Tokens") to the RS and C. This SHOULD be done by secure channels. The Client Tokens are crafted in such a way that the client can construct authorization tokens that allow them to demonstrate to RS its authorization claims. The message exchange between C and RS for the presentation of the tokens MAY be performed via insecure channels. The tokens do not provide any information about any associated identities or identifiers of the clients nor of the server. In particular, the method can be used in context where unlinkability (privacy) is a main goal: the tokens convey only the assurance of the authorization claims of the clients. This means that the payloads of our protocol, and in particular, the Authentication Token secrets used, can be constructed in such a way that they not leak information about the correspondence of messages to the same Client. In other words: if an eavesdropper observes the messages from the different Clients to and from the server, the protocol does not give him information about which messages correspond to the same Client. Of course, other information, like the IP-addresses or the contents themselves of the requests/responses may leak some information in this regard can be treated separately via other methods. The tokens are supported by a "proof-of-possession" (PoP) method. PoP allows an authorized entity (a client) to prove to the verifier (here, the RS), that he is indeed the intended authorized owner of the token and not simply the bearer of the token. (Notice that the Authorization Token may be sent in the clear, and thus, it could be stolen by an intruder. A PoP would hinder the attacker to use the token pretending to be authorized). The Key Material can be used to generate and coordinate pseudonyms between C and RS and potentially further parties. The user (more precisely, the Resource Owner, RO, see Section "Actors and Terminology" below) is able to decide (if he wishes: in a fine-grained way and in real-time) which client under which circumstances may access his data stored in RS. This can be used to provide consent (in terms of privacy) from users (again, ROs). To be coherent with ACE Authorization framework [I-D.ietf-ace-oauth-authz], this draft also specifies an ACE profile to use PAT and for efficient encoding it uses CWT and COSE. The PAT profile is signalled when the C requests token from the AS. In short, the PAT protocol presents as the most important features: Simplified authentication on constrained nodes by handing the more sophisticated authentication over to less-constrained devices Support of secure communication between constrained devices Authorization policies of the principals of both participating parties are ensured Simplified authorization mechanism for cases where implicit authorization is sufficient Using only symmetric encryption on constrained nodes Specifies an ACE profile to cohere with ACE framework

The PAT protocol includes three actors: the RS, the C, and the AS. The PAT message flow is shown in Figure 1. Messages in [square brackets] mean they are optional.

,-. ,--. ,--. |C| |RS| |AS| `+' `+-' `+-' | | 1 Security-Association-Setup| | | <---------------------------> | | | | 2 [Resource-REQ] | | |------------------------> | | | | |3 [Un-Auth-REQ(AS-Info)]| | |<------------------------ | | | | | 4 Security-Association-Setup | |<-----------------------------------------------------> | | | | 5 Access-REQ | |------------------------------------------------------> | | | | 6 Access-RSP | |<------------------------------------------------------ | | | | 7 Resource-REQ | | |------------------------> | | | | | 8 Resource-RSP | | |<------------------------ | ,+. ,+-. ,+-. |C| |RS| |AS| `-' `--' `--' Figure 1: PAT protocol message flow The AS and RS share a long term secret (K). To determine AS which in charge of a resource hosted at the RS, C MAY send an initial Resource-Request without valid access token to RS. RS denies the request without valid access token and could possibly include the address of its AS (AS-Info) to C in the response. Or, instead of the initial Resource-Request without valid access token, C MAY look up the desired resource in a resource directory as described in [I-D.ietf-core-resource-directory] that lists the available resources. Once C knows AS's address, it can send an Access-Request for authorization to AS (directly, or indirectly using its own CAS). If the access is to be authorized, AS generates an Access-Request Response to C. It contains client token and a symmetric PoP key (the verifier) which is necessary for the C to create valid access tokens for RS. Each time C sends RS a Resource-Request, it generates and presents an Access-Token to RS to prove its right to access. If the access-token is valid, RS sends a Resource-Response to the C. Later with the common established secret C and RS can generate derived keys which are described later in the draft. The following section describes the message flow in more detail, especially how the messages, tokens are constructed and how RS and C can use their common knowledge i.e., initial PAT secret to verify the authenticity of the ATs. Further, C and RS may derive keys from the initial PAT secret: VerifK: to verify that C and RS are talking with the intended partner, for the Client C it is used as Proof of Possession of the Access-Token PSK: as a symmetric Key to establish a DTLS secure channel or for other purposes (by product of PAT) IntK: for Integrity protection (in message authentication codes) ConfK: for Confidentiality Protection (to be elaborated in a future version of the document). As CoAP [RFC7252] is the recommended application layer protocol for constrained devices, the PAT protocol is designed to work with CoAP. The following notation:

A -> B : <Msg_Name> represents the message with name Msg_Name, sent from A to B.

This memo assumes that the Resource Server RS and its Authentication Server AS share a secure channel and share a long term shared secret, i.e., a shared key (K), which MAY be implemented via USB (and physical security) or when commissioning the devices or by other means (out of scope). The shared secret (K) is used both by the AS and the RS to create a proof-of-possession keys (verifiers). It must be stressed that the security of the protocol strongly depends on how secure this channel is. We can also assume that the CAS and AS share a secure connection, say over DTLS if CAS exist as an actor. Also, during this process RS registers the cryptographic algorithms and parameters it can support validating the access-tokens for authorization. The internal clock of RS can be synchronized with the AS during the commissioning phase. How this time synchronization is refreshed will be discussed in the future version of this draft.

Initially, a C may not have a valid access token to access a protected resource hosted in RS or the corresponding AS-information from which it needs to get the authorization token. In this scenario, the Client may send a Resource-Request message to RS without valid access-token. To enable resource discovery, RS may expose the URI "/.well-known/core" [RFC6690], but this resource itself MAY be protected. Thus, to discover the resources available on RS, the C can optionally make a CoAP GET request to the URI "/.well-known/core". As with any other unauthorized GET request, the Client C is asked to access the AS.

Once RS receives a request from a C, it checks the following: If C does not have valid access token, then RS MUST respond to C with 4.01 (Unauthorized request). Optionally, RS may include information about AS (AS-Info) which includes additional information (AS address) to reach /token endpoint exposed by the AS. Note: this message is sent to any unauthorized Client, therefore it is recommended to include as less information as possible to identify AS. If C has a valid access token, but not for the requested resource then RS MUST respond with 4.03 (Forbidden) If C has a valid access token, but not for the method requested then RS MUST respond with 4.05 (Method Not Allowed) Figure 2 shows the sequence of messages with detailed CoAP types between C and RS for the above Unauthorized resource request:

,-. ,--. |C| |RS| `+' `+-' | | ,---------------------------. | 1 Res-REQ | |Header:GET | |----------->| |Type:Confirmable | | | |URI-Path:.well-known/core | | | `---------------------------' | | ,---------------------------. | | |Header: 4.01 Unauthorized | | 2 Res-RSP | |Type: Acknowledgement | |<-----------| |content-type: | | | |application/cbor | | | |Payload:{AS-Info,params} | ,+. ,+-.`---------------------------' |C| |RS| `-' `--' Figure 2: C<->RS Resource-Request and Unauthorized as response TBD: together with AS-Info, the RS may also send params. To mitigate attacks based on time synchronization the Lightweight Authenticated Time (LATe) synchronization protocol for constrained environments as described in [I.D-draft-navas-ace-secure-time-synchronization]. Figure 3 shows an example of the response message sent by RS to C encoded using CBOR [RFC7049] with pat-type="UnAuthReq". The response message might include key-reference ID of the shared secret between RS and AS, nonce to prevent replay attacks of C. Further, in the next versions of the draft time synchronization draft will be studied and adopted if necessary. Examples of binary encoded representations will available in the next versions of this draft.

Header: 4.01 (Unauthorized) Content-Type: application/cbor+pat; pat-type="UnAuthReq" Payload: {#Unprotected AS-Info: "coaps://as.example.com/token", params: { TBD: { ... } } } Figure 3: AS information payload example

If C is registered with the AS as described in [I-D.ietf.ace-oauth-authz] or after C receives AS-Info, the C or CAS (if involved) MUST establish a secure connection channel with the AS. The AS may have an access control list defined by the RO for the clients, with that AS can verify if the client is allowed to establish a secure connection or not. The methods to implement access control in this regard are out of scope of this memo. If the client has valid access to the resource in RS, then AS establishes a confidential channel with C. How this secure connection (example: a DTLS channel) should be established is out of scope of this memo. Notice that, it is important to ensure that this connection is reliable and secure as the remainder of this protocol relies on the fact that the messages exchanged between C and AS are protected and confidential.

Once C establishes a secure communication channel with AS, C sends an access-request (ACC-REQ) message to AS to the endpoint /token requesting an access token for RS as described in [I-D.ietf.ace-oauth-authz]. Optionally, the C includes the details about the resources (R) or the corresponding URI with operations it needs to access or perform on RS to AS as part of the Access-Request Message, if not AS should prepare an access token with default permissions. Fine grained access to resources (R) of RS depends on the infrastructure or services the RS offers. For example, if RS exposes different resources such as temperature and humidity, a generic token may be granted by AS to C to access both resources on RS. On the other hand, the application developer or administrator may decide to have fine grained (different) tokens for each resource. Figure 4 shows an access-request from C for a token to AS. The "aud" represents a specific resource R ("tempSensor") and "scope" represents the allowed actions that C is requesting to perform on the requested resource R as described in [I-D.ietf-ace-oauth-authz] using CWT [I-D.ietf-ace-cbor-web-token]. The Scope parameter can be designed based on application requirements i.e., it can be "read" or "write" or methods such as "GET|POST" etc. Note that we assume a DTLS-based communication defined in the DTLS profile [I.D-draft-gerdes-ace-dtls-authorize] for this example. How the client is authenticating itself to the AS is out of scope of this draft, but in the following example the client presents its credentials i.e., password based authentication by presenting its client_secret (see section 2.3.1. of [RFC6749]).

Header: POST (Code=0.02) Uri-Host: "coaps://as.example.com" Uri-Path: "token" Content-Type: "application/cbor+cwt" Payload: { "grant_type" : "client_credentials", "client_id": "client123", "client_secret": "Secret123", "aud" : "tempSensor", "scope": "GET|POST", ... omitted for brevity ... } Figure 4: Example Client Access-Request message to AS

When AS receives an access-request from a C, AS validates and performs the following: If the access request from C is valid, AS sends the Client-Token CT with COAP response code 2.01 (Created). If the client request is invalid, or does not include required parameters such as "aud" or "cnf", then AS MUST send appropriate COAP error response code as specified in [I-D.ietf-ace-oauth-authz]. The Figure 5 shows the Access request from C to AS and the access-response from AS to C.

,-. ,--. |C| |AS| `+' `+-' | 1 DTLS | |<-----------> | | | | ,------------------------. | | |Header:POST(code=0.02) | |2 Access-REQ| |content-type: | |------------> |application/cbor | | | |URI-Path: token | | | |Payload:{ACC-REQ} | | | `------------------------' | | ,-----------------------------. |3 Access-RSP| |Header: Created (code=2.01) | |<------------ |content-type: | | | |application/cbor | | | |Payload:{ACC-RSP} | ,+. ,+-.`-----------------------------' |C| |AS| `-' `--' Figure 5: Access-Request and Access-Response The Access Request payload is already shown in Figure 4. How AS constructs the Client-Token (CT) and the verifier (the symmetric PoP key) for the C is described in the following: The contents of the access-response (ACC-RSP) payload is logically spit into two major parts, the Client-Token (CT) and the Verifier (Symmetric PoP key). When the Client makes the authorized request to RS, the C will not send the verifier, but only the Client-Token with some additional parameters such as AuthenticationHash to prove RS that C holds the proof-of-possession (PoP) key. The Verifier is constructed in such a way that with the Client-Token the RS is able to construct the Verifier with the shared key (K) between AS and RS. Client-Token construction: Client-Token is constructed using the CWT claim parameters by AS "aud" It contains the resource server URI "scope" (application specific) allowed methods such as GET, POST, PUT or DELETE or permissions such as "read" or "write" "iat" timestamp of AS: token issued "iss" issuer: AS identity "exp" token expires after this many seconds "cti" CWT ID should be unique for every Client-Token can be a sequence number TBD:".." Verifier construction: Verifier (Symmetric PoP key): G (K, Client-Token) G: the MAC algorithm which is used to create the verifier, we propose Poly1305 [RFC7539]. Notice that G is a function which takes two parameters (key, data) as input and produces a keyed digest as the output K: the shared key between AS and RS Client-Token: constructed using CWT claims as explained before Important Note: The Access-Response message with the verifier MUST be sent to C through a secure channel. The Client will use the Verifier as the key material (symmetric PoP key) to communicate with the RS The time-synchronization between AS and RS may be implemented based on the application requirements using [I.D-draft-navas-ace-secure-time-synchronization] or other methods and is out of scope of this draft. Figure 6 shows the example Access-Response from AS to C after successful validation of C's credentials presented in Access-Request message by C. The AS MUST include client_token, the verifier encoded in COSE-key using "cnf" parameter. The AS should specify required parameters as described in [I-D.ietf-ace-oauth-authz] such as the type of token, etc. Also, if the Access-Request from C does not include any profile, AS MUST signal the C to use appropriate or default profile that RS uses in the Access-Response payload.

Header: 2.01 (Created) Content-Type: application/cbor+cwt+pat; pat-type="ct" Location-Path: token/... Payload: { "client_token": b64'SlAV32hkKG ... { "token_type": pop, "aud": "tempSensor", "scope": "read", "seq": 1.., "iat": 1..., "nbf": 0..., "cti": "..", # Unique can be a Sequence Number "exp": 5..., "alg": "chacha20/poly1305", "profile": "ace_pat" } "cnf": { COSE_Key: { "kty": "symmetric", "kid": h'... "k": b64'jb3yjn... #[verifier] } } optional(TBD):{ "LATE time sync" } } Figure 6: Example Access-Response message from AS to C with detailed CWT params and payload info

Once C receives the Access-Response from AS, C can construct an Access-Token (AT) which will demonstrate that C has got the authorization to access resources (R) in RS. The message Resource-Request (RES-REQ) with new AT has to be sent afresh: Client C has to renew his Authorization status at the Resource Server. The frequency in which the Client has to send a new AT can be enforced by RS and is determined indirectly by the owner of RS (or by AS). This allows a fine-grained control on the service level that the Resource Server will provide to the Client (for instance, on the amount of information of sensor data) Each time a RES-REQ is sent from C to RS, a new Access-Token (AT) MAY be needed. Optionally, communications between C and RS can be encrypted to protect the payload and to enforce confidentiality if necessary. PAT profile provides necessary recommendations by using chach20/poly1305 AEAD algorithm. For example if C performs: a CoAP GET() or any other request without any payload may be unprotected. Note: the request from C MAY be unprotected, but the response from RS with payload MUST be always protected and only the valid C can decrypt the response. a CoAP POST() or a CoAP PUT() or a CoAP DELETE() request with payload MUST be protected by using AEAD algorithm presented in Client Token (CT). We propose to use ChaCha20-Poly1305-AEAD authenticated encryption mechanism, while using the Verifier (symmetric PoP key) as the key and a nonce, the AuthenticationHash MAY be integrity protected by using it as Additional Authentication Data (AAD). The RS MUST implement /authz-info endpoint to allow any Client to transfer the access-token as described in [I-D.ietf-ace-oauth-authz]. The Resource-Request message with valid Access-Token shall be constructed by C and can be transported to RS in one of the following ways: option1:

Request Message:{ CoAP request: POST endpoint: /authz-info payload:{ Access-Token:{ Client-Token, AuthenticationHash=Hash(verifier+nonce) } } Figure 7: option1: RES-REQ using /authz-info implemented at RS Figure 7 shows the option1 that specifies the endpoint /authz-info implemented at RS as described in [I-D.ietf-ace-oauth-authz], this option enables the C to transport the access-token to the RS. After receiving the request, RS verifies the access-token, if the access-token is valid a security context is established between RS and C using the verifier. With verifier (a shared symmetric secret) a DTLS channel or OSCOAP or native PAT methods could be used to establish a secure channel between RS and C. Note: more details about native PAT methods will be presented in future versions of this draft. Figure 8 presents representation of POST resource-request from C to RS described in [I-D.ietf-ace-oauth-authz] with pat-type="AuthReq".

Header: POST (Code=0.02) Content-Type: application/cose+cbor+pat; pat-type="AuthReq"; Uri-Host: "coap://rs.example" Uri-Path: /authz-info Payload: { # Unprotected access_token: { "client_token": b64'SlAV32hkKG { "aud": "tempSensor" "scope": "read" ... CWT omitted for brevity. } "nonce": "C_nonce" "auth_hash": b64'v4Sugr7.. #[Hash=(verifier+nonce)] } } Figure 8: Example of valid option1 request from C to RS using endpoint /authz-info. option2:

Request Message:{ CoAP request: GET/POST/PUT/DELETE Access-Token: Client-Token, AuthenticationHash= Hash(verifier+C_nonce) MSG_PAYLOAD: Chach20/Poly1305(Verifier,C_nonce, AAD=null, payload) } Figure 9: Example of option2 RES-REQ with native PAT token transfer method Figure 9 shows the alternative native PAT method for transporting the tokens from C to RS. In the example presented, the C may request the known URI path where the resource is available with the access-token which includes the Client-Token and the AuthenticationHash which is the result of the Hash function of (verifier + the C_nonce). TBD: if a CoAP message does not have any payload to carry, the access token shall be presented to RS using CoAP option. Figure 10 shows the detailed description of the option2 PAT method to transfer access-tokens from C to RS. In the presented example, the Uri-Path "/firmware" allows the authorized client to perform firmware upgrade on the RS. PAT recommends to protect sensitive information payload using chacha20/poly1305 AEAD algorithm and the symmetric PoP key (the Verifier), the result will generate a Cipher text and a tag which is enclosed in the payload. TBD: as part of additional authenticated data (AAD) the client may include "auth_hash".

Header: POST (Code=0.02) Content-Type: application/cose+cbor+pat; cose-type="encrypt0"; "pat-type="AuthReq"; Uri-Host: "coap://rs.example" Uri-Path: /firmware Payload: {# COSE Unprotected access_token: { "client_token": b64'SlAV32hkKG { "aud": "firmwareUpd" "scope": "write" ... CWT omitted for brevity, } "nonce": .. # C_nonce "auth_hash": h'bfa03.. #[Hash=(verifier+nonce)] } # COSE_Encrypt0 + COSE_MAC0 Protected ciphertext:{ #Chacha20/Poly1305 AEAD payload using # key=verifier, # nonce=C_nonce, # AAD=auth_hash h'....omitted for brevity }, tag: h'... omitted for brevity } Figure 10: Example of valid POST request from C to RS

When the request with access-token arrives the RS from a C, RS MUST evaluate the resource request and its access-token in the following order: Step1: extract the client-token, nonce and AuthenticationHash from the access-token. Step1.1: (if available) verify the freshness of the sequence number in the client token presented by AS. Step2: generate the verifier by computing MAC(K, client-token) where K is shared key between AS and RS. Step2.1: compute verificationHash as Hash(verifier+nonce) and compare the result with AuthenticationHash. Step3: check if the client-token has right CWT parameters such as "aud", "scope", "exp", "nbf", etc for the requested resource or action to be performed. Step4: TBD: (if available) synchronize RS internal clock with AS as described in [I.D-draft-navas-ace-secure-time-synchronization] Response to request option1: When RS receives resource-request from a C of type option1, RS validates the access-token as described above, If the access-token is valid, the RS MUST respond to the POST request with code 2.04 (changed). If the access-token is invalid, then RS MUST respond to the POST request with code 4.01 (Unauthorized) Figure 11 shows an example of successful request and response for option1 to the endpoint /authz-info implemented in RS, RS should maintain a security context to enable subsequent communication channel with RS. RS could establish a secure channel with the initial PAT secret (the Verifier) i.e., the symmetric PoP key between C and RS using the DTLS profile described in [I.D-draft-gerdes-ace-dtls-authorize]. Further information about other methods of establishing secure channel will be presented in the future version of this draft.

,-. ,--. |C| |RS| `+' `+-' | | ,-----------------------------. | | |Code: POST | | 1 Res-REQ | |URI-Path: /authz-info | |----------->| |Payload:{ | | | |access-token:{client-token, | | | | auth_hash | | | | } | | | `-----------------------------' | 2 Res-RSP | ,----------------------. |<-----------| |Code: 2.04 (changed) | ,+. ,+-.`----------------------' |C| |RS| `-' `--' Figure 11: Example RS response to C request on /authz-info Response to request option2: If RS receives an option2 resource-request from C, RS should verify the following conditions before sending a response to C: If the access-token is valid, the RS MUST respond to the POST request with 2.01 (created) or 2.04 (changed). If the access-token is invalid, then RS MUST respond to the POST request with code 4.01 (Unauthorized) If the token is valid but does not match the "aud" or resource C is requesting for then RS MUST respond with code 4.03 (Forbidden) If the Access-Token is valid for every condition, then RS prepares a valid response. If request message's payload is encrypted, RS decrypts it using ChaCha20/Poly1305 AEAD algorithm using (key=verifier, nonce=C_nonce, AAD, payload). The response from RS MUST be encrypted so that only C with a valid key (the Verifier or using derived keys for subsequent messages) can decrypt the payload:

Encrypted Response payload:{ CoAP request: request type RSP_MSG_PAYLOAD: Chach20/Poly1305(Key=verifier, nonce = nonce++, AAD, payload) } Figure 12: Example of RS response payload with Encryption for native PAT request option2 Notice the difference in the nonce parameter. A difference nonce MUST be used while encrypting the response, generally incrementing the nonce parameter is acceptable. Figure 13 shows Authorized resource request from C->RS and response message RS->C.

,-. ,--. |C| |RS| `+' `+-' | | ,-----------------------. | | |Code: POST | | | |URI-Path: /firmware | | | |Payload: | | | |{ | | 1 Res-REQ | | access-token: | |----------->| | {Client-Token, | | | | AuthHash} | | | | chacha20/poly1305( | | | | key=Verifier, | | | | nonce=C_nonce, | | | | AAD, | | | | data=firmware)} | | | `-----------------------' | | ,--------------------------. | | |Code:2.01(Created) | | | |Location-Path:/... | | 2 Res-RSP | |Payload: | |<-----------| |{ chacha20/poly1305 | | | | (key=Verifier, | | | | nonce=nonce++, AAD, | | | | data=value)} | ,+. ,+-.`--------------------------' |C| |RS| `-' `--' Figure 13: [C<->RS] Authorized Resource Request and Response for native PAT request option2 Figure 14 shows the valid response from RS to C for the request type option2 presented in previous section. The chacha20/poly1305 function produces a ciphertext and a tag. It is important to note that "cks" means that C and RS understand the parameters for cryptographic operations that they use for communication.

Header: 2.01/2.04 (Created/Changed) Content-Type: application/cose; Payload: { cks: # COSE_Encrypt0 + COSE_MAC0 Protected { ciphertext:{ # Chacha20/Poly1305 # key=verifier, nonce=nonce++, payload ....omitted for brevity... } tag: ...omitted for brevity.. } } Figure 14: Example of valid response from RS to C for native PAT request option2

TBD

The CoAP messaging layer parameters such as token and message-id can be used for matching a specific request and response. TBD

TBD

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7252] Shelby, Z., Hartke, K. and Borman, C., "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC6347] Rescorla E. and Modadugu N., "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC4279] Eronen P. and Tschofenig H., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, December 2005. [RFC7539] Y. Nir and A. Langley: ChaCha20 and Poly1305 for IETF Protocols, RFC7539, May 2015 [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An architecture for authorization in constrained environments", draft-ietf-ace-actors-04 (work in progress), March 2017. [I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W., Mishra, P., and H. Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", draft-ietf-oauth-pop-architecture-07 (work in progress), December 2015. [I-D.ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authorization for the Internet of Things using OAuth 2.0", draft-ietf-ace-oauth-authz-04 (work in progress), October 2016. [I-D.ietf-core-object-security] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security of CoAP (OSCOAP)", draft-ietf-core-object-security-00 (work in progress), october 2016. [I-D.ietf-cose-msg] Schaad, J., "CBOR Object Signing and Encryption (COSE)", draft-ietf-cose-msg-24 (work in progress), November 2016.

[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.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Van der Stok, P., "CoRE Resource Directory", draft-ietf-core-resource-directory-08 (work in progress), July 2016. [I.D-draft-navas-ace-secure-time-synchronization] Navas, G., Selander, G., Seitz, L., "Lightweight Authenticated Time (LATe) Synchronization Protocol", draft-navas-ace-secure-time-synchronization-00 (work in progress), October 2016. [I.D-draft-gerdes-ace-dtls-authorize] Gerdes, S., Begmann, O., Bormann, C., Selander, G., Seitz, L. Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE),draft-gerdes-ace-dtls-authorize-00, October 2016 [I-D.ietf-ace-cbor-web-token] Jones, M., Tschofenig, H., Erdtman, S., CBOR Web Token (CWT), draft-ietf-ace-cbor-web-token-01 (work in progress), July 2016.

This draft is the result of collaborative research in the RERUM EU funded project and has been partly funded by the European Commission (Contract No. 609094). The authors thank Ludwig Seitz for reviewing previous version of the draft.

TBD

|----------------------+-----| | ACE profile template | PAT | |----------------------+-----| | Profile name | TBD | | Profile Description | TBD | | Profile ID | TBD | |----------------------+-----| Table2: ACE profile registration template

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 .