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

Versions: 00

ACE Working Group                                               L. Seitz
Internet-Draft                                                      SICS
Intended status: Standards Track                             G. Selander
Expires: December 31, 2015                                      Ericsson
                                                              M. Vucinic
                                                      STMicroelectronics
                                                           June 29, 2015


           Authorization for Constrained RESTful Environments
                     draft-seitz-ace-core-authz-00

Abstract

   This memo defines a framework for authorization in constrained-node
   networks, i.e. networks where some devices have severe constraints on
   memory, processing, power and communication bandwidth.  The main goal
   is to offload constrained devices by providing them access control
   support from trusted parties that are less constrained.  The approach
   is based on RESTful requests to dedicated access management
   resources, supporting different authorization schemes and
   communication security paradigms.

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 http://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 December 31, 2015.

Copyright Notice

   Copyright (c) 2015 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
   (http://trustee.ietf.org/license-info) in effect on the date of



Seitz, et al.           Expires December 31, 2015               [Page 1]


Internet-Draft             CoRE Authorization                  June 2015


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Example A: Access to an Actuator  . . . . . . . . . . . .   4
     2.2.  Example B: Multiple Devices Accessing Sensor Data . . . .   5
     2.3.  The Authentication and Authorization Problem  . . . . . .   5
     2.4.  Solution Overview . . . . . . . . . . . . . . . . . . . .   6
   3.  Information Flows . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Message Sequences . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Access Management Resources . . . . . . . . . . . . . . .   9
   4.  Communication Security  . . . . . . . . . . . . . . . . . . .  11
     4.1.  AS - RS . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  AS - C  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  C - RS  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.4.  Authorization Information transfer in the DTLS Handshake   13
   5.  Authorization Request Format  . . . . . . . . . . . . . . . .  15
     5.1.  ARF Information Model . . . . . . . . . . . . . . . . . .  15
     5.2.  ARF Data Model  . . . . . . . . . . . . . . . . . . . . .  15
   6.  Authorization Information Format  . . . . . . . . . . . . . .  16
     6.1.  AIF Information Model . . . . . . . . . . . . . . . . . .  16
     6.2.  AIF Data Model  . . . . . . . . . . . . . . . . . . . . .  17
   7.  Client Information Format . . . . . . . . . . . . . . . . . .  18
     7.1.  CIF for the Push scheme . . . . . . . . . . . . . . . . .  18
     7.2.  CIF for the Client-Pull scheme  . . . . . . . . . . . . .  19
   8.  Message Processing  . . . . . . . . . . . . . . . . . . . . .  20
     8.1.  Unauthorized Access Attempt . . . . . . . . . . . . . . .  20
     8.2.  Authorization Request . . . . . . . . . . . . . . . . . .  21
     8.3.  Receiving Authorization Information . . . . . . . . . . .  22
     8.4.  Receiving Client Information  . . . . . . . . . . . . . .  23
     8.5.  Resource Request and Response . . . . . . . . . . . . . .  23
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   11. Acknowledmgents . . . . . . . . . . . . . . . . . . . . . . .  24
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  25
     12.2.  Informative References . . . . . . . . . . . . . . . . .  25
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  28




Seitz, et al.           Expires December 31, 2015               [Page 2]


Internet-Draft             CoRE Authorization                  June 2015


1.  Introduction

   Authorization is the process of deciding what an entity ought to be
   allowed to do.  Authorization management and processing access
   control policies in order to reach an authorization decision is often
   a heavyweight task, involving e.g. database lookups, credential
   verification and matching large sets of values against each other.
   Constrained devices are ill-equipped to handle this on their own,
   therefore the logical approach is to offload authorization management
   and part of the decision process to a less constrained, trusted third
   party.

   This memo describes an approach to authorization in constrained-node
   networks using dedicated resources for access management.  The
   various entities in the architecture handle authorization information
   by making RESTful requests (GET/PUT/POST/DELETE) to these resources
   and thereby establish the necessary security contexts for
   interactions between endpoints.

   The approach is based on the use cases from [I-D.ietf-ace-usecases]
   and on the architecture and problem description from
   [I-D.gerdes-ace-actors].  It introduces protocols for requesting
   authorization information from a trusted third party, encodings for
   such authorization information and protocols for transferring it to
   the affected device(s).  We assume that CoAP [RFC7252] is the
   preferred application-layer protocol and that constrained devices
   implementing these mechanisms can be as resource constrained as class
   1 according to the definitions in [RFC7228].

   An important goal in the design of this framework is to preserve end-
   to-end security in the presence of untrusted intermediate nodes in
   the communication of requests, responses and related authorization
   information.

1.1.  Terminology

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

   Certain security-related terms are to be understood in the sense
   defined in [RFC4949].  These terms include, but are not limited to,
   "authentication", "authorization", "confidentiality", "(data)
   integrity", "message authentication code", and "verify".

   RESTful terms including "resource", "representation", etc. are to be
   understood as used in HTTP [RFC7231] and CoAP [RFC7252].




Seitz, et al.           Expires December 31, 2015               [Page 3]


Internet-Draft             CoRE Authorization                  June 2015


   Terminology for constrained environments including "constrained
   device", "constrained-node network", "class 1", etc. is defined in
   [RFC7228].

   Terminology for entities in the architecture is defined in
   [I-D.gerdes-ace-actors], such as the constrained nodes Client (C) and
   Resource Server (RS), and the less constrained nodes Client
   Authorization Server (CAS) and Authorization Server (AS).

   Since this draft focuses on the problem of access control to
   resources it is for simplicity assumed that the Client Authorization
   Server functionality is not stand-alone but subsumed by either the
   Authorization Server or the Client (see section 2.2 in
   [I-D.gerdes-ace-actors]).

   We use the term "authorization token" for authorization information
   that is protected with object security.

2.  Overview

   This section contains an overview of the authentication and
   authorization problem and the solution described in this memo.  We
   begin with two generic examples.

2.1.  Example A: Access to an Actuator

   Consider an actuator, e.g. in an industrial control system.  Set in
   the terms of the architecture [I-D.gerdes-ace-actors], the actuator
   is hosted in one endpoint, acting RS, and another endpoint, acting C,
   is requesting access to the actuation resource.

   Security requirements of special importance are:

   o  RS needs to verify that the requesting Client is authorized to
      access the resource.

   o  Integrity and replay protection of request.  Assuming CoAP,
      integrity protection applies to Payload but also to other fields
      such as for example the CoAP option Uri-path.

   o  C must be able to verify the integrity of the response, and that
      the received message is the response to the previously made
      request, in order for C to verify that the actuation was
      performed.

   o  It must be possible to confidentiality protect the request and
      response, e.g. for privacy reasons.




Seitz, et al.           Expires December 31, 2015               [Page 4]


Internet-Draft             CoRE Authorization                  June 2015


2.2.  Example B: Multiple Devices Accessing Sensor Data

   Consider a constrained sensor performing measurements consumed by
   multiple devices.  Since the communication of a duty-cycled sensor
   with each consuming device would require energy expensive radio
   receptions and transmissions, it is favorable to minimize the number
   of devices that directly interact with the sensor.  Therefore the
   sensor publishes (e.g. sends notifications with) measurements to a
   message broker, which forwards the measurements to subscribing
   devices.  Access control is performed by only giving plaintext access
   to authorized subscribers.

   In the terminology of [I-D.gerdes-ace-actors] this means that the
   sensor acts RS and the subscribing devices are Clients.  In this
   case, the RS may neither be able to verify integrity nor replay of
   individual client requests, nor authorize individual clients, since
   it isn't necessarily interacting directly with any clients.  For the
   same reason the client is not able to match a publication against a
   request.  The main relevant security requirements here are:

   o  Access to plaintext publications must be restricted to authorized
      Clients.

   o  A Client needs to verify the origin of the publication, and that
      it is not a replay of an old publication.

2.3.  The Authentication and Authorization Problem

   Both examples in the previous subsections are encompassed by the
   problem statement described in [I-D.gerdes-ace-actors] but their
   security requirements are quite different.  On a high level, the
   authentication and authorization problem can be broken down into
   three sub-problems:

   1.  The policy for resource access as defined by the Resource Owner
       (RO) and managed by the Authorization Server (AS) needs to be
       translated into authorization information following an
       Authorization Information Format (AIF) that the RS can parse and
       act upon.

   2.  Similarly, the Client may need to acquire keys/credentials or
       other information from the AS to securely access the resource.
       Such client information is encoded following a Client Information
       Format (CIF).







Seitz, et al.           Expires December 31, 2015               [Page 5]


Internet-Draft             CoRE Authorization                  June 2015


   3.  In order for Client and RS to authenticate and authorize
       according to policy, the communication of the various information
       elements needs to be protected appropriately end-to-end: from AS
       to C, from AS to RS, and between C and RS.

   To access an actuator, as in example A, the authorization information
   could be an authorization decision that C is granted access to a
   certain resource, or attributes of C that RS can match against
   internal access policies.  The client information could be
   cryptographic keys which C could use to establish secure
   communication with RS.

   In the publish-subscribe scenario of example B, the authorization
   information (if present) could be cryptographic keys that must be
   used for protection of published resource representations.  The
   client information could be cryptographic keys/credentials with which
   publications of certain resource representations can be verified and
   decrypted.

   Communication security could be addressed with a session security
   based protocol such as DTLS [RFC6347], or an object security solution
   based on e.g.  COSE [I-D.schaad-cose-msg] (see Section 4).

   The other sub-problems listed in this section, AIF and CIF, are
   further detailed in Section 6 and Section 7, respectively.

2.4.  Solution Overview

   Considering the large variety of use cases, it may be difficult to
   address the authentication and authorization problem with one single
   protocol instance.  In this section we list some guiding principles
   for a solution.  The remainder of the document provides solution
   components based on the principles listed in this section.  In
   Section 8 the detailed processing steps are presented.  In Appendix A
   examples of the proposed solution are given.

   PRINCIPLE 1: Allow different order of information flows

   The information flows, including AIF, CIF, and Resource Request/
   Response (RRR) (Figure 1), may take place in different order see
   Section 3.










Seitz, et al.           Expires December 31, 2015               [Page 6]


Internet-Draft             CoRE Authorization                  June 2015


                    +---------------------------------+
                    |           Authorization         |
                    |              Server             |
                    +---------------------------------+
                         |                      |
                        CIF                    AIF
                         |                      |
                         V                      V
                    +--------+             +----------+
                    | Client |<--- RRR --->| Resource |
                    |        |             |  Server  |
                    +--------+             +----------+

                        Figure 1: Information flows

   PRINCIPLE 2: Build upon REST

   The information flows should leverage the RESTful architecture.  For
   RRR this is already assumed, but RESTful administrative resources for
   managing access to e.g. AIF and CIF need to be defined.  The support
   for REST should not preclude optimizations for particular protocols,
   for example some flows may be embedded within the DTLS handshake.

   PRINCIPLE 3: Allow security at different layers

   Leave to the application to decide about session based or object
   based security for any given information flow.

3.  Information Flows

   This section gives an overview of information flows between the
   entities in the architecture, and the use of access management
   resources.

3.1.  Message Sequences

   The information flows in scope between the nodes (constrained to
   constrained and constrained to less constrained) are described in
   [I-D.gerdes-ace-actors].  Taking [RFC2904] as a starting point, there
   are three authorization schemes, defining the message sequences for
   the flow of request, response, and authorization data:

   1.  In the Push scheme, C first obtains authorization information
       from AS and then transmits this data to RS together with its
       request, and finally RS sends its reply.  In this model RS does
       not communicate with AS directly.





Seitz, et al.           Expires December 31, 2015               [Page 7]


Internet-Draft             CoRE Authorization                  June 2015


   2.  In the Pull scheme, C sends its request to RS directly, RS then
       contacts AS in order to obtain authorization information, AS
       provides authorization information, and finally RS sends back the
       reply.  In this model C does not communicate with AS directly.

   3.  In the Agent scheme, C sends its request to AS, which evaluates
       C's access rights and, if authorized, executes the request on C's
       behalf, transmitting RS's response back to C.  In this model C
       does not communicate with RS directly.

   Depending on use case, different schemes may be more appropriate than
   others.  From a constrained-node network point of view we note the
   following:

   o  The Push and Agent scheme requires C to connect to AS.

   o  The Pull and Agent scheme requires RS to connect to AS.

   o  The Pull scheme requires RS to handle two secure connections at
      the same time (RS - AS and RS - C) in order to perform the real
      time authorization check.

   Considering processing and memory requirements of RS, the Push scheme
   is more favorable than the Pull scheme.

   The Agent scheme assumes constant connectivity with both C and RS and
   is therefore not applicable to the constrained setting.

   However, the publish-subscribe case from Section 2.2 is not covered
   by any of the schemes so this memo defines a new scheme, called
   Client-Pull.

   4. In the Client-Pull scheme, RS first provides unconditional access
      to a protected resource representation.  C obtains this protected
      resource representation and then contacts AS to obtain
      authorization information (in this case cryptographic keys) for
      access and verification of the resource representation.  In this
      model RS does not communicate with AS directly, and C does not
      communicate with RS directly.

   The Client-Pull scheme is only useful for GET access.  However, it
   offloads the RS considerably, since the RS neither receives any
   requests from clients nor performs any access control verifications.
   Furthermore it enables use cases, such as caching and publish-
   subscribe, that can not be covered by the other schemes in a
   satisfactory manner.





Seitz, et al.           Expires December 31, 2015               [Page 8]


Internet-Draft             CoRE Authorization                  June 2015


3.2.  Access Management Resources

   This section describes an approach for transferring authorization
   information between the various entities in the architecture by
   making RESTful requests to dedicated resources for access management.
   The structure or naming of such "access management resources" is left
   for a future version of this memo, and for simplicity we denote any
   such resource "/authorize".

   In this section we illustrate various message sequences for
   transferring authorization information by means of requesting access
   management resources.  We assume, as in section 3.2 of
   [I-D.gerdes-ace-dcaf-authorize], that the need for transferring
   authorization information may be triggered by a request from C to RS
   to access a resource.  Figure 2 shows C making an access request (GET
   /PUT/POST/DELETE) which cannot be granted by the RS because of
   missing authorization information.

                      C                           RS
                      |                           |
                      |    Request  /resource     |
                      | ------------------------> |
                      | <------------------------ |
                      |    Unauthorized           |
                      |                           |

                  Figure 2: Access request unauthorized.

   Starting with the Pull scheme, if the RS can access the AS, then any
   missing authorization information could be requested on the fly, see
   Figure 3.  The RS sends an authorization request in a specific
   Authorization Request Format (ARF) to the /authorize resource at the
   AS as detailed in Section 8 and receives authorization information in
   a specific Authorization Information Format (AIF) in the response.
   RS updates the stored authorization information based on the new
   information and executes the client's resource request accordingly.
   Note that C and RS need be mutually authenticated using pre-
   established credentials in this scheme.













Seitz, et al.           Expires December 31, 2015               [Page 9]


Internet-Draft             CoRE Authorization                  June 2015


        C                           RS                          AS
        |                           |                           |
        |    Request  /resource     |                           |
        | ------------------------> |                           |
        |                           |    POST /authorize ARF    |
        |                           | ------------------------> |
        |                           | <------------------------ |
        |                           |             AIF           |
        |                           |                           |
        | <------------------------ |                           |
        |    Granted                |                           |
        |                           |                           |

                           Figure 3: Pull Scheme

   In use cases where the RS does not have connectivity with AS, or if
   the RS cannot handle two secure connections at the same time, the
   Push scheme provides an alternative, see Figure 4.  C receives, in
   the negative response to its resource request, information about
   where to request the missing authorization information.  In this case
   it is C that requests the resource /authorize at the AS and receives
   both authorization information, and client information in a specific
   Client Information Format (CIF).  The latter will be used by C to
   establish communication security with RS.  Next, C pushes the
   authorization information to the /authorize resource at the RS.  RS
   updates the stored authorization information based on the new data
   and confirms the change, after which C can repeat the resource
   request to the RS with the new client information and authorization
   information in place.

        AS                          C                           RS
        |                           |                           |
        |                           |    Request  /resource     |
        |                           | ------------------------> |
        |                           | <------------------------ |
        |                           |    Unauthorized           |
        |    POST  /authorize ARF   |                           |
        | <------------------------ |                           |
        | ------------------------> |                           |
        |       AIF, CIF            |                           |
        |                           |                           |
        |                           |    POST /authorize  AIF   |
        |                           | ------------------------> |
        |                           | <------------------------ |
        |                           |    Changed                |
        |                           |                           |
        |                           |    Request  /resource     |
        |                           | ------------------------> |



Seitz, et al.           Expires December 31, 2015              [Page 10]


Internet-Draft             CoRE Authorization                  June 2015


        |                           | <------------------------ |
        |                           |    Granted                |
        |                           |                           |

                           Figure 4: Push Scheme

   Note that in case there is connectivity between RS and AS, but RS has
   not implemented the Pull scheme or cannot handle two secure
   connections at the same time, then AS could POST the authorization
   information to the /authorize resource of RS directly instead of
   using C as intermediary node.

   Also note that the authorization information needs to be integrity
   protected during the transport between AS and RS.  This is because
   the client has access to it and would otherwise be able to change its
   permissions.  How this is done is described in Section 4.

   Finally the Client-Pull scheme, which only requires C to request a
   Protected Resource Representation from the RS, and client information
   (e.g. cryptographic keys) from the AS.

        AS                          C                           RS
        |                           |                           |
        |                           |    GET  /resource         |
        |                           | ------------------------> |
        |                           | <------------------------ |
        |                           |   Protected Resource      |
        |                           |     Representation        |
        |                           |                           |
        |    POST /authorize ARF    |                           |
        | <------------------------ |                           |
        | ------------------------> |                           |
        |    CIF                    |                           |
        |                           |                           |

                       Figure 5: Client-Pull Scheme

   Note that the order of the information flows is different for the
   different authorization schemes.  The authorization scheme is defined
   at design time, so an RS would typically support one specific message
   sequence suitable for the particular application.

4.  Communication Security

   In this section we address the third sub-problem of Section 2.3, the
   authentication and communication security problem, based on the
   assumptions made in [I-D.gerdes-ace-actors]:




Seitz, et al.           Expires December 31, 2015              [Page 11]


Internet-Draft             CoRE Authorization                  June 2015


   o  AS and RS are assumed to have established security contexts (keys,
      credentials, security protocols, parameters).  How this was
      established is out of scope for this work.

   o  AS is assumed to have a policy for how C is allowed to access the
      resources of RS, including information for how to authenticate C,
      such as a shared secret key, public key or other credential.

   o  Both session based and object based security solutions shall be
      supported.

   Since CoAP is the default communication protocol, DTLS [RFC6347]  is
   the default session based security protocol.  DTLS MUST NOT be used
   with untrusted intermediary nodes.  For object security in
   constrained environments, COSE [I-D.schaad-cose-msg] is the main
   candidate.  OSCOAP [I-D.selander-ace-object-security] defines a
   profile of COSE, suitable for securing individual CoAP messages, and
   two Modes of operation:

   o  Mode:PAYL for (CoAP) Payload confidentiality, integrity and replay
      protection.

   o  Mode:COAP for additional protection of CoAP Headers (Code) and
      Options (Uri-Path, Uri-Query etc.) and for securing request-
      response pair.

4.1.  AS - RS

   The main purpose of this communication is to provide authorization
   information from AS to RS.  There are three communication patterns:

   1.  RS: POST /authorize to AS (ARF in request, AIF in response)

   2.  AS: POST /authorize to RS (AIF in request)

   3.  C: POST /authorize to AS (ARF in request, AIF in response)
       followed by C: POST /authorize to RS (AIF in request)

   Pattern 1. and 2.  SHALL be protected by DTLS or COSE Mode:COAP,
   leveraging the pre-established security context.  In pattern 3.,
   since C is an untrusted intermediary node, the authorization
   information SHALL be protected end-to-end from AS to RS with COSE
   Mode:PAYL, leveraging the pre-established credentials.

   Pattern 2. with COSE Mode:COAP includes the case of POST via an
   intermediary untrusted Forward Proxy, which in particular could be
   the Client, if the Client supports Forward Proxy functionality.




Seitz, et al.           Expires December 31, 2015              [Page 12]


Internet-Draft             CoRE Authorization                  June 2015


   In pattern 3. the use of transport layer security (DTLS) or CoAP
   message security (Mode:COAP) is optional, since Mode:PAYL protected
   authorization information is in itself a confidential, integrity and
   replay protected token.

   If the subsequent communication between C and RS is going to be
   protected by DTLS, then an OPTIONAL optimization of the message
   exchange is to replace "C: POST /authorize to RS (AIF in request)"
   with a transfer of the protected authorization in the DTLS Handshake,
   see Section 4.4.

4.2.  AS - C

   The main purpose of this communication is to provide client
   information from the AS to the C.  The communication pattern is:

   o  C: POST /authorize to AS to (ARF in request, CIF in response)

   This pattern SHALL be protected by DTLS or COSE Mode:COAP, leveraging
   out of band established credentials.

4.3.  C - RS

   This is the original resource request/response problem.  Since there
   may be no pre-established keys between C and RS, it is the purpose of
   AIF and CIF to provide information for authentication and
   communication security.  There are two communication patterns:

   1.  The Client makes a request (GET/PUT/POST/DELETE /resource) to RS
       and receives a response.

   2.  The Client makes a GET request to the RS, or a cache, or message
       broker and unconditionally receives a protected resource
       representation

   Pattern 1.  SHALL be protected by DTLS or COSE Mode:COAP, leveraging
   the established keys or credentials in authorization information and
   client information.  Pattern 2.  SHALL be protected with COSE
   Mode:PAYL.

4.4.  Authorization Information transfer in the DTLS Handshake

   In certain situations, a session security protocol like DTLS
   [RFC6347] can be used directly to send the authorization information
   to the RS and optimize the message exchange.  The authorization
   information MAY be embedded in the DTLS handshake.  In this case the
   authorization information SHOULD be transferred using the TLS
   supplemental data extension [RFC4680].



Seitz, et al.           Expires December 31, 2015              [Page 13]


Internet-Draft             CoRE Authorization                  June 2015


   Figure 6 illustrates this approach for a DTLS handshake.  The
   messages marked with * are optional depending on the type of
   handshake.

       Client                                       Resource Server
       ------                                       ---------------

       ClientHello (with extensions) ------->

                                      <-------  HelloVerifyRequest

       ClientHello (with extensions) -------->

                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                    <--------     ServerHelloDone

       SupplementalData (AIF)
       Certificate*
       ClientKeyExchange
       CertificateVerify*
       [ChangeCipherSpec]
       Finished                     -------->
                                               [ChangeCipherSpec]
                                    <--------            Finished
       Application Data             <------->    Application Data

         Figure 6: Authorization information Transfer in Handshake

   The SupplementalDataType value SHOULD be set to 16386 (authz_data).
   The Resource Server MUST verify the validity of the received
   authorization information before accepting any application data from
   the client.

   The RS MUST verify that the authorization information transmitted in
   the SupplementalData message is bound to the same key as the one the
   Client used in the handshake (see Section 6 for the subject binding
   in the AIF).  Note that this also enables AS-asserted authorization
   of the DTLS handshake.










Seitz, et al.           Expires December 31, 2015              [Page 14]


Internet-Draft             CoRE Authorization                  June 2015


5.  Authorization Request Format

   Authorization requests are represented in the Authorization Request
   Format (ARF).  They are produced either by the Client (Push, Client-
   Pull) or the RS (Pull) and consumed by the AS.  The ARF allows to
   specify requests for several actions on several resources in a single
   message.

5.1.  ARF Information Model

   The general information that needs to be contained in the ARF is the
   following:

   o  The identifier of the subject of this authorization request
      (usually the Client).

   o  The identifier of the host that provides the resources that are
      requested in this authorization request (CoAP option URI-host).
      Note that the ARF does not allow to specify more than one host.

   o  The requested resources and actions on these resources.

   The resources can be represented by the "path-absolute" part of the
   URI (In CoAP this would be the Uri-Path options).

5.2.  ARF Data Model

   For representing the ARF discussed in Section 5.1 the following steps
   are performed:

   o  The subject identifier is encoded in a map that maps the type of
      the identifier to its value.  The type could e.g. be a raw public
      key, or the key identifier of a secret key, or a X.509
      distinguished name.

   o  The host identifier is encoded as second parameter.

   o  The third parameter is array of resource-actions tuples.  The
      structure of the entries is specified as follows:

      *  Requests that affect the same resource are merged into a single
         entry that specifies the union of the permitted actions.

      *  The actions GET, POST, PUT, DELETE are represented as integer
         0, 1, 2, and 3 respectively.






Seitz, et al.           Expires December 31, 2015              [Page 15]


Internet-Draft             CoRE Authorization                  June 2015


      *  The set of numbers is converted into a single number by taking
         each number to the power of two and computing the inclusive OR
         of the binary representations of all the numbers.

      *  Each entry is an array, containing the resource identifier, and
         the number representing the actions.

   This information can then be represented in CBOR [RFC7049] or JSON
   [RFC7159] as an array of the elements listed above.  An example JSON
   representation of the ARF is given in Figure 7.

             [{"subjectKeyId":"someKeyId1"}, "rs.example.com",
              [["sensors/tempC",1], ["conf/sleepInterval", 5],
               ["conf/sleepDuration", 5]]]

        Figure 7: Example JSON representation of an access request

6.  Authorization Information Format

   Addressing the first sub-problem of Section 2.3, this section defines
   an Authorization Information Format (AIF) for encoding authorization
   information.  AIF instances are either consumed directly by an RS
   (Pull), or packaged into a COSE Mode:PAYL token and sent to the
   Client, who forwards the token to the RS (Push).

   This memo defines two different types of AIF that can be used by an
   AS:

   o  One or more access control decisions, listing one or more tuples
      of actions and resources similar to a capability list.  This is a
      simple super-set of the ARF.

   o  Group memberships for the Client.  This type of AIF is used in a
      configuration where the RS stores access control lists (ACLs)
      corresponding to a number of groups.  The RS will resolve a
      specific group to a specific set of ACLs which are then applied to
      the request.

6.1.  AIF Information Model

   The general information that needs to be contained in the AIF is the
   following:

   o  The identifier of the subject of this authorization information
      (usually the Client)






Seitz, et al.           Expires December 31, 2015              [Page 16]


Internet-Draft             CoRE Authorization                  June 2015


   o  The identifier of the host that provides the resources for which
      this authorization information applies (CoAP option URI-host).
      Note that the AIF does not allow to specify more than one host.

   If the authorization information represents one or more group
   memberships, the only other information needed is the group names.
   If the authorization information represents access control decisions,
   the affected resources and the actions are needed.

   Authorization decisions can also MAY contain local conditions, that
   can only be evaluated by the RS at access time (e.g.
   "NotBefore='09:00', NotAfter='18:00'").  This memo does not define
   the format of these local conditions, as it is expected that these
   will be application specific.  The RS MUST reject any authorization
   information that contains local conditions that it does not
   understand.

6.2.  AIF Data Model

   For representing the AIF discussed in Section 6.1 the following steps
   are performed:

   o  The subject identifier is encoded in a map that maps the type of
      the identifier to its value.  The type could e.g. be a raw public
      key, or the key identifier of a secret key, or a X.509
      distinguished name.  Section 4.3 defines how this is used to bind
      the authorization information to a specific client.

   o  The host identifier is encoded as second parameter.

   o  The third parameter is either an array of access control
      decisions, or if group memberships are asserted, a map, mapping
      the key 'grp' to the array of group names.  The structure of the
      entries in the access control decision array is the same as for
      the ARF, except that is may also contain local conditions
      represented as strings.

   o  Each entry is an array, containing the resource identifier, the
      number representing the actions, and optionally the local
      conditions.

   This information can then be represented in CBOR [RFC7049] or JSON
   [RFC7159] as an array of the elements listed above.  An example JSON
   representation of the AIF with access control decisions is given in
   Figure 8, while an example of the AIF containing group membership
   assertions is shown in Figure 9.





Seitz, et al.           Expires December 31, 2015              [Page 17]


Internet-Draft             CoRE Authorization                  June 2015


   [{"SubjectKeyId":"someKeyId2"}, "rs.example.com",
    [["actuators/doorLock", 5, "not-before:'07:00';not-after:'18:00'"]]]

     Figure 8: Example JSON representation of access control decisions

     [{"SubjectPublicKey":"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJG4m93
     ED8tPK2CpkhrrtKNx1vXDbml4Fun1628Qkl1U_aIB5zUfqPwaacznbqoMJ6vQVZ7
     4X9HpfynouLK_ujw"}, "rs.example.com",
     {"grp":["admin","user"]}]

        Figure 9: Example JSON representation of group memberships

   Note that different subject identifiers might be used in instances of
   the ARF and the AIF in the same Push scheme.  This is due to the fact
   that the credential the Client uses towards the AS may not be the
   same as the one later used towards the RS.

7.  Client Information Format

   This section addresses the second sub-problem of Section 2.3, and
   describes a format for client information.  Two types of client
   information are defined in this section:

   1.  Client Information related to the Push scheme, which encodes keys
       and related parameters, that allow the Client to communicate
       securely with the RS and prove that it is the legitimate subject
       of some authorization information.

   2.  Client Information related to the Client-Pull scheme represent
       keys and related parameters that allow the Client to access and
       verify a resource representation protected with object security.

   For the Push scheme, the CIF must be able to encode instructions to
   the Client on how secure the connection between Client and RS, and
   how to transfer the authorization information to the RS.

7.1.  CIF for the Push scheme

   The encoding of the client information in a Push scheme is an array
   with the following elements:

   1.  The type of this client information, here the string 'push'.

   2.  The method to be used for securing the transfer.  Either the
       string 'coaps' (for CoAP over DTLS) or the string 'oscoap' (for
       CoAP with object security).





Seitz, et al.           Expires December 31, 2015              [Page 18]


Internet-Draft             CoRE Authorization                  June 2015


   3.  The method of transferring the authorization information.  Either
       the string 'suppl' (for supplemental data) or the URI of the
       resource on the RS to which the authorization information should
       be transferred.

   4.  The type of key to be used for coaps of oscoap.  This can either
       be a raw public key denoted by the string 'rpk', or a pre-shared
       key denoted by the string 'psk'.

   5.  If the key type was 'psk', then the next element is the
       identifier of this key.  If the key type was 'rpk' this element
       is the raw public key of the RS.  The encoding here should follow
       the SubjectPublicKeyInfo defined in RFC 7250 [RFC7250].

   6.  If the key type was 'psk', then the next element is the pre-
       shared key that the Client should use either for DTLS or object
       security.  The encoding of this key depends on the representation
       format.  For CBOR it is raw bytes, for JSON it is Base64 encoded
       bytes.

   Figure Figure 10 shows an example representation of the CIF for a
   Push scheme, using JSON.

                  ["push", "oscoap", "/authorize", "psk",
                  "someKeyId", "Z4LXBNbOeeOJOYglBLb4pg"]

                Figure 10: CIF example for the Push scheme

7.2.  CIF for the Client-Pull scheme

   The encoding of the CIF for a Client-Pull scheme is an array with the
   following elements:

   1.  The type of this client information, here the string 'cpull'.

   2.  The public key of the RS used to sign the resource
       representation.  The encoding here should follow the
       SubjectPublicKeyInfo defined in RFC 7250 [RFC7250].

   3.  The secret key used to encrypt the resource representation.  The
       encoding of this key depends on the representation format.  For
       CBOR it is raw bytes, for JSON it is Base64 encoded bytes.

   Note that further parameters are provided in the secure object
   itself, such as e.g. algorithm identifiers and initialization
   vectors.





Seitz, et al.           Expires December 31, 2015              [Page 19]


Internet-Draft             CoRE Authorization                  June 2015


   Figure Figure 11 shows an example representation of the CIF for a
   Client-Pull scheme, using JSON.

          ["cpull", "MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEJG4m93
          ED8tPK2CpkhrrtKNx1vXDbml4Fun1628Qkl1U_aIB5zUfqPwaaczn
          bqoMJ6vQVZ74X9HpfynouLK_ujw", "eyJhbGciOiJIUzI1NiIsIm"]

             Figure 11: CIF example for the Client-Pull scheme

8.  Message Processing

   This section puts together the pieces from previous sections and
   specifies more in detail the processing steps for the authorization
   schemes defined in Section 3.

8.1.  Unauthorized Access Attempt

   All schemes can start with the Client requesting access at the RS
   without any established authorization information.  Depending on
   which authorization scheme (Push, Pull, Client Pull) the RS has
   implemented, the RS can either:

   o  Query the AS using the Pull scheme.

   o  Instruct the Client to use the Push scheme.

   o  In case the Client-Pull scheme, provide an encrypted
      representation of the resource that was requested, without
      performing any access control.

   If the RS wants the Client to use the Push scheme, the RS MUST
   respond with an error message using the response code 4.01
   (Unauthorized).  The error message MUST contain information that
   allows the Client to locate the AS responsible for the requested
   resource, and other information needed to make an Authorization
   Request.  For example:

                  4.01 Unauthorized
                  Content-Format: application/json
                  ["oscoap", "as.example.com/authorize"]

   The response payload MAY be protected, e.g. signed with the private
   key of RS, using COSE Mode:PAYL.  The response MAY include
   authentication information of AS, such as the (hash of the) public
   key of AS.  The public key of RS or AS be retrieved in different ways
   e.g.  from a Resource Directory





Seitz, et al.           Expires December 31, 2015              [Page 20]


Internet-Draft             CoRE Authorization                  June 2015


   The initial exchange described in this section may be omitted, and
   the client can start with the Authorization Request to AS as
   described in Section 8.2 if the Client has obtained information about
   the relevant AS in some other way, e.g. using a Resource Directory.

   If the RS has access to authorization information about the Client,
   but it does not apply to the requested resource, the RS MUST answer
   with an error message using the response code 4.03 (Forbidden).  If
   the RS has authorization information for the Client that applies to
   the requested resource, but that does not cover the requested action,
   the RS MUST reply with an error message using the response code 4.05
   (Method Not Allowed).

8.2.  Authorization Request

   Either the Client (Push scheme) or the RS (Pull scheme) can POST an
   request to the /authorize resource at the AS, specifying the Client's
   request(s) for authorization using the ARF defined in Section 5.

   Upon receiving a POST request to /authorize, the AS MUST perform the
   following steps:

   o  Ensure that the request was received over a secure channel (DTLS)
      or uses object security.  If object security was used the AS MUST
      perform the necessary verifications.

   o  Ensure that the requesting party is authenticated.  This is either
      the Client (as described in Section 4.2) or the RS (as described
      in Section 4.1).  For DTLS this is supposed to have happened
      during the handshake, for object security this is accomplished by
      a signature or MAC over the request, produced by the requesting
      party.

   o  Control that the requesting party is authorized to submit this
      kind of authorization request

   If the integrity verification fails, the AS MUST respond with an
   error message using the response code 4.00 (Bad Request)

   If the requesting party is not correctly authenticated, the AS MUST
   respond with an error message using the response code 4.01
   (Unauthorized).

   If the requesting party is not authorized to perform this request for
   authorization information, the AS MUST respond with an error message
   using the response code 4.03 (Forbidden).





Seitz, et al.           Expires December 31, 2015              [Page 21]


Internet-Draft             CoRE Authorization                  June 2015


   If the evaluation is successful the AS MUST respond with a 2.05
   (Content) message code.  The response can contain one of the
   following payloads:

   o  If any part of the access requested by the Client was not
      authorized, the payload MUST be empty.

   o  If all parts of the access requested by the Client were
      authorized, the payload MUST be either in AIF, CIF or both,
      depending on the authorization scheme:

   1.  If the Authorization Scheme is Pull, then the payload MUST be in
       AIF, as defined in Section 6.

   2.  If the Authorization Scheme is Client-Pull, then the payload MUST
       be in CIF as defined in Section 7.

   3.  If the Authorization Scheme is Push, then the payload MUST be an
       array containing first CIF, then AIF, as defined in Section 7 and
       Section 6 respectively.

8.3.  Receiving Authorization Information

   The RS may receive authorization information in a response to a POST
   to an Authorization Request as described in the previous section.

   As an alternative this section describes how to push this information
   to the RS.  This is done with a POST of the authorization information
   to the /authorize resource on the RS.  This request may come from the
   Client in the Pull scheme, as defined in Pattern 3 in Section 4.1.
   The request may also come from the AS directly.

   Figure 12 illustrates the successful execution of such a request.

                      C/AS                         RS
                       |                           |
                       |    POST /authorize AIF    |
                       | ------------------------> |
                       | <------------------------ |
                       |    2.01 Created           |
                       |                           |

                     Figure 12: POST AIF to /authorize

   A third OPTIONAL method is to include the authorization information
   in a DTLS handshake as supplemental data, as described in
   Section 4.4.




Seitz, et al.           Expires December 31, 2015              [Page 22]


Internet-Draft             CoRE Authorization                  June 2015


   Irrespective of how the authorization information is received by the
   AS, upon receiving it, RS MUST verify that it is valid, by doing the
   following:

   o  Check that the authorization information comes from a trusted AS

   o  Check that the host in the authorization information corresponds
      to itself

   o  Check that the authorization information is not expired or
      revoked, if the object security encapsulation allows this

   o  Verify the integrity of the authorization information

   If the validation succeeds, RS MUST store the authorization
   information and use it to determine the authorization of future
   requests.

   If the authorization information is invalid, RS MUST respond with an
   error message using the error code 4.03 (Forbidden).

8.4.  Receiving Client Information

   The Client receives client information in a response to a POST of an
   authorization request to an AS as described in Section 8.2.  The
   Client MUST make sure that it is communicating with a trusted AS.  If
   the communication is protected with COSE Mode:COAP, the Client MUST
   verify the authenticity and integrity of the client information,
   before using it.

8.5.  Resource Request and Response

   The final resource request is handled differently based on which
   authorization scheme is implemented.  In the Pull scheme this is an
   unauthorized request as described in Section 8.1.  For resources
   configured to use the Client-Pull scheme for GET access, the RS MUST
   unconditionally provide an encrypted and signed representation of the
   requested resource to any requesting Client.

   In the Push scheme the RS MUST perform the following steps:

   o  If the communication is secured with DTLS, verify that the
      handshake included client authentication.  If the communication is
      protected with Mode:COAP, verify the object security of the
      request.

   o  Verify the present authorization information to see if it has data
      that matches the Client, the requested resource, and the actions



Seitz, et al.           Expires December 31, 2015              [Page 23]


Internet-Draft             CoRE Authorization                  June 2015


      requested on that resource.  Note specifically that the binding
      between the authorization information and the Client is provided
      either by comparing with the keys used in the DTLS handshake, or
      with the keys used for object security of the request.

   o  If some matching authorization information contains local
      conditions, verify that these are fulfilled.

   If any of these verifications fail, the RS treat the request as
   specified in Section 8.1.

   If all of these verifications succeed, the RS MUST process the
   request as required by the underlying application.

   If the request was protected with Mode:COAP, the RS MUST follow the
   response protecting scheme for this mode.

9.  Security Considerations

   The entire document is about security.  Security considerations
   applicable to authentication and authorization in RESTful
   environments provided in OAuth 2.0 [RFC6749] apply to this work, as
   well as the security considerations from [I-D.gerdes-ace-actors].

10.  IANA Considerations

   This document has no actions for IANA yet.

11.  Acknowledmgents

   Some of the ideas of this document were originally described in a now
   expired Internet Draft: draft-selander-core-access-control-01.  The
   authors would also like to thank Carsten Bormann, Stefanie Gerdes and
   Olaf Bergmann for the inspiration drawn from draft-bormann-core-ace-
   aif [I-D.bormann-core-ace-aif] and [I-D.gerdes-ace-dcaf-authorize].

   This work has further drawn inspriation from [OSCAR] which presents
   another scheme for securing resource request and response using
   object security and where access key transport is performed by means
   of RESTful requests to dedicated resources.











Seitz, et al.           Expires December 31, 2015              [Page 24]


Internet-Draft             CoRE Authorization                  June 2015


12.  References

12.1.  Normative References

   [I-D.schaad-cose-msg]
              Schaad, J., "CBOR Encoded Message Syntax", draft-schaad-
              cose-msg-00 (work in progress), June 2015.

   [I-D.selander-ace-object-security]
              Selander, G., Mattsson, J., and L. Seitz, "March 9, 2015",
              draft-selander-ace-object-security-01 (work in progress),
              March 2015.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4680]  Santesson, S., "TLS Handshake Message for Supplemental
              Data", RFC 4680, October 2006.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [RFC7250]  Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
              T. Kivinen, "Using Raw Public Keys in Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7250, June 2014.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

12.2.  Informative References

   [I-D.bormann-core-ace-aif]
              Bormann, C., "An Authorization Information Format (AIF)
              for ACE", draft-bormann-core-ace-aif-02 (work in
              progress), March 2015.

   [I-D.gerdes-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-gerdes-ace-actors-05 (work in
              progress), April 2015.

   [I-D.gerdes-ace-dcaf-authorize]
              Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
              Authentication and Authorization Framework (DCAF)", draft-
              gerdes-ace-dcaf-authorize-02 (work in progress), March
              2015.



Seitz, et al.           Expires December 31, 2015              [Page 25]


Internet-Draft             CoRE Authorization                  June 2015


   [I-D.ietf-ace-usecases]
              Seitz, L., Gerdes, S., Selander, G., Mani, M., and S.
              Kumar, "ACE use cases", draft-ietf-ace-usecases-04 (work
              in progress), June 2015.

   [OSCAR]    Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A.,
              Damon, L., and R. Guizzetti, "OSCAR: Object security
              architecture for the Internet of Things", Ad Hoc Networks
              Vol. 32, September 2015.

   [RFC2904]  Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
              Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
              D. Spence, "AAA Authorization Framework", RFC 2904, August
              2000.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.

   [RFC7049]  Bormann, C. and P. Hoffman, "Concise Binary Object
              Representation (CBOR)", RFC 7049, October 2013.

   [RFC7159]  Bray, T., "The JavaScript Object Notation (JSON) Data
              Interchange Format", RFC 7159, March 2014.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228, May 2014.

   [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

Appendix A.  Examples

   The following examples show an overview the different authorization
   schemes presented in Section 3.  The notation is as follows:

                  A -> B     :  POST      {blah}   (request)
                 \__ __/       \_ _/      \__ __/  \___ ___/
                    V            V           V         V
               Communication    RESTful   Payload    Type of
               partners and     method               payload
               direction of
               communication

   Messages protected with COSE Mode:COAP are denoted by adding
   'CoseC(Key)', where 'Key' is the key used to protect the message.



Seitz, et al.           Expires December 31, 2015              [Page 26]


Internet-Draft             CoRE Authorization                  June 2015


   Payload protected with COSE Mode:PAYL is denoted by
   'CoseP(Key){payload}', where 'Key' is the key used to protect the
   payload.

   Note that we use POST to request authorization information instead of
   GET, since with the latter, the request would need to be transported
   in CoAP options (e.g. Uri-Query), and it could potentially become
   larger than the maximum CoAP packet size.  Since CoAP options can not
   be fragmented this would be extremely problematic.

   Example A (using the Push scheme)

   1.  C -> RS : GET /sensors/tempC {} (request)

   2.  RS -> C : 4.01 Unauthorized {"oscoap", "as.example.com/
       authorize"} (response)

   3.  C -> AS : POST /authorize CoseC(Key_C-AS) { [{"subjectKeyId
       ":"Key_C-AS"}, "rs.example.com", [['sensors/tempC', 1(= GET)]]] }
       (ARF)

   4.  AS -> C : 2.05 CoseC(Key_C-AS) { ["push", "oscoap", "/authorize",
       "psk", "someKeyId", "Z4LXBNbOeeOJOYglBLb4pg"], CoseP(Key_AS-RS){
       [{"SubjectKeyId":"someKeyId"}, "rs.example.com", [["sensors/
       tempC", 1(= GET)]]] } } (CIF, AIF)

   5.  C -> RS : POST /authorize CoseC(someKeyId) { CoseP(Key_AS-
       RS){[{"SubjectKeyId":"someKeyId"}, "rs.example.com", [["sensors/
       tempC", 1(= GET)]]]} } (AIF)

   6.  C -> RS : GET /sensors/tempC CoseC(someKeyId) {} (request)

   7.  RS -> C : 2.05 CoseC(someKeyId) {37.5} (response)

   Example B (using the Pull scheme)

   1.  C -> RS : POST /actuators/doorLock CoseC(someClientKey) {open}
       (request)

   2.  RS -(DTLS)-> AS : POST /authorize {
       [{"subjectKeyId":"someClientKey"}, "rs.example.com", [['actuators
       /doorLock', 2(= POST)]]] } (ARF)

   3.  AS -(DTLS)-> RS : 2.05 { [{"subjectKeyId":"someClientKey"},
       "rs.example.com", [['actuators/doorLock', 2(= POST)]]] } (AIF)

   4.  RS -> C : 2.04 (response)




Seitz, et al.           Expires December 31, 2015              [Page 27]


Internet-Draft             CoRE Authorization                  June 2015


   Example C (using the Client-Pull scheme)

   1.  C -> RS : GET /sensors/tempC {} (request)

   2.  RS -> C : 2.05 { CoseP(someKey){39.2} } (response)

   3.  C -> AS : POST /authorize CoseC(Key_C-AS) { [{"subjectKeyId
       ":"Key_C-AS"}, "rs.example.com", [['sensors/tempC', 1(= GET)]]] }
       (ARF)

   4.  AS -> C : 2.05 CoseC(Key_C-AS) { ["cpull", "RS_PublicKey",
       "someKey] } (CIF)

   The authorizon schemes defining these flows are introduced in
   Section 3, and detailed in Section 8.  The message structures for
   ARF, AIF and CIF are introduced in Section 5, Section 6, and
   Section 7.

Authors' Addresses

   Ludwig Seitz
   SICS
   Scheelevaegen 17
   Lund  223 70
   SWEDEN

   Email: ludwig@sics.se


   Goeran Selander
   Ericsson
   Faroegatan 6
   Kista  164 80
   SWEDEN

   Email: goran.selander@ericsson.com


   Malisa Vucinic
   STMicroelectronics
   850 Rue Jean Monnet
   Crolles  38920
   FRANCE

   Email: malisa.vucinic@st.com






Seitz, et al.           Expires December 31, 2015              [Page 28]


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