--- 1/draft-ietf-ace-oscore-profile-16.txt 2021-03-22 13:29:48.142359370 -0700 +++ 2/draft-ietf-ace-oscore-profile-17.txt 2021-03-22 13:29:48.214361162 -0700 @@ -1,24 +1,24 @@ ACE Working Group F. Palombini Internet-Draft Ericsson AB Intended status: Standards Track L. Seitz -Expires: August 1, 2021 Combitech +Expires: September 9, 2021 Combitech G. Selander Ericsson AB M. Gunnarsson RISE - January 28, 2021 + March 8, 2021 OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework - draft-ietf-ace-oscore-profile-16 + draft-ietf-ace-oscore-profile-17 Abstract This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. Status of This Memo @@ -29,21 +29,21 @@ 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 https://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 August 1, 2021. + This Internet-Draft will expire on September 9, 2021. Copyright Notice Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -129,25 +129,25 @@ Readers are expected to be familiar with the terms and concepts defined in OSCORE [RFC8613], such as "Security Context" and "Recipient ID". Terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749], such as client (C), resource server (RS), and authorization server (AS). It is assumed in this document that a given resource on a specific RS is associated to a unique AS. - Concise Binary Object Representation (CBOR) [I-D.ietf-cbor-7049bis] - and Concise Data Definition Language (CDDL) [RFC8610] are used in - this specification. CDDL predefined type names, especially bstr for - CBOR byte strings and tstr for CBOR text strings, are used - extensively in the document. + Concise Binary Object Representation (CBOR) [RFC8949] and Concise + Data Definition Language (CDDL) [RFC8610] are used in this + specification. CDDL predefined type names, especially bstr for CBOR + byte strings and tstr for CBOR text strings, are used extensively in + the document. Note that the term "endpoint" is used here, as in [I-D.ietf-ace-oauth-authz], following its OAuth definition, which is to denote resources such as token and introspect at the AS and authz- info at the RS. The CoAP [RFC7252] definition, which is "An entity participating in the CoAP protocol" is not used in this memo. 2. Protocol Overview This section gives an overview of how to use the ACE Framework @@ -206,34 +206,35 @@ Finally, the client starts the communication with the RS by sending a request protected with OSCORE to the RS. If the request is successfully verified, the server stores the complete Security Context state that is ready for use in protecting messages, and uses it in the response, and in further communications with the client, until token deletion, due to e.g. expiration. This Security Context is discarded when a token (whether the same or a different one) is used to successfully derive a new Security Context for that client. - The use of nonces during the exchange prevents the reuse of an - Authenticated Encryption with Associated Data (AEAD) nonces/key pair - for two different messages. Reuse might otherwise occur when client - and RS derive a new Security Context from an existing (non- expired) - access token, as might occur when either party has just rebooted, and - might lead to loss of both confidentiality and integrity. Instead, - by using nonces as part of the Master Salt, the request to the authz- - info endpoint posting the same token results in a different Security - Context, by OSCORE construction, since even though the Master Secret, - Sender ID and Recipient ID are the same, the Master Salt is different - (see Section 3.2.1 of [RFC8613]). If nonces were reused, a node - reusing a non-expired old token would be susceptible to on-path - attackers provoking the creation of OSCORE messages using old AEAD - keys and nonces. + The use of nonces N1 and N2 during the exchange prevents the reuse of + an Authenticated Encryption with Associated Data (AEAD) nonce/key + pair for two different messages. Reuse might otherwise occur when + client and RS derive a new Security Context from an existing (non- + expired) access token, as might occur when either party has just + rebooted, and might lead to loss of both confidentiality and + integrity. Instead, by using the exchanged nonces N1 and N2 as part + of the Master Salt, the request to the authz-info endpoint posting + the same token results in a different Security Context, by OSCORE + construction, since even though the Master Secret, Sender ID and + Recipient ID are the same, the Master Salt is different (see + Section 3.2.1 of [RFC8613]). If the exchanged nonces were reused, a + node reusing a non-expired old token would be susceptible to on-path + attackers provoking the creation of an OSCORE message using an old + AEAD key and nonce. After the whole message exchange has taken place, the client can contact the AS to request an update of its access rights, sending a similar request to the token endpoint that also includes an identifier so that the AS can find the correct OSCORE security input material it has previously shared with the client. This specific identifier, encoded as a byte string, is assigned by the AS to be unique in the sets of its OSCORE security input materials, and is not used as input material to derive the full OSCORE Security Context. @@ -262,22 +263,21 @@ | | | | <--- OSCORE Response ----- | | | | | /proof-of-possession | | Sec Context storage/ | | | | | | ---- OSCORE Request -----> | | | | | | <--- OSCORE Response ----- | | | | | - /mutual ... | | - authentication/ + | ... | | Figure 1: Protocol Overview 3. Client-AS Communication The following subsections describe the details of the POST request and response to the token endpoint between client and AS. Section 3.2 of [RFC8613] defines how to derive a Security Context based on a shared master secret and a set of other parameters, established between client and server, which the client receives from @@ -675,39 +675,39 @@ 4. Client-RS Communication The following subsections describe the details of the POST request and response to the authz-info endpoint between client and RS. The client generates a nonce N1 and an identifier ID1 unique in the sets of its own Recipient IDs, and posts them together with the token that includes the materials (e.g., OSCORE parameters) received from the AS to the RS. The RS then generates a nonce N2 and an identifier ID2 unique in the sets of its own Recipient IDs, and uses Section 3.2 of [RFC8613] to derive a security context based on a shared master - secret, the two nonces and the two identifiers, established between - client and server. The nonces and identifiers are encoded as CBOR - byte string if CBOR is used, and as Base64 string if JSON is used. - This security context is used to protect all future communication - between client and RS using OSCORE, as long as the access token is - valid. + secret, the two exchanged nonces and the two identifiers, established + between client and server. The exchanged nonces and identifiers are + encoded as CBOR byte string if CBOR is used, and as Base64 string if + JSON is used. This security context is used to protect all future + communication between client and RS using OSCORE, as long as the + access token is valid. Note that the RS and client authenticates each other by generating the shared OSCORE Security Context using the pop-key as master secret. An attacker posting a valid token to the RS will not be able to generate a valid OSCORE Security Context and thus not be able to prove possession of the pop-key. Additionally, the mutual authentication is only achieved after the client has successfully verified a response from the RS protected with the generated OSCORE Security Context. 4.1. C-to-RS: POST to authz-info endpoint - The client MUST generate a nonce value very unlikely to have been + The client MUST generate a nonce value N1 very unlikely to have been previously used with the same input keying material. This profile RECOMMENDS to use a 64-bit long random number as nonce's value. The client MUST store the nonce N1 as long as the response from the RS is not received and the access token related to it is still valid (to the best of the client's knowledge). The client generates its own Recipient ID, ID1, for the OSCORE Security Context that it is establishing with the RS. By generating its own Recipient ID, the client makes sure that it does not collide with any of its Recipient IDs, nor with any other identifier ID1 if @@ -732,22 +732,22 @@ The communication with the authz-info endpoint does not have to be protected, except for the update of access rights case described below. Note that a client may be required to re-POST the access token in order to complete a request, since an RS may delete a stored access token (and associated Security Context) at any time, for example due to all storage space being consumed. This situation is detected by the client when it receives an AS Request Creation Hints response. Reposting the same access token will result in deriving a new OSCORE - Security Context to be used with the RS, as different nonces will be - used. + Security Context to be used with the RS, as different exchanged + nonces will be used. The client may also chose to re-POST the access token in order to renew its OSCORE Security Context. In that case, the client and the RS will exchange newly generated nonces, re-negotiate identifiers, and derive new keying material. The client and RS might decide to keep the same identifiers or renew them during the re-negotiation. Figure 10 shows an example of the request sent from the client to the RS, with payload in CBOR diagnostic notation without the tag and value abbreviations. The access token has been truncated for @@ -902,37 +902,39 @@ N1, N2 and input salt expressed in CBOR diagnostic notation: nonce1 = h'018a278f7faab55a' nonce2 = h'25a8991cd700ac01' input salt = h'f9af838368e353e78888e1426bd94e6f' N1, N2 and input salt as CBOR encoded byte strings: nonce1 = 0x48018a278f7faab55a nonce2 = 0x4825a8991cd700ac01 input salt = 0x50f9af838368e353e78888e1426bd94e6f -Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f 48 018a278f7faab55a 48 25a8991cd700ac01 + Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f + 48 018a278f7faab55a 48 25a8991cd700ac01 Figure 12: Example of Master Salt construction using CBOR encoding If JSON is used instead of CBOR, the Master Salt of the Security Context is the Base64 encoding of the concatenation of the same parameters, each of them prefixed by their size, encoded in 1 byte. When using JSON, the nonces and input salt have a maximum size of 255 bytes. An example of Master Salt construction using Base64 encoding is given in Figure 13. N1, N2 and input salt values: nonce1 = 0x018a278f7faab55a (8 bytes) nonce2 = 0x25a8991cd700ac01 (8 bytes) input salt = 0xf9af838368e353e78888e1426bd94e6f (16 bytes) -Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f 08 018a278f7faab55a 08 25a8991cd700ac01 + Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f + 08 018a278f7faab55a 08 25a8991cd700ac01 Master Salt = b64'EPmvg4No41PniIjhQmvZTm8IAYonj3+qtVoIJaiZHNcArAE=' Figure 13: Example of Master Salt construction using Base64 encoding The client MUST set the Sender ID to the ace_server_recipientid received in Section 4.2, and the Recipient ID to the ace_client_recipientid sent in Section 4.1. The client MUST set the Master Secret from the parameter received from the AS in Section 3.2. The client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE @@ -1093,33 +1095,34 @@ the OSCORE response from the RS pass verification. OSCORE is designed to secure point-to-point communication, providing a secure binding between the request and the response(s). Thus the basic OSCORE protocol is not intended for use in point-to-multipoint communication (e.g., multicast, publish-subscribe). Implementers of this profile should make sure that their use case corresponds to the expected use of OSCORE, to prevent weakening the security assurances provided by OSCORE. - Since the use of nonces in the exchange guarantees uniqueness of AEAD - keys and nonces, it is REQUIRED that nonces are not reused with the - same input keying material even in case of re-boots. This document - RECOMMENDS the use of 64 bit random nonces. Considering the birthday - paradox, the average collision for each nonce will happen after 2^32 - messages, which is considerably more token provisionings than - expected for intended applications. If applications use something - else, such as a counter, they need to guarantee that reboot and loss - of state on either node does not provoke reuse. If that is not - guaranteed, nodes are susceptible to reuse of AEAD (nonces, keys) - pairs, especially since an on-path attacker can cause the client to - use an arbitrary nonce for Security Context establishment by - replaying client-to-server messages. + Since the use of nonces N1 and N2 during the exchange guarantees + uniqueness of AEAD keys and nonces, it is REQUIRED that the exchanged + nonces are not reused with the same input keying material even in + case of re-boots. This document RECOMMENDS the exchange of 64 bit + random nonces. Considering the birthday paradox, the average + collision for each nonce will happen after 2^32 messages, which is + considerably more token provisionings than expected for intended + applications. If applications use something else, such as a counter, + they need to guarantee that reboot and loss of state on either node + does not provoke reuse. If that is not guaranteed, nodes are + susceptible to reuse of AEAD (nonce, key) pairs, especially since an + on-path attacker can cause the use of a previously exchanged client + nonce N1 for Security Context establishment by replaying the + corresponding client-to-server message. This profile recommends that the RS maintains a single access token for each client. The use of multiple access tokens for a single client increases the strain on the resource server as it must consider every access token and calculate the actual permissions of the client. Also, tokens indicating different or disjoint permissions from each other may lead the server to enforce wrong permissions. If one of the access tokens expires earlier than others, the resulting permissions may offer insufficient protection. Developers should avoid using multiple access tokens for a same @@ -1357,25 +1359,20 @@ H. Tschofenig, "Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 (work in progress), November 2020. [I-D.ietf-ace-oauth-params] Seitz, L., "Additional OAuth Parameters for Authorization in Constrained Environments (ACE)", draft-ietf-ace-oauth- params-13 (work in progress), April 2020. - [I-D.ietf-cbor-7049bis] - Bormann, C. and P. Hoffman, "Concise Binary Object - Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work - in progress), September 2020. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . @@ -1395,20 +1392,25 @@ Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, . + [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object + Representation (CBOR)", STD 94, RFC 8949, + DOI 10.17487/RFC8949, December 2020, + . + 10.2. Informative References [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, .