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

Versions: 00 01 02 03 04 05 06

ACE Working Group                                             J. Cuellar
Internet-Draft                                             P. Kasinathan
Intended status: Standards Track                              Siemens AG
Expires: January 1, 2017                                        D. Calvo
                                            Atos Research and Innovation
                                                           June 30, 2016

            Privacy-Enhanced Tokens for Authorization in ACE


   This specification defines PAT, "Privacy-Enhanced-Authorization-
   Tokens" or "Pseudonym-based Authorization Tokens", a protocol and a
   token construction procedure for client authorization in a
   constrained environment.

   The tokens can be also used to establish a Datagram Transport Layer
   Security (DTLS) channel between resource-constrained nodes.

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 January 1, 2017.

Copyright Notice

   Copyright (c) 2016 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
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Cuellar, et al.          Expires January 1, 2017                [Page 1]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   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.  Key words to Indicate Requirement Levels  . . . . . . . .   3
     1.2.  Features  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Actors and Terminology  . . . . . . . . . . . . . . . . .   5
   2.  System Overview . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Message Flow Overview . . . . . . . . . . . . . . . . . .   8
   4.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  RS<->SAM : Security-association-Setup . . . . . . . . . .   9
     4.2.  [C->RS: Resource-Request] . . . . . . . . . . . . . . . .   9
     4.3.  [RS->C : Un-Authorized-Request(SAM-ID)] . . . . . . . . .   9
     4.4.  C<->SAM : Security-Association-Setup  . . . . . . . . . .  10
     4.5.  C->SAM: Access-Request  . . . . . . . . . . . . . . . . .  11
     4.6.  C<-SAM: Ticket-Transfer . . . . . . . . . . . . . . . . .  11
       4.6.1.  Construction of CT  . . . . . . . . . . . . . . . . .  12
     4.7.  C->RS : Resource-Request  . . . . . . . . . . . . . . . .  13
     4.8.  RS->C : Resource-Response . . . . . . . . . . . . . . . .  14
   5.  Construction of derived Keys  . . . . . . . . . . . . . . . .  16
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  18
   7.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  18
   8.  Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  Copyright Statement . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1.  Introduction

   Three well-known problems in constrained environments are the
   authorization of clients to access resources on servers, the
   realization of secure communication between nodes, and the
   preservation of privacy.  The reader is referred for instance to
   [draft-ietf-ace-actors] and [KoMa2014].

   The Internet tackles certain aspects of those three problems.  It
   describes a way of constructing Token Material (Key Material) that
   can be used by clients and servers (or in some cases, more generally
   by arbitrary nodes) to create secure channels and provide
   authentication.  Moreover, the construction can be used to offer user
   consent (in the sense of privacy) and to create dynamically

Cuellar, et al.          Expires January 1, 2017                [Page 2]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   pseudonyms to enhance the unlinkability of the information, see
   Subsection "Features" below.

   This draft uses the same architecture of [draft-ietf-ace-actors],
   designed to help constrained nodes with authorization-related tasks
   via less-constrained nodes.  PAT supports an implicit authorization
   mode where no authorization information is exchanged and uses access
   tokens to implement this architecture.  A device that wants to access
   an item of interest on a constrained node first has to gain
   permission in the form of a token from the node's Authorization

   A main goal of PAT is to securely transmit authorization tokens.  A
   by-product is the setup of a Datagram Transport Layer Security (DTLS)
   [RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279]
   between two nodes.  Notice that the DTLS channel is not needed to
   securely transmit the authorization tokens, the authorization tokens
   may also be exchanged as described in [draft-ietf-ace-oauth-authz]
   which will be discussed in the future version of the ID.  In some
   cases, relevant in constrained environments, it is also not necessary
   for a secure transmission of the payload data from server to client.

1.1.  Key words to Indicate Requirement Levels

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

   In this document, the characters ">>" preceding an indented line(s)
   indicates a compliance requirement statement using the key words
   listed above.  This convention aids reviewers in quickly identifying
   or finding the explicit compliance requirements of this RFC

1.2.  Features

   o  The method allows a User, or an Authentication/Authorization
      Manager on its behalf, to authorize one (or several) client(s) to
      access resources on a server.  The client and/or the server can be
      constrained devices.  The authorization is implemented by
      distributing purpose-built Key Material (which we generically call
      "Tokens") to the server and clients.  This SHOULD be done by
      secure channels.

Cuellar, et al.          Expires January 1, 2017                [Page 3]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   o  The Client Tokens are crafted in such a way that the clients can
      construct authorization tokens that allow them to demonstrate to
      the server their authorization claims.  The message exchange
      between client and server for the presentation of the tokens MAY
      be performed via insecure channels.

   o  Further, the purpose-built Key material and tokens can be used for
      establishing a secret shared key between a client and the server,
      which can be then used to establish a DTLS communication with pre-
      shared keys.

   o  The tokens do not provide any information about any associated
      identities or identifiers of the clients nor of the server.

   In particular, the method can be used in context where unlinkability
   (privacy) is a main goal: the tokens convey only the assurance of the
   authorization claims of the clients.  This means that the payloads of
   our protocol, and in particular, the Authentication Token secrets
   used, can be constructed in such a way that they not leak information
   about the correspondence of messages to the same Client.  In other
   words: if an eavesdropper observes the messages from the different
   Clients to and from the server, the protocol does not give him
   information about which messages correspond to the same Client.  Of
   course, other information, like the IP-addresses or the contents
   themselves of the requests/responses may leak some information in
   this regard, but that is not information leaked by our protocol and
   can be treated separately.

   o  The tokens may be supported by a "proof-of-possession" (PoP)
      method.  PoP allows an authorized entity (a client) to prove to
      the verifier (here, the server), that he is indeed the intended
      authorized owner of the token and not simply the bearer of the
      token.  (Notice that the Authorization Token may be sent in the
      clear, and thus, it could be stolen by an intruder.  A PoP would
      hinder the attacker to use the token pretending to be authorized).

   o  The Key Material can be used to generate and coordinate pseudonyms
      between C and RS and potentially further parties.

   o  The user (more precisely, the Resource Owner, RO, see
      Section "Actors and Terminology" below) is able to decide (if he
      wishes: in a fine-grained way and in real-time) which client under
      which circumstances may access his data stored in RS.  This can be
      used to provide consent (in terms of privacy) from users (again,

   The PAT protocol has the following features:

Cuellar, et al.          Expires January 1, 2017                [Page 4]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   o  Simplified authentication on constrained nodes by handing the more
      sophisticated authentication over to less-constrained devices

   o  Support of secure communication between constrained devices

   o  Authorization policies of the principals of both participating
      parties are ensured

   o  Simplified authorization mechanism for cases where implicit
      authorization is sufficient

   o  Using only symmetric encryption on constrained nodes

1.3.  Actors and Terminology

   The actors and terminology are the similar to [I-D.ietf-ace-actors].
   Very briefly, for the purposes of this draft, the main actors are:

   o  Resource Server (RS): An endpoint which is a constrained device
      that hosts and represents a Resource (R).

   o  Client (C): An endpoint that attempts to access a resource on RS.

   o  Server Authorization Manager (SAM): An entity that prepares and
      endorses authentication and authorization data for a RS.

   o  Client Authorization Manager (CAM): An optional entity that
      prepares and endorses authentication and authorization data for a

   o  Resource Owner (RO): The principal that is in charge of the
      resource and controls its access permissions.  The RO is often the
      data subject of the protected resource.

   In addition to the terms defined in [I-D.ietf-ace-actors], we use
   additionally the following terms:

   o  Client Token (CT): The token which is generated by the SAM for the
      Client.  It contains a secret, which can be used to generate the
      Access-Token, plus some other data used for PoP.  Optionally CT
      may contain authorization information that represents RO's
      authorization policies for C.

   o  Access-Token (AT): The token which is generated by the Client and
      presented by him to the RS.  It contains a secret, which changes
      regularly (in a similar way to one-time passwords).  The AT
      contains all information needed by the RS to verify that it was

Cuellar, et al.          Expires January 1, 2017                [Page 5]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

      granted by SAM.  The Access-Tokens can also be interpreted as
      Authentication Tokens in this context.

   Further, C and RS may derive keys from the initial secret:

   o  VerifK: to verify that they are talking with the intended partner,
      for the Client C it is used as Proof of Possession of the
      (current) Access-Token

   o  PSK: as Pre-shared Key to establish a DTLS secure channel

   o  IntK: for Integrity protection (in message authentication codes)

   o  ConfK: for Confidentiality Protection (to be elaborated in a
      future version of the document).

2.  System Overview

   Each Resource Server (RS) has a Server Authorization Manger (SAM)
   which provides the authentication and authorization for RS.  To gain
   access to a specific resource on a Resource Server RS, a Client (C)
   requests a token from SAM, either directly or using its CAM.  In the
   following, for simplicity, we avoid Client Authorization Manager's
   (CAM) role.  After SAM receives the request from C, he decides if C
   is allowed to access the resource or not.  If so, SAM generates a
   Client-Token used for the authorization and for securing the
   communication between C and RS.

   For explicit access control, SAM adds the detailed access permissions
   to the token in a way that C (or his CAM) can interpret and RS can
   verify as authentically stemming from SAM.  Then C presents the
   Access-Token to RS, demonstrating his authorization, and C and RS can
   establish a secure channel.

3.  Protocol Overview

   In PAT protocol, the token generation is similar to how Proof of
   Possession tokens are constructed in [I-D.ietf-oauth-pop-
   architecture].  In the discussed protocol, three actors RS, C, SAM
   are involved and it may involve CAM as an intermediary for client
   authentication but CAM is not taken into consideration in the
   discussed version of PAT protocol.  Notice that in comparison to [I-
   D.ietf-oauth-pop-architecture], we propose a different method to
   construct the token for C by SAM, and we introduce methods to resist
   Denial-of-service (DoS) attacks on the resource constrained server

   In Figure 1 we show PAT protocol's interaction between RS, SAM and C.

Cuellar, et al.          Expires January 1, 2017                [Page 6]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

                  (B) Access-Request        |         |
           +-------------------------------->         |
           |                                |   SAM   |
           |  +-----------------------------+         |
           |  |   (C) Ticket-Transfer       |         |
           |  |                             +---^-----+
           |  |                                 |
           |  |                                 |
           |  |                                 |
         +----v+           PAT                  |(A) Shared-Secret
         |     |         PROTOCOL               |
         |  C  |                                |
         |     |                                |
         +-^---+                                |
           | |                                  |
           | |  (D) Resource+Request        +---v---+
           | +------------------------------+       |
           |                                |   RS  |
           +--------------------------------+       |
               (E) Resource-Response        +-------+

        Figure 1: PAT protocol

   The SAM and RS share a long term secret (A).  To determine SAM which
   in charge of a resource hosted at the RS, C MAY send an initial
   Resource-Request without valid access token to RS.  RS denies the
   request without valid access token and could possibly include the
   address of its SAM back to C as a response.  Or, instead of the
   initial Resource-Request without valid access token, C MAY look up
   the desired resource in a resource directory (see [I-D.ietf-core-
   resource-directory]) that lists the available resources.

   Once C knows SAM's address, it can send an (B) Access-Request for
   authorization to SAM (directly, or indirectly using its own CAM).  If
   the access is to be authorized, SAM generates a (C) Ticket-Transfer
   to C.  It contains Key-material for generating all necessary tokens
   and keys, and, if necessary, a representation of the permissions C
   has for the resource.

   Each time C sends RS a (D) Resource-Request, it generates and
   presents an Access-Token to RS to prove its right to access.  If the
   access-token is valid, RS sends a (E) Resource-Response to the C.
   Later with the common established secret C and RS can generate
   derived keys which is described later in the draft.

   The following section describes the message flow in more detail,
   especially how the messages, tokens are constructed and how RS and C

Cuellar, et al.          Expires January 1, 2017                [Page 7]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   can use their common knowledge to verify the authenticity of the ATs
   and to derive the shared keys VerifK, PSK, IntK, and ConfK.

3.1.  Message Flow Overview

   In Figure 2, a PAT protocol flow is depicted (messages in square
   brackets are optional).  Notice that the DTLS channel between C and
   RS is optional in comparison to [I-D.ietf-oauth-pop-architecture].
   The resource response from RS to C can be optionally secured by DTLS
   or by other native PAT methods.

        ,-.                     ,--.                          ,---.
        |C|                     |RS|                          |SAM|
        `+'                     `+-'                          `-+-'
         |                       | 1 Security-Association-Setup |
         |                       | <--------------------------->|
         |                       |                              |
         |   2 [Resource-REQ]    |                              |
         |----------------------->                              |
         |                       |                              |
         |3 [Un-Auth-REQ(SAM-ID)]|                              |
         |<-----------------------                              |
         |                       |                              |
         |            4 Security-Association-Setup              |
         |                       |                              |
         |                    5 Access-REQ                      |
         |                       |                              |
         |                  6 Ticket-Transfer                   |
         |                       |                              |
         |    7 Resource-REQ     |                              |
         |----------------------->                              |
         |                       |                              |
         |    8 Resource-RSP     |                              |
         |<-----------------------                              |
        ,+.                     ,+-.                          ,-+-.
        |C|                     |RS|                          |SAM|
        `-'                     `--'                          `---'
       Figure 2: PAT Protocol message flow

4.  Protocol Details

   As CoAP [RFC7252] is the recommended application layer protocol for
   constrained devices, the PAT protocol is designed to work with CoAP,
   wherever necessary appropriate recommendations are made for using
   CoAP parameters with the proposed protocol.

Cuellar, et al.          Expires January 1, 2017                [Page 8]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   The following notation:


   represents the message with name Msg_Name, sent from A to B.

4.1.  RS<->SAM : Security-association-Setup

   We assume that the Resource Server RS and its Authentication Manager
   SAM share a secure channel and share a long term shared secret, i.e.,
   a shared key K, which may be implemented via USB (and physical
   security) or via DTLS, etc.  We do not assume any particular concrete
   secure channel, but it must be stressed that the security of the
   protocol strongly depends on how this secure this channel is.  We can
   also assume that the CAM and SAM share a secure connection, say over
   DTLS if CAM exist as an actor.

4.2.  [C->RS: Resource-Request]

   Initially, C may not have a valid access token to access the resource
   hosted in RS.  Initially, C performs a request (could be a CoAP GET
   or POST message [RFC7252]) to RS for a resource, given by an URI.
   The Resource Request message is OPTIONAL .

   It is assumed that C does not have information about SAM but has
   information about RS and the resource R it needs to access.

   RS MUST treat any CoAP request as Unauthorized Resource Request
   message when any of two following holds:

   o  If the sender does not present a valid access token for the
      requested resource.

   o  If the sender does not present valid access token for the
      requested action on the requested resource.

4.3.  [RS->C : Un-Authorized-Request(SAM-ID)]

   Once RS receives a request from a C, it checks the following:

   o  whether C has a valid access ticket.

      *  If not, it may respond to C with an un-authorized request
         message which contains information about SAM (SAM-ID) which
         includes additional parameters such as URI and other relevant
         information to reach SAM.

Cuellar, et al.          Expires January 1, 2017                [Page 9]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

      *  If C has a valid access ticket, but it does not include
         appropriate rights to perform the requested action (i.e., C may
         have a valid access ticket to perform a GET() but not POST()),
         RS responds back with appropriate response (In CoAP, 4.05
         Method Not Allowed [RFC7252] is sent as response)

   Figure 3 shows the sequence of messages with detailed CoAP types
   between C and RS for the above Unauthorized resource request:

                      ,-.          ,--.
                      |C|          |RS|
                      `+'          `+-'
 ,--------------------.|            |
 |Code: GET(Code=1)   || 1 Res-REQ  |
 |Type: Confirmable   ||----------->|
 |Token: invalid-tkn  ||            |
 |URI-Path: test      ||            |
 `--------------------'|            |
                       |            |  ,-------------------------.
                       |            |  |Code: 4.01 Unauthorized  |
                       | 2 Res-RSP  |  |Type: Acknowledgement    |
                       |<-----------|  |Token: invalid-tkn       |
                       |            |  |content-type:            |
                       |            |  |application/cbor         |
                       |            |  |Payload:{SAM-ID,params}  |
                      ,+.          ,+-.`-------------------------'
                      |C|          |RS|
                      `-'          `--'
 Figure 3:  C<->RS Resource-Request and Unauthorized-Request as response

4.4.  C<->SAM : Security-Association-Setup

   Once C receives SAM-ID which contains the information to reach SAM, C
   or CAM (if involved) SHOULD establish a secure connection channel.

   o  The SAM may have an access control list for the clients, with that
      SAM can verify if the client is allowed to establish a secure
      connection or not.  The methods to implement access control in
      this regard are out of scope of this draft.

   o  If the client has valid access to the resource in RS, then SAM
      establishes a confidential channel with C.  This draft does not
      specify how this secure connection should be established, it could
      be a DTLS channel with pre-shared key.

   Notice that, it is important to ensure that this connection is
   reliable and secure as the remainder of this protocol lies on the
   fact that the messages exchanged between C and SAM are protected.

Cuellar, et al.          Expires January 1, 2017               [Page 10]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

4.5.  C->SAM: Access-Request

   Once C establishes a secure communication channel with SAM, C sends
   an access request message to SAM.

   The C includes the details about the resources (R) and operations it
   needs to access / perform on RS to SAM as part of the Access-Request
   Message.  This depends on the infrastructure or services the RS
   offers.  For example, if RS exposes resources such as temperature and
   humidity, a generic token may be granted by SAM to C to access both
   resources on RS.  On the other hand, the application developer or
   administrator may decide to have fine grained (different) tokens for
   temperature and humidity.

4.6.  C<-SAM: Ticket-Transfer

   When SAM receives an access-request from a C, it validates the
   access-request message.  If the access request from C is valid, SAM
   creates and sends the Client-Token CT for C through a Ticket-Transfer

   The Figure 4 shows the Access request message from C to SAM and the
   consequent Ticket Transfer as a response from SAM to C.

Cuellar, et al.          Expires January 1, 2017               [Page 11]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

                              ,-.               ,---.
                              |C|               |SAM|
                              `+'               `-+-'
                               |                  |
                               |   ========       |
   ================================= DTLS ==============================
                               |   ========       |
                               |                  |
   ,--------------------------.|                  |
   |Code:POST                 ||  1 Access-REQ    |
   |Content-Format:CBOR       ||----------------->|
   |URI-Path: authorize       ||                  |
   |Payload:{RES,Operations}  ||                  |
   `--------------------------'|                  |
                               |                  | ,------------------.
                               |2 Ticket-Transfer | |Code:Content      |
                               |<-----------------| |content-type:     |
                               |                  | |application/cbor  |
                               |                  | |Payload:{CT}      |
                               |                  | `------------------'
                               |                  |
                               |   ========       |
   ================================= DTLS ==============================
                               |   ========       |
                              ,+.               ,-+-.
                              |C|               |SAM|
                              `-'               `---'
   Figure 4: Access-Request and Ticket-Transfer

4.6.1.  Construction of CT

   This sub-section describes how SAM generates the CT for C.  SAM uses
   PoP token method to construct CT and it is constructed using HMAC
   algorithm instead of encryption as described in [I-D.ietf-oauth-pop-
   architecture].  The CT includes a Face, a Verifier and some
   additional information which isblazer described in detail below:

   A Face is constructed as the following:

   o  Face: SAI, timestamp, time-to-live, random

      *  Server Authorization Information (SAI): It contains the
         resource server URI with the allowed permissions.

      *  timestamp: It contains the timestamp information

      *  time-to-live: (or lifetime ) It is used to limit the validity
         of the access tickets [optional]

Cuellar, et al.          Expires January 1, 2017               [Page 12]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

      *  random: random seed on the token such that we make Face non-
         deterministic, this random number can be generated by any

   The Face can be optionally encoded in CBOR format.  Note that the
   time-synchronization between SAM and RS may be implemented based on
   the application requirements is out of scope of this draft.

   o  Verifier: G (K, Face) Notice that G takes two parameters (key,
      data) as input and produced a keyed digest as the output

      *  G: the HMAC algorithm which is used to create the verifier, we
         propose Poly1305 [RFC7539]

      *  K: the shared key between SAM and RS

      *  Face: it is obtained from the previous step

   o  Client-Token: Face, Verifier, Additional_Information

      *  Face: what we obtained from first step

      *  Verifier: what we obtained from previous step

      *  Additional-Information: it may contain information about
         cryptographic algorithms such as AEAD, Hash and HMAC.

   Notice that the Ticket transfer message and the verifier MUST be sent
   to C through a secure channel.  The client will use the Verifier as
   the key material to communicate with the Resource Server.

4.7.  C->RS : Resource-Request

   When C receives the ticket-transfer from SAM, C can construct a valid
   Access-Token, AT, which will demonstrate his authorization to RS that
   he may access the resources he is requesting.

   Regularly, the message Resource-Req with new AT has to be sent
   afresh: Client C has to renew his Authorization status at the
   Resource Server.  The frequency in which the Client has to send a new
   AT can be enforced by RS and is determined indirectly by the owner of
   RS (or by SAM).  This allows a fine-grained control on the service
   level that the Resource Server will provide to the Client (for
   instance, on the amount of information of sensor data).

   Each time a Resource-Req is sent, a new Access-Token MAY be needed.
   Optionally, communications between C and RS can be encrypted using a
   part of the access ticket to enforce confidentiality if necessary.

Cuellar, et al.          Expires January 1, 2017               [Page 13]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   o  For example if C performs:

      *  a CoAP GET() request, C does not have any payload therefore no
         need for encryption

      *  a CoAP POST() request with payload, C may create a authorized
         resource request message by encrypting the "payload" using an
         algorithm described in Face's Additional-Information.  We
         propose ChaCha20-Poly1305-AEAD authenticated encryption
         mechanism, while using the Verifier as the key and CoAP-MID as
         the nonce

   The Resource-Request message with valid Access-Token shall be
   constructed in one of two ways:

   Option 1:

        Request Message:{
            CoAP request: request type {GET/POST}, Message ID (MID)
            Access-Token: Face, [params]
            MSG_PAYLOAD: [optional encryption]

   Option 2:

     Request Message:{
         CoAP request: request type {GET/POST}, Message ID (MID)
         Access-Token: Face, AuthenticationHash= Hash(verifier+nonce)
         MSG_PAYLOAD: ChaCha20_Poly1305_AEAD(Verifier,nonce= MID,
                      AAD=null, payload)

   In option 2, the AuthenticationHash (AH) contains the hash of the
   verifier and a nonce, CoAP's MID may be used as the nonce.  The AH
   proves that the client is authenticated by the SAM because the
   Verifier is a MAC constructed using the shared secret between SAM and

4.8.  RS->C : Resource-Response

   When RS receives resource-request from a C of type Option 1, RS
   validates the request message from C and if the request is valid, RS
   sends a response message to C.

   If RS receives an Option 2 resource-request from C, RS checks the
   following conditions before sending a response to C:

Cuellar, et al.          Expires January 1, 2017               [Page 14]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   o  look for an Access-Token in the request message and RS validates

      *  Access-Token has valid a AutheticationHash and Face

      *  Access-Token is valid for the Resource Server

      *  Access-Token is valid for the resource (R)

      *  Access-Token has valid TimeStamp and Lifetime or time-to-live

      *  Access-Token covers the request operations

   Notice that from the request message, RS is able to generate the
   Verifier and it can validate the AuthenticationHash present in the
   Resource-Request message.

   o  The RS MUST generate the verifier by computing HMAC(K, Face)

      *  K: shared key between SAM and RS; Face is extracted from the
         Access-Token attached by the C to each request.

      *  The Face is validated by computing Hash(verifier+MID) and
         comparing it with the AuthenticationHash which is enclosed in
         the Access-Token

   If any one of the verification fails, RS responds to C with an
   Unauthorized resource request or Method not allowed respectively,
   with SAM-ID (optional).  RS will respond to the requested action only
   when all the above verifications are successful.

   If the Access-Token is valid, RS prepares a valid response.  If
   request message's payload is encrypted, RS decrypts it using
   ChaCha20_Poly1305_AEAD(key=verifier,nonce=MID,AAD=null,payload).  The
   response from RS may be encrypted so that only C with a valid key
   (the Verifier or using derived keys for subsequent messages) can
   decrypt the payload:

        Encrypted Response payload:{
            CoAP request: request type {GET/POST}, Message ID (MID)
            RSP_MSG_PAYLOAD: ChaCha20_Poly1305_AEAD (Key=Verifier,
                             nonce = MID++, AAD=null, payload)

   Notice the difference in the nonce parameter.  The MID is incremented
   to avoid using the same key for encrypting twice.

Cuellar, et al.          Expires January 1, 2017               [Page 15]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   Figure 5 shows Authorized resource request from C->RS and response
   message RS->C.

                            ,-.          ,--.
                            |C|          |RS|
                            `+'          `+-'
 ,--------------------------.|            |
 |Code: POST                ||            |
 |URI-Path: test            || 1 Res-REQ  |
 |token: Face, AuthHash     ||----------->|
 |Payload:{Enc(key=Verifier ||            |
 |nonce=MID, AAD=null,      ||            |
 |payload_data)}            ||            |
 `--------------------------'|            |
                             |            |  ,-------------------------.
                             | 2 Res-RSP  |  |Code: Content            |
                             |<-----------|  |Payload:{Enc(key=Verifier|
                             |            |  |nonce=MID++, AAD=null,   |
                             |            |  |response_data)}          |
                            ,+.          ,+-.`-------------------------'
                            |C|          |RS|
                            `-'          `--'
 Figure 5: [C<->RS] Authorized Resource Request and Response

5.  Construction of derived Keys

   Once C proves to RS that it is authorized to access a resource on RS,
   RS and C may agree to generate keys based on the initial secret m
   (Verifier), permissions available on the Face.

   The main data structure used in this document may be represented as
   table of values.  Each value is a bit string of a fixed size, which
   we denote m.  Initially we choose m = 265 bits, but it is easy to
   define extensions for other values of m.

   A Pseudo-Random Generator, commonly used to generate Stream Ciphers
   can be used as the key-derivation function G.  In particular, we
   propose to use the Pseudo-Random Generator (PRG) of ChaCha20
   [RFC7539].  In other words, we use ChaCha20 block function as G, by
   generating an arbitrarily long keystream.  The stream cipher ChaCha20
   takes as input a 256-bit key k, a 64-bit nonce v (unique per key,
   message pair), and a 64-bit counter or block number.  The ChaCha20
   output stream can therefore be accessed randomly, and any number of
   blocks can be computed in parallel.

   It is easy to construct functions for example, G: K x I -> K, and g2,
   g3, g4: K x I -> K, where K = the key space = {0,1}^265 and I

Cuellar, et al.          Expires January 1, 2017               [Page 16]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   ={0,1,2,..N} where N is an appropriate integer (a parameter of the

   The Token secrets (keys) thus can be constructed from the initial
   secret (m) using G.  Other functions g1, g2, g3, and g4 will be used
   to generate the derived keys VerifK, PSK, IntK, and ConfK.

   We assume that G, g1, g2, g3, and g4 are (or may be) all publicly
   known functions.  That is the security of the protocol SHOULD NOT
   depend on the secrecy of those functions.

   One way of using ChaCha20_block() function [RFC7539] is represented
   in Table 1 where the counter parameter of ChaCha_block() is used as I
   to generate the derived keys.

             | ChaCha_block (key=verifier, | Generated Keys |
             | nonce=CoAP-MID, counter=#)  |                |
             | Counter_0                   | VerifK         |
             | Counter_1                   | PSK            |
             | Counter_2                   | IntK           |
             | Counter_3                   | ConfK          |
             Table 1: Derived Keys

6.  References

6.1.  Normative References

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

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

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

   [RFC4279] Eronen P. and Tschofenig H., "Pre-Shared Key Ciphersuites
   for Transport Layer Security (TLS)", RFC 4279, December 2005.

   [RFC7539] Y.  Nir and A.  Langley: ChaCha20 and Poly1305 for IETF
   Protocols, RFC7539, May 2015

   [I-D.ietf-ace-actors] Gerdes, S., Seitz, L., Selander, G., and C.
   Bormann, "An architecture for authorization in constrained

Cuellar, et al.          Expires January 1, 2017               [Page 17]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   environments", draft-ietf-ace-actors-03 (work in progress), September

   [I-D.ietf-core-resource-directory] Shelby Z. and Bormann C., "CoRE
   Resource Directory", draft-ietf-core-resource-directory-07 (work in
   progress), March 2016.

   [I-D.ietf-oauth-pop-architecture] Hunt, P., Richer, J., Mills, W.,
   Mishra, P., and H.  Tschofenig, "OAuth 2.0 Proof-of-Possession (PoP)
   Security Architecture", draft-ietf-oauth-pop-architecture-07 (work in
   progress), December 2015.

   [draft-ietf-ace-oauth-authz] Seitz, L., Selander, G., Wahlstroem, E.,
   Erdtman, S., and H.  Tschofenig, "Authorization for the Internet of
   Things using OAuth 2.0", draft-ietf-ace-oauth-authz-02 (work in
   progress), December 2016.

6.2.  Informative References

   [KoMa2014] Kohnstamm, J. and Madhub, D., "Mauritius Declaration on
   the Internet of Things", 36th International Conference of Data
   Protection and Privacy Comissioners, October 2014.

7.  Acknowledgement

   This draft is the result of collaborative research in the RERUM EU
   funded project and has been partly funded by the European Commission
   (Contract No. 609094).

8.  Appendix

8.1.  Copyright Statement

   Copyright (c) 2015 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents <http://trustee.ietf.org/license-info)>.

Authors' Addresses

Cuellar, et al.          Expires January 1, 2017               [Page 18]

Internet-Draft       PAT for Authorization in ACE 03           June 2016

   Jorge Cuellar
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Germany  81739

   Email: jorge.cuellar@siemens.com

   Prabhakaran Kasinathan
   Siemens AG
   Otto-Hahn-Ring 6
   Munich, Germany  81739

   Email: prabhakaran.kasinathan@siemens.com

   Daniel Calvo
   Atos Research and Innovation
   Poligono Industrial Candina
   Santander, Spain  39011

   Email: daniel.calvo@atos.net

Cuellar, et al.          Expires January 1, 2017               [Page 19]

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