[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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


          Identifier Negotiation for the OSCORE Profile of ACE
                draft-palombini-ace-oscore-profile-id-00

Abstract

   This document defines a mechanism to negotiate OSCORE security
   material identifiers for the OSCORE profile of ACE.

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
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.






Palombini                Expires March 25, 2021                 [Page 1]


Internet-Draft      Id Negotiation for OSCORE Profile     September 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Identifiers Negotiation . . . . . . . . . . . . . . . . . . .   4
     3.1.  C-to-AS:  . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  C-to-RS: POST to authz-info endpoint  . . . . . . . . . .   4
     3.3.  RS-to-C: 2.01 (Created) . . . . . . . . . . . . . . . . .   4
     3.4.  Not Supported . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     5.1.  OAuth Parameters Registry . . . . . . . . . . . . . . . .   5
     5.2.  OAuth Parameters CBOR Mappings Registry . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   In the OSCORE profile, the client and resource server receive the
   OSCORE Sender and Recipient Identifiers from the AS.  This has some
   limitations, especially if the OSCORE profile is used in conjuction
   with other mechamisms that also derive identifiers, in which case
   either collisions would happen, or longer identifiers need to be used
   as a result.  This document describes a way to negotiate the
   identifiers so that collisions does not happen even if other
   authentication mechanisms are used.

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.






Palombini                Expires March 25, 2021                 [Page 2]


Internet-Draft      Id Negotiation for OSCORE Profile     September 2020


2.  Background

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

   The 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.

             C                            RS                   AS
             |                            |                     |
             | ----- POST /token  ----------------------------> |
             |                            |                     |
             | <---------------------------- Access Token ----- |
             |                           + Access Information   |
             | ---- POST /authz-info ---> |                     |
             |     (access_token, N1)     |                     |
             |                            |                     |
             | <--- 2.01 Created (N2) --- |                     |
             |                            |                     |
           /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 Overview

   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 mechanism also need to be used if a different AS (not
   sinchronized with the first AS) or authentication protocol is used to



Palombini                Expires March 25, 2021                 [Page 3]


Internet-Draft      Id Negotiation for OSCORE Profile     September 2020


   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 longer identifiers to
   be used in general, which leads to larger message sizes, or
   additional processing on the RS.

   This document specifies a different mechanism to assign identifiers
   that works 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.

3.  Identifiers Negotiation

   This section details the message exchange.

3.1.  C-to-AS:

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

   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
   other Recipient Identifiers stored in memory.  The client posts it
   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 a ace_client_recipientid
   parameter, as registered in Section 5.1 and Section 5.2.

   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 and discard any
   ServerId present in the access token.

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

   The RS generates its own Recipient Id for the OSCORE Security Context
   that it is establishing with the client.  The Recipient Id MUST be
   different than the ace_client_recipientid received from the client.
   By generating its own Recipient Id, the RS makes sure that it does
   not collide with any other Recipient Identifiers stored in memory.
   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



Palombini                Expires March 25, 2021                 [Page 4]


Internet-Draft      Id Negotiation for OSCORE Profile     September 2020


   Recipient Id in the 2.01 (Created) response, as a
   ace_server_recipientid parameeter, as registered in Section 5.1 and
   Section 5.2.

   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.

3.4.  Not Supported

   If the RS does not support this specification, and the client sends
   its Recipient Id in the ace_client_recipientid, the server will not
   recognize the parameter and either respond with an error response or
   discard the parameter.

   If the RS replies with an error response or if the RS replies with a
   2.01 (Created) not including the ace_server_recipientid parameter the
   Client MUST assume the server uses the identifiers in the token and
   do the same.

   TODO: so it is possible for anybody in the middle to revert back to
   OSCORE profile, without this addition, and therefore create
   collisions without identifiers.

4.  Security Considerations

   TODO

5.  IANA Considerations

   This document has the following actions for IANA.

5.1.  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-rs request o Change Controller: IESG o Specification
   Document(s): [[This specification]]

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






Palombini                Expires March 25, 2021                 [Page 5]


Internet-Draft      Id Negotiation for OSCORE Profile     September 2020


5.2.  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\]\]

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

Acknowledgments

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

7.  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 6]


Internet-Draft      Id Negotiation for OSCORE Profile     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>.

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 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/