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

Versions: 00

ACE Working Group                                              S. Gerdes
Internet-Draft                                               O. Bergmann
Intended status: Standards Track                              C. Bormann
Expires: April 26, 2019                          Universitaet Bremen TZI
                                                        October 23, 2018


 C3DC -- Constrained Client/Cross-Domain Capable Authorization Profile
for Authentication and Authorization for Constrained Environments (ACE)
                        draft-gerdes-ace-c3dc-00

Abstract

   Resource-constrained nodes come in various sizes and shapes and often
   have constraints on code size, state memory, processing capabilities,
   user interface, power and communication bandwidth (RFC 7228).

   This document specifies a profile that describes how two autonomous
   resource-constrained devices, a client and a server, obtain the
   required keying material and authorization information to securely
   communicate with each other.  Each of the devices is coupled with a
   less-constrained device, the authorization manager, that helps with
   difficult authentication and authorization tasks.  The constrained
   devices do not need to register with authorization managers from
   other security domains.  The profile specifically targets constrained
   clients and servers.  It is designed to consider the security
   objectives of the owners on the server and the client side.

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 April 26, 2019.







Gerdes, et al.           Expires April 26, 2019                 [Page 1]


Internet-Draft                    C3DC                      October 2018


Copyright Notice

   Copyright (c) 2018 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   5
   2.  Protocol  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Details for the C3DC profile as an instance of the DTLS
           profile . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  Details for the C3DC profile as an instance of the OSCORE
           profile . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The ACE framework [I-D.ietf-ace-oauth-authz] describes how a client
   obtains authorization to access a (probably constrained [RFC7228])
   server from the server's authorization manager.  Without additional
   support, constrained clients will have difficulties to communicate
   with authorization managers from other security domains.  They need
   to be configured with the necessary keying material to securely
   communicate with the AS.  Manual configuration is not a feasible
   solution for the Internet of Things where the large number of nodes
   makes scalability a special concern.  Also, constrained devices often
   lack user interfaces and displays and have slow response times, which
   make their configuration tedious.  Therefore, the configuration of
   the client is best done using a less-constrained device that mediates
   between the constrained device and its overseeing principal, i.e.,



Gerdes, et al.           Expires April 26, 2019                 [Page 2]


Internet-Draft                    C3DC                      October 2018


   the human being that is configuring the device (such as its owner or
   user).

   In the Constrained Client Cross-Domain Authorization Profile (C3DC),
   each constrained device initially only requires a security
   association with its own authorization manager; it does not need to
   register with authorization managers from other security domains.
   The constrained device and its authorization manager belong to the
   same security domain, which makes their security association easier
   to maintain.  As the managers are less-constrained, they can perform
   more difficult authentication and authorization tasks such as storing
   large numbers of keys, using less-constrained-level protocols such as
   HTTP or TLS, processing TLS certificates, etc.  In this way, the
   authorization managers authenticate each other and validate each
   other's authorization.  They vouch for their own constrained devices'
   attributes and keying material and negotiate the details of the
   secure communication between client and server.  If the overseeing
   principals of both security domains approve of the communication, the
   managers provide the necessary keying material and authorization
   information to their respective constrained devices: The client is
   provided with a claim set from its authorization manager (CAS) that
   contains the necessary keying material, and, if necessary, the
   resources and actions it may perform on the server.  The server is
   provided with a claim set from its manager (AS) that contains the
   keying material and the client's access permissions.  The effort for
   clients and servers is thereby minimized.

   Summarizing, the role that is termed "Client" in
   [I-D.ietf-ace-oauth-authz] is split into the actual constrained
   client, "C", and its authorization manager, "CAS".  This is
   summarized in Figure 1.




















Gerdes, et al.           Expires April 26, 2019                 [Page 3]


Internet-Draft                    C3DC                      October 2018


    -------                           -------
    | RqP |                           |  RO | Principal Level
    -------                           -------
       |                                 |
   controls                          controls
       |                                 |
       V                                 V
   --------                          -------
   |  CAS |  <- AuthN and AuthZ ->   |  AS |  Less-Constrained Level
   --------                          -------
       |                                 |
   controls and supports        controls and supports
   authentication               authentication
   and authorization            and authorization
       |                                 |
       V                                 V
    -------                           -------
    |  C  |  -- requests resource --> | RS  | Constrained Level
    -------  <-- provides resource--  -------

                      Figure 1: Overall architecture

   Authorization Managers may be responsible for large numbers of
   devices.  The overseeing principals only need to configure the
   authorization manager which will then provide the respective
   authentication and authorization information to the constrained
   devices it manages.  The management of constrained devices thereby
   becomes much more comfortable.

   The benefits of the C3DC profile include:

   o  Constrained devices only require a security association with their
      own authorization manager.

   o  Constrained clients are not required to authenticate authorization
      servers from other security domains.

   o  Authentication and authorization on the client side can be
      dynamic.

   o  Both RqP's and RO's interests are considered.

   o  Constrained devices without a real-time clock that are not time-
      synchronized can be supported.







Gerdes, et al.           Expires April 26, 2019                 [Page 4]


Internet-Draft                    C3DC                      October 2018


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 assumed to be familiar with the terms and concepts
   defined in [I-D.ietf-ace-actors].

   The official pronunciation of "C3DC" rhymes with "curtsy".

2.  Protocol

   The C3DC profile comprises three parts:

   1.  transfer of authentication and, if necessary, authorization
       information between AS and RS;

   2.  transfer of authentication and, if necessary, authorization
       information between CAS and C;

   3.  establishment of a security association between C and RS.

2.1.  Overview

   Figure 2 depicts the C3DC protocol flow (messages in square brackets
   are optional):






















Gerdes, et al.           Expires April 26, 2019                 [Page 5]


Internet-Draft                    C3DC                      October 2018


    CAS                   C                    RS                   AS
     | <== DTLS chan. ==> |                    | <== DTLS chan. ==> |
     |                    | [Resource Req.-->] |                    |
     |                    |                    |                    |
     |                    | [<-- AS Info.]     |                    |
     |                    |                    |                    |
     | <-- Access Req.    |                    |                    |
     |                    |                    |                    |
     | <==== TLS/DTLS channel (CAS/AS Mutual Authn+Authz)     ====> |
     |                    |                    |                    |
     |  Token Request   ------------------------------------------> |
     |                    |                    |                    |
     | <------------------------------------------     Token Grant  |
     |                    |                    |                    |
     |  Token Transf. --> |                    |                    |
     |                    |                    |                    |
     |                    | <== DTLS chan. ==> |                    |
     |                    | Auth. Res. Req. -> |                    |


                        Figure 2: Protocol Overview

   As in the ACE framework, the client (C) may send an unauthorized
   resource request to the resource server (RS) to obtain the address of
   the authorization server (AS) that is responsible for the server.
   The client then contacts its own authorization manager (CAS) with
   which it already has a security association.  As described in
   [I-D.ietf-ace-actors], C and CAS are expected to belong to the same
   security domain.

   The requesting party (RqP), i.e., the human being that is responsible
   for C and CAS, provisions CAS with authorization information.  This
   enables CAS to decide which resource servers the client is allowed to
   communicate with, and which authorization servers are allowed to
   provide information about the RS.  If CAS has information that RqP
   approves of the communication, CAS and AS authenticate each other.
   As they are less-constrained devices, they may use less-constrained
   level protocols such as TLS to authenticate each other.  AS obtains
   from its overseeing principal, the resource owner (RO) if CAS is
   authorized to provide information (e.g., keying material) about C and
   if CAS's client is authorized to communicate with RS.

   After AS and CAS thus validated each others' authorization, AS
   generates an access token for RS.  In the response to CAS, the AS may
   also specify access information that contains the keying material
   meant for C.  The access token and access information must securely
   be provided to CAS.




Gerdes, et al.           Expires April 26, 2019                 [Page 6]


Internet-Draft                    C3DC                      October 2018


   RqP may further specify the resources and actions that C may perform
   on RS.  In this case, CAS adds this information to the access
   information.  It then securely provides the access token and access
   information to C.  Since C has a security association with CAS, it
   can authenticate the message.  Also, CAS can provide C with validity
   information that even a constrained C is able to interpret.

   As in the usual ACE framework protocol flow, the client keeps the
   access information and provides the access token to the resource
   server.  The resource server already has a security association with
   its AS and thus can validate that the token actually stems from an
   authorization server that is authorized by its overseeing principal
   RO.  The client and the server then use the obtained information to
   communicate securely.

2.2.  Details for the C3DC profile as an instance of the DTLS profile

2.3.  Details for the C3DC profile as an instance of the OSCORE profile

3.  IANA Considerations

   TBD

4.  Security Considerations

   TBD

5.  Acknowledgements

6.  References

6.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-16
              (work in progress), October 2018.

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

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



Gerdes, et al.           Expires April 26, 2019                 [Page 7]


Internet-Draft                    C3DC                      October 2018


6.2.  Informative References

   [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-07 (work in
              progress), October 2018.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <https://www.rfc-editor.org/info/rfc7228>.

Authors' Addresses

   Stefanie Gerdes
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63906
   Email: gerdes@tzi.org


   Olaf Bergmann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63904
   Email: bergmann@tzi.org


   Carsten Bormann
   Universitaet Bremen TZI
   Postfach 330440
   Bremen  D-28359
   Germany

   Phone: +49-421-218-63921
   Email: cabo@tzi.org








Gerdes, et al.           Expires April 26, 2019                 [Page 8]


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