Privacy-Enhanced Tokens for Authorization in ACE
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jorge R Cuellar , Prabhakaran Kasinathan , Daniel Calvo | ||
| Last updated | 2016-06-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03
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
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-03
Abstract
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
Manager.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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,
ROs).
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
C.
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
(RS).
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:
A->B:<Msg_Name>
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
message.
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
Pseudo-Random-Generator
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
RS.
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
if:
* 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)
where,
* 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
construction)
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
2016.
[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]