Internet DRAFT - draft-palombini-ace-oscore-profile-v2

draft-palombini-ace-oscore-profile-v2







ACE Working Group                                           F. Palombini
Internet-Draft                                               Ericsson AB
Intended status: Standards Track                      September 21, 2020
Expires: March 25, 2021


                        OSCORE Profile of ACE v2
                draft-palombini-ace-oscore-profile-v2-00

Abstract

   This document 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.
   Additionally, this profile provides OSCORE identifiers negotiation
   between Client and Resource Server.

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 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 March 25, 2021.

Copyright Notice

   Copyright (c) 2020 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
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Palombini                Expires March 25, 2021                 [Page 1]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Client-AS Communication . . . . . . . . . . . . . . . . . . .   5
     3.1.  C-to-AS: POST to token endpoint . . . . . . . . . . . . .   5
     3.2.  AS-to-C: Access Token . . . . . . . . . . . . . . . . . .   6
   4.  Client-RS Communication . . . . . . . . . . . . . . . . . . .  10
     4.1.  C-to-RS: POST to authz-info endpoint  . . . . . . . . . .  10
     4.2.  RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . .  11
     4.3.  OSCORE Setup  . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  ACE Profile Registry  . . . . . . . . . . . . . . . . . .  13
     7.2.  OAuth Parameters Registry . . . . . . . . . . . . . . . .  13
     7.3.  OAuth Parameters CBOR Mappings Registry . . . . . . . . .  13
     7.4.  OSCORE Security Context Parameters Registry . . . . . . .  14
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   An OSCORE profile of ACE is defined in [I-D.ietf-ace-oscore-profile].
   That profiles describes how to set up OSCORE between nodes, while the
   OSCORE Sender and Recipient Identifiers, i.e. the identifiers of the
   OSCORE keying material, are assigned by the Authorization Server.
   This has some limitations, especially if the OSCORE profile is used
   in conjuction with other mechamisms that also derive identifiers, in
   which case there needs to be a mechanism in place to avoid
   collisions.

   This document describes a new OSCORE profile that builds on
   [I-D.ietf-ace-oscore-profile], and adds a mechanism for negotiating
   identifiers between Client and Resource Server.








Palombini                Expires March 25, 2021                 [Page 2]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Readers are expected to be familiar with the terms and concepts
   described in [I-D.ietf-ace-oauth-authz]
   [I-D.ietf-ace-oscore-profile], such as Authorization Server (AS) and
   Resource Server (RS).

   Readers are expected to be familiar with the terms and concepts
   described in [RFC8613], especially on the use of Sender, Recipient
   and Context Identifiers.

1.2.  Background

   TODO: introduce OSCORE Sender and Recipient Identifiers and how they
   are used in OSCORE.

   The OSCORE profile defined in [I-D.ietf-ace-oscore-profile] specifies
   that the AS assigns and sends the OSCORE Sender and Recipient
   Identifiers to both Client and RS, together with the rest of the
   input material to derive the complete OSCORE Security Context.  That
   is done by including these identifiers in the Access Token and Access
   Information response to the Client.  The access token containing
   these identifiers is also forwarded to the RS by the Client.

   This works with a number of requirements: the OSCORE profile states
   that if other authentication mechanisms are used to set up OSCORE
   between the same client and RS, that do not rely on an AS assigning
   identifiers, collisions may happen and need to be mitigated.  Such
   mitigation mechanisms also need to be used if a different AS (which
   does not synchronize identifiers with the first AS) or authentication
   protocol is used to set up OSCORE between the same RS and other
   clients.  A mitigation example would be to use distinct namespaces of
   context identifiers for different authentication mechanisms or
   authentication servers.  Another solution would be to use longer
   random identifiers.  A third possible solution, acceptable if
   collisions are not expected to be numerous, would be to rely on trial
   and error of security contexts when receiving a message.

   These solutions have the drawback of requiring either some sort of
   agreement between different authentication mechanisms using disjoint
   namespaces for the identifiers, and/or longer identifiers to be used,




Palombini                Expires March 25, 2021                 [Page 3]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   which leads to larger message sizes, or additional processing on the
   RS.

   This document specifies an OSCORE profile that adds a mechanism to
   assign identifiers on top of the current OSCORE profile, and that
   allows to set up identifiers without collisions, even when other
   authentication mechanisms or non-syncrhonized AS are used.  What
   specified in [I-D.ietf-ace-oscore-profile] applies to this profile as
   well, with the modifications reported in the following sections.
   Although defining a separate profile, the reader is advised that the
   [I-D.ietf-ace-oscore-profile] needs to be read side by side with this
   specification, to understand it.

2.  Protocol Overview

   This section defines the additions to Section 2 of
   [I-D.ietf-ace-oscore-profile].

   Once the client has retrieved the access token, and generated the
   nonce N1, the Client also generates a Recipient Identifier ID1 for
   use with the keying material associated to the RS.  The client posts
   the token, N1 and its Recipient ID to the RS using the authz-info
   endpoint and mechanisms specified in section 5.8 of
   [I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor.

   If the access token is valid, the RS replies to this request with a
   2.01 (Created) response with Content-Format = application/ace+cbor,
   which contains a nonce N2 and a newly generated Recipient Identifier
   ID2 for use with the keying material associated to the Client in a
   CBOR map.  Moreover, the server concatenates the input salt, N1, and
   N2 to obtain the Master Salt of the OSCORE Security Context (see
   section 3 of [RFC8613]).  The RS then derives the complete Security
   Context associated with the received token from the Master Salt, the
   Recipient ID generated by the Client (set as its OSCORE Sender Id),
   the Recipient ID generated by itself (set as its OSCORE Recipient
   Id), plus the parameters received in the access token from the AS,
   following section 3.2 of [RFC8613].

   In a similar way, after receiving the nonce N2, the client
   concatenates the input salt, N1 and N2 to obtain the Master Salt of
   the OSCORE Security Context.  The client then derives the complete
   Security Context from the Master Salt, the Recipient ID generated by
   the RS (set as its OSCORE Sender Id), the Recipient ID generated by
   itself (set as its OSCORE Recipient Id), plus the parameters received
   from the AS.

   After the whole message exchange has taken place, the client can
   contact the AS to request an update of its access rights, sending a



Palombini                Expires March 25, 2021                 [Page 4]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   similar request to the token endpoint that also includes an
   identifier so that the AS can find the correct OSCORE security
   material it has previously shared with the Client.  This specific
   identifier, encoded as a byte string, is set by the AS to be unique
   in the sets of its OSCORE Security Contexts, and is not used as input
   material to derive the full OSCORE Security Context.

             C                            RS                   AS
             |                            |                     |
             | ----- POST /token  ----------------------------> |
             |                            |                     |
             | <---------------------------- Access Token ----- |
             |                           + Access Information   |
             | ---- POST /authz-info ---> |                     |
             |  (access_token, N1, Id1)   |                     |
             |                            |                     |
             | <- 2.01 Created (N2, Id2)- |                     |
             |                            |                     |
           /Sec Context             /Sec Context                |
             Derivation/              Derivation/               |
             |                            |                     |
             | ---- OSCORE Request -----> |                     |
             |                            |                     |
             |                    /proof-of-possession          |
             |                    Sec Context storage/          |
             |                            |                     |
             | <--- OSCORE Response ----- |                     |
             |                            |                     |
          /proof-of-possession            |                     |
          Sec Context storage/            |                     |
             |                            |                     |
             | ---- OSCORE Request -----> |                     |
             |           ...              |                     |

                   Figure 1: OSCORE Profile v2 Overview

3.  Client-AS Communication

   The following subsections apply modifications to what specified in
   Section 3 of [I-D.ietf-ace-oscore-profile].

3.1.  C-to-AS: POST to token endpoint

   If the client wants to update its access rights without changing an
   existing OSCORE Security Context, it MUST include in its POST request
   to the token endpoint a req_cnf object.  The req_cnf MUST include a
   kid field carrying a CBOR byte string containing the




Palombini                Expires March 25, 2021                 [Page 5]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   OSCORE_Input_Material Identifier (assigned as discussed in
   Section 3.2).

   An example of an update of access rights request, with payload in
   CBOR diagnostic notation without the tag and value abbreviations is
   reported in Figure 2.

   Header: POST (Code=0.02)
   Uri-Host: "as.example.com"
   Uri-Path: "token"
   Content-Format: "application/ace+cbor"
   Payload:
   {
    "req_aud" : "tempSensor4711",
    "scope" : "write",
    "req_cnf" : {
      "kid" : h'01'
   }

   Figure 2: Example C-to-AS POST /token request for updating rights to
                 an access token bound to a symmetric key.

3.2.  AS-to-C: Access Token

   The AS can signal that the use of OSCORE is REQUIRED for a specific
   access token by including the "profile" parameter with the value
   "coap_oscore_2" in the access token response.

   The AS MUST send the following data:

   o  a master secret

   o  an identifier of the OSCORE_Input_Material

   The AS MUST NOT include clientId or serverId, in the
   OSCORE_Input_Material, neither in the 'cnf' nor in the claims sets
   associated with the access token.

   The identifier of the OSCORE_Input_Material MUST be communicated as
   the 'id' field in the 'osc' field in the 'cnf' parameter of the
   access token response (and therefore included in the claims
   associated with the access token).

   We don't assume in this document that a resource is associated to one
   single AS, since the AS is not tasked with enforcing uniqueness of
   identifiers for each client requesting a particular resource to a RS.
   This profile can also be used together with other authentication
   mechanisms such as EDHOC, see [I-D.ietf-lake-edhoc].



Palombini                Expires March 25, 2021                 [Page 6]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   Figure 3 shows an example of an AS response, with payload in CBOR
   diagnostic notation without the tag and value abbreviations.  The
   access token has been truncated for readability.

   Header: Created (Code=2.01)
   Content-Type: "application/ace+cbor"
   Payload:
   {
    "access_token" : h'8343a1010aa2044c53 ...
     (remainder of access token (CWT) omitted for brevity)',
    "profile" : "coap_oscore_2",
    "expires_in" : "3600",
    "cnf" : {
      "osc" : {
        "ms" : h'f9af838368e353e78888e1426bd94e6f',
        "id" : h'01'
      }
    }
   }

    Figure 3: Example AS-to-C Access Token response with OSCORE profile
                                    2.

   Figure 4 shows an example CWT Claims Set, including the relevant
   OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation
   without tag and value abbreviations.

   {
    "aud" : "tempSensorInLivingRoom",
    "iat" : "1360189224",
    "exp" : "1360289224",
    "scope" :  "temperature_g firmware_p",
    "cnf" : {
      "osc" : {
        "ms" : h'f9af838368e353e78888e1426bd94e6f',
        "id" : h'01'
      }
    }
   }

         Figure 4: Example CWT Claims Set with OSCORE parameters.

   The same CWT Claims Set as in Figure 4, using the value abbreviations
   defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in
   CBOR is shown in Figure 5.  The bytes in hexadecimal are reported in
   the first column, while their corresponding CBOR meaning is reported
   after the '#' sign on the second column, for easiness of readability.




Palombini                Expires March 25, 2021                 [Page 7]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   A5                                      # map(5)
      63                                   # text(3)
         617564                            # "aud"
      76                                   # text(22)
         74656D7053656E736F72496E4C6976696E67526F6F6D
                                           # "tempSensorInLivingRoom"
      63                                   # text(3)
         696174                            # "iat"
      6A                                   # text(10)
         31333630313839323234              # "1360189224"
      63                                   # text(3)
         657870                            # "exp"
      6A                                   # text(10)
         31333630323839323234              # "1360289224"
      65                                   # text(5)
         73636F7065                        # "scope"
      78 18                                # text(24)
         74656D70657261747572655F67206669726D776172655F70
                                           # "temperature_g firmware_p"
      63                                   # text(3)
         636E66                            # "cnf"
      A1                                   # map(1)
         63                                # text(3)
            6F7363                         # "osc"
         A2                                # map(2)
            62                             # text(2)
               6D73                        # "ms"
            50                             # bytes(16)
               F9AF838368E353E78888E1426BD94E6F
                                           # "\xF9\xAF\x83\x83h\xE3S\xE7
                                           \x88\x88\xE1Bk\xD9No"
            62                             # text(2)
               6964                        # "id"
            41                             # bytes(1)
               01                          # "\x01"


   Figure 5: Example CWT Claims Set with OSCORE parameters, CBOR encoded

   If the client has requested an update to its access rights using the
   same OSCORE_Input_Material, which is valid and authorized, the AS
   MUST omit the 'cnf' parameter in the response, and MUST carry the
   OSCORE_Input_Material Identifier in the 'kid' field in the 'cnf'
   parameter of the token.  This identifier needs to be included in the
   token in order for the RS to identify the correct OSCORE Input
   Material.





Palombini                Expires March 25, 2021                 [Page 8]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   Figure 6 shows an example of such an AS response, with payload in
   CBOR diagnostic notation without the tag and value abbreviations.
   The access token has been truncated for readability.

   Header: Created (Code=2.01)
   Content-Type: "application/ace+cbor"
   Payload:
   {
    "access_token" : h'8343a1010aa2044c53 ...
     (remainder of access token (CWT) omitted for brevity)',
    "profile" : "coap_oscore_2",
    "expires_in" : "3600"
   }

   Figure 6: Example AS-to-C Access Token response with OSCORE profile,
                       for update of access rights.

   Figure 7 shows an example CWT Claims Set, containing the necessary
   OSCORE parameters in the 'cnf' claim for update of access rights, in
   CBOR diagnostic notation without tag and value abbreviations.

   {
    "aud" : "tempSensorInLivingRoom",
    "iat" : "1360189224",
    "exp" : "1360289224",
    "scope" :  "temperature_h",
    "cnf" : {
      "kid" : h'01'
    }
   }

                                 Figure 7

3.2.1.  OSCORE_Input_Material Object

   The following parameter is added to the OSCORE_Input_Material object
   defined in Section 3.2.1 of [I-D.ietf-ace-oscore-profile].

   +------------+-------+-------------+------------+--------------+
   | name       | CBOR  | CBOR type   | registry   | description  |
   |            | label |             |            |              |
   +------------+-------+-------------+------------+--------------+
   | identifier | 8     | byte string |            | OSCORE Input |
   |            |       |             |            | Material     |
   |            |       |             |            | Identifier   |
   +------------+-------+-------------+------------+--------------+

           Figure 8: OSCORE_Input_Material Additional Parameters



Palombini                Expires March 25, 2021                 [Page 9]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   id:  This parameter identifies the OSCORE_Input_Material and is
      encoded as a byte string.  In JSON, the "id" value is a Base64
      encoded byte string.  In CBOR, the "id" type is byte string, and
      has label 8.

4.  Client-RS Communication

   Additionally to what specified in Section 4 of
   [I-D.ietf-ace-oscore-profile], the client also generates an
   identifier id1, unique in the sets of its own Recipient Ids, and
   posts it together with the token and nonce N1 to the RS.  The RS also
   generates an identifier id2, unique in the sets of its own Recipient
   Ids, and uses it together with the rest of the input material to
   derive a security context.  Both the nonces and identifiers are
   encoded as CBOR bstr if CBOR is used, and as Base64 string if JSON is
   used.

4.1.  C-to-RS: POST to authz-info endpoint

   Additionally to what specified in Section 4.1 of
   [I-D.ietf-ace-oscore-profile], the following applies.

   The client generates its own Recipient Id 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 Identifiers.  The client posts it to the RS together
   with what is described in Section 4.1 of
   [I-D.ietf-ace-oscore-profile]: the client includes the Recipient Id
   in the POST to authz-info request, as an ace_client_recipientid
   parameter, registered in Section 7.2 and Section 7.3.

   When receiving the POST to authz-info request including the
   ace_client_recipientid parameter, the RS MUST set its own Sender
   Identifier to the value of the ace_client_recipientid.  If the
   ace_client_recipientid parameter is not included in the request, the
   RS MUST stop processing the request and interrupt the Ace exchange,
   and MAY reply with a 4.00 (Bad Request) error message.

   If the access token received contains either the clientId or serverId
   parameters, the server SHOULD stop processing the message, and MAY
   reply with a 4.00 (Bad Request) error message.

   Figure 9 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
   readability.





Palombini                Expires March 25, 2021                [Page 10]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   Header: POST (Code=0.02)
   Uri-Host: "rs.example.com"
   Uri-Path: "authz-info"
   Content-Format: "application/ace+cbor"
   Payload:
    {
      "access_token": h'8343a1010aa2044c53 ...
   (remainder of access token (CWT) omitted for brevity)',
      "nonce1": h'018a278f7faab55a',
      "ace_client_recipientid" : h'11'
    }

                                 Figure 9

4.1.1.  The ace_client_recipientid Parameter

   This parameter MUST be sent from the client to the RS, together with
   the access token and the nonce, if the ace profile used is
   coap_oscore_2.  The parameter is encoded as a byte string for CBOR-
   based interactions, and as a string (Base64 encoded binary) for JSON-
   based interactions.  This parameter is registered in Section 7.2 and
   Section 7.3.

4.2.  RS-to-C: 2.01 (Created)

   Additionally to what specified in Section 4.2 of
   [I-D.ietf-ace-oscore-profile], the following applies.

   The RS generates its own Recipient Id for the OSCORE Security Context
   that it is establishing with the client.  By generating its own
   Recipient Id, the RS makes sure that it does not collide with any of
   its Recipient Identifiers.  The RS MUST ensure that id2 is different
   from the ace_client_recipientid.  The RS sends it to the Client
   together with what is described in Section 4.2 of
   [I-D.ietf-ace-oscore-profile]: the RS includes the Recipient Id in
   the 2.01 (Created) response, as a ace_server_recipientid parameter,
   as registered in Section 7.2 and Section 7.3.

   When receiving the response including the ace_server_recipientid
   parameter, the Client MUST set its own Sender Identifier to the value
   of the ace_server_recipientid and discard any ClientId present in the
   access token.  If the ace_server_recipientid parameter is not
   included in the response, the client MUST stop processing the
   response and interrupt the Ace exchange.

   Figure 10 shows an example of the response sent from the RS to the
   client, with payload in CBOR diagnostic notation without the tag and
   value abbreviations.



Palombini                Expires March 25, 2021                [Page 11]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   Header: Created (Code=2.01)
   Content-Format: "application/ace+cbor"
   Payload:
    {
      "nonce2": h'25a8991cd700ac01',
      "ace_server_recipientid" : h'22'
    }

                                 Figure 10

4.2.1.  The ace_server_recipientid Parameter

   This parameter MUST be sent from the RS to the client, together with
   the access token and nonce, if the ace profile used is coap_oscore_2.
   The parameter is encoded as a byte string for CBOR-based
   interactions, and as a string (Base64 encoded binary) for JSON-based
   interactions.  This parameter is registered in Section Section 7.2
   and Section 7.3.

4.3.  OSCORE Setup

   Differently than what defined in Section 4.3 of
   [I-D.ietf-ace-oscore-profile], the client and RS do not set the
   Sender ID and Recipient ID from the parameters received from the AS
   in Section 3.2.

   Instead, the client MUST set the Sender ID from the
   ace_server_recipientid received in Section 4.2, and the Recipient ID
   from its own generated ace_client_recipientid.  Conversely, the
   server MUST set the Sender ID from the ace_client_recipientid
   received in Section 4.1, and the Recipient ID from its own generated
   ace_server_recipientid.

5.  Security Considerations

   TODO

   TBD: How do this profile and the v1 OSCORE profile work together? can
   the AS send a v1 profile + token and the c and RS try to run a v2?
   how does c react if it tries to run v2 and get reverted to v1?  How
   do the 2 profiles work together?

6.  Privacy Considerations

   TODO






Palombini                Expires March 25, 2021                [Page 12]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


7.  IANA Considerations

   This document has the following actions for IANA.

7.1.  ACE Profile Registry

   The following registration is done for the ACE Profile Registry
   following the procedure specified in section 8.8 of
   [I-D.ietf-ace-oauth-authz]:

   o  Name: coap_oscore_2

   o  Description: Profile for using OSCORE to secure communication
      between constrained nodes using the Authentication and
      Authorization for Constrained Environments framework.

   o  CBOR Value: TBD (value between 1 and 255)

   o  Reference: [[This specification]]

7.2.  OAuth Parameters Registry

   The following registrations are done for the OAuth ParametersRegistry
   following the procedure specified in section 11.2 of [RFC6749]:

   o  Parameter name: ace_client_recipientid
   o  Parameter usage location: client request
   o  Change Controller: IESG
   o  Specification Document(s): [[This specification]]

   o  Parameter name: ace_server_recipientid
   o  Parameter usage location: token response
   o  Change Controller: IESG
   o  Specification Document(s): [[This specification]]

7.3.  OAuth Parameters CBOR Mappings Registry

   The following registrations are done for the OAuth Parameters CBOR
   Mappings Registry following the procedure specified in section 8.9 of
   [I-D.ietf-ace-oauth-authz]:

   * Name: ace_client_recipientid
   * CBOR Key: TBD (range -256 to 255)
   * Value Type: byte string
   * Reference: \[\[This specification\]\]






Palombini                Expires March 25, 2021                [Page 13]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   * Name: ace_server_recipientid
   * CBOR Key: TBD (range -256 to 255)
   * Value Type: byte string
   * Reference: \[\[This specification\]\]

7.4.  OSCORE Security Context Parameters Registry

   The following registration is done for the ACE Profile Registry
   following the procedure specified in section 9.4 of
   [I-D.ietf-ace-oscore-profile]:

   This registry will be populated by the values in Figure 8.  The
   specification column for all of these entries will be this document.

Acknowledgments

   This document was started from comments and discussion with the
   following individuals: John Mattsson, Jim Schaad, Goeran Selander.

9.  References

9.1.  Normative References

   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE) using the OAuth 2.0
              Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35
              (work in progress), June 2020.

   [I-D.ietf-ace-oscore-profile]
              Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson,
              "OSCORE profile of the Authentication and Authorization
              for Constrained Environments Framework", draft-ietf-ace-
              oscore-profile-11 (work in progress), June 2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.



Palombini                Expires March 25, 2021                [Page 14]

Internet-Draft          OSCORE Profile of ACE v2          September 2020


   [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,
              <https://www.rfc-editor.org/info/rfc8613>.

   [RFC8747]  Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
              Tschofenig, "Proof-of-Possession Key Semantics for CBOR
              Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
              2020, <https://www.rfc-editor.org/info/rfc8747>.

9.2.  Informative References

   [I-D.ietf-lake-edhoc]
              Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
              Diffie-Hellman Over COSE (EDHOC)", draft-ietf-lake-
              edhoc-01 (work in progress), August 2020.

Author's Address

   Francesca Palombini
   Ericsson AB
   Torshamnsgatan 23
   Kista  SE-16440 Stockholm
   Sweden

   Email: francesca.palombini@ericsson.com

























Palombini                Expires March 25, 2021                [Page 15]