Access Control Framework for Constrained Environments
draft-selander-core-access-control-00
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 | Göran Selander , Mohit Sethi , Ludwig Seitz | ||
| Last updated | 2013-07-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| 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-selander-core-access-control-00
CoRE Working Group G. Selander
Internet-Draft M. Sethi
Intended Status: Standards Track Ericsson
Expires: January 6, 2014 L. Seitz
SICS Swedish ICT
July 5, 2013
Access Control Framework for Constrained Environments
draft-selander-core-access-control-00
Abstract
The Constrained Application Protocol (CoAP) is a light-weight web
transfer protocol designed to be used in constrained nodes and
constrained networks. Communication security support for CoAP,
including authentication, encryption, integrity protection, is well
understood and a DTLS binding for CoAP is specified, but
authorization and access control are not described in detail.
This document describes a generic and dynamic access control
framework suitable for constrained environments using CoAP. The
framework builds on standards and well known paradigms for access
control, externalizing authorization decision making to unconstrained
nodes while performing authorization decision enforcement and
verification of local conditions in constrained devices.
In addition, this document provides alternative or complementary key
management to the CoAP security modes.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at
<Author> Expires January 6, 2014 [Page 1]
INTERNET DRAFT <Document Title> July 5, 2013
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2013 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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements, rationale and outline . . . . . . . . . . . . . 5
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Outline of Access Control Framework . . . . . . . . . . . . 8
3. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Resource Owner . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Authorization Server . . . . . . . . . . . . . . . . . . . 10
3.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 Resource Server . . . . . . . . . . . . . . . . . . . . . . 11
4. Assertion profiles . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Assertion requirements . . . . . . . . . . . . . . . . . . 12
4.2 Assertion wrapping . . . . . . . . . . . . . . . . . . . . 13
4.3 Assertion transport . . . . . . . . . . . . . . . . . . . . 13
5. Message protection profiles . . . . . . . . . . . . . . . . . . 14
5.1 Communication security profile . . . . . . . . . . . . . . 14
5.1.1 Assertion caching in resource server (informational) . . 15
5.2 Object security profile . . . . . . . . . . . . . . . . . . 16
5.2.1 GET . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2 PUT/POST . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3 DELETE . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.4 Assertion replay protection (informational) . . . . . . 18
<Author> Expires January 6, 2014 [Page 2]
INTERNET DRAFT <Document Title> July 5, 2013
6. Intermediary processing and notifications . . . . . . . . . . . 19
6.1 Intermediary nodes . . . . . . . . . . . . . . . . . . . . . 19
6.2 Mirror Server . . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Observe . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Trust management . . . . . . . . . . . . . . . . . . . . . . . 20
7.1 Access Control Lists . . . . . . . . . . . . . . . . . . . 21
7.2 Key provisioning schemes . . . . . . . . . . . . . . . . . 23
7.2.1 ACF PK Scheme . . . . . . . . . . . . . . . . . . . . . 23
7.2.2 ACF SSK Scheme . . . . . . . . . . . . . . . . . . . . 24
7.3 Key provisioning examples . . . . . . . . . . . . . . . . . 25
7.3.1 The authorization server as certification authority . . 26
7.3.2 The authorization server for configuration of raw
public keys . . . . . . . . . . . . . . . . . . . . . . 26
7.3.3 The assertion as an authentication token . . . . . . . . 26
7.3.4 Using the assertion to transport the nonce . . . . . . . 27
7.3.5 TLS extension for transport of nonce . . . . . . . . . . 27
8. ACF Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1 Assertion Profile: Compact SAML-XACML . . . . . . . . . . . 27
8.2 Communication Security Profile: DTLS PSK with Bind Key . . 31
8.3 Object Security Profile: JWE-protected CoAP payload . . . . 32
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
11.1 Normative References . . . . . . . . . . . . . . . . . . . 35
11.2 Informative References . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
<Author> Expires January 6, 2014 [Page 3]
INTERNET DRAFT <Document Title> July 5, 2013
1. Introduction
The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a
light-weight web transfer protocol suitable for applications in
embedded devices used in services such as smart energy, smart home,
building automation, remote patient monitoring etc. Due to the
nature of the these use cases including critical, unattended
infrastructure and the personal sphere, security and privacy are
critical components.
CoAP message exchanges can be protected with different security
protocols. The CoAP specification defines a DTLS binding for CoAP,
which provides communication security services including
authentication, encryption, integrity protection and replay
protection.
Authorization and access control - i.e. controlling who has access to
what - is addressed with access control lists, which are assumed to
have been provisioned to the devices and which contain e.g. lists of
identifiers that may start DTLS sessions with the devices.
There are some limitations with this approach:
1. By restricting the scope of access control to the granularity of
identifiers with "root" access, it is not possible to give different
privileges to different entities that are allowed to access the same
device. For example, it may be desirable to give some clients the
right to GET resources but others the right to POST or PUT resources
to the same device; or to give the same client different access
rights for different resources on the same device.
2. Furthermore, in certain use cases the granularity of
GET/PUT/POST/DELETE is not sufficient to specify the relevant access
restrictions. For example, the access policy may depend on local
conditions of the device such as: date and time, proximity, geo-
location, detected effort (press 3 times) or other aspects of the
current state of the device.
3. Another limitation is that it is neither defined how to change the
access privileges except by means of re-provisioning, nor how such
changes would be authorized.
The use of more flexible access control also enables more advanced
business settings, for example: outsourcing of operations of sensor
networks, data harvesting in leased networks, etc.
All these aspects could in principle be addressed with customized
<Author> Expires January 6, 2014 [Page 4]
INTERNET DRAFT <Document Title> July 5, 2013
access control lists, but if access control should be standardized
for CoAP, it seems more appropriate to use of existing access control
standards instead of re-inventing the wheel for a particular protocol
or use case.
This document proposes a framework that allows fine-grained and
flexible standard-compatible access control applicable to a generic
setting including use cases with constrained devices such e.g. class
1 devices [I-D.ietf-lwig-terminology].
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [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", "access control",
"confidentiality", "credential", "encryption", "sign", "signature",
"data integrity", and "verify".
Terminology for constrained environments is defined in [I-D.ietf-
lwig-terminology]. These terms include, but are not limited to,
"constrained device", "constrained network", and "device class".
2. Requirements, rationale and outline
This section gives an overview of the requirements that form the
basis for the proposed Access Control Framework, as well as the
rationale behind it, and furthermore it gives a rough outline of how
the framework is applied.
2.1 Requirements
The Access Control Framework SHALL support
- access control in a constrained environment with constrained
devices or networks, in particular,
-- no additional messages SHOULD be sent or received by a
constrained device exclusively for performing access control.
<Author> Expires January 6, 2014 [Page 5]
INTERNET DRAFT <Document Title> July 5, 2013
- access control applicable to a variety of use cases and access
purposes, in particular
-- differentiated access rights for different requesting entities,
-- access control at least at the granularity of RESTful
resources,
-- access policies based on local conditions (e.g. state of
device, time, position),
- changes to access policies without re-provisioning, and
- state-of-the-art security (in particular access control) standards
and best practices (in particular end-to-end security between
resource and authorized client).
The Access Control Framework SHALL be compatible with a large variety
of client-server authentication methods, message protection
mechanisms (communication/object security), device key management
procedures and trust anchors (secret keys, raw public keys,
certificates).
2.2 Rationale
Consider the main setting in focus where a CoAP client wants to
access a resource hosted on a CoAP server, which is potentially a
constrained device, and where the access rights should be determined
by the owner of the resource.
To comply with requirements on generic applicability, granular, and
standardized access control, we need to be able to support some
fairly general and rich access control policy language, e.g. XACML
[XACML].
Managing and evaluating XACML or similar policies is too heavyweight
for constrained devices. As a consequence we propose to externalize
the main authorization decision to a less constrained node called the
Authorization Server, acting on behalf of the resource owner.
On the other hand, access control enforcement SHOULD be performed in
a trusted environment associated to the resource and as close to the
resource as possible, in order to provide end-to-end security between
resource and authorized client.
Moreover, verifications of local conditions SHOULD be performed in
conjunction with accessing the resource for the following reasons:
<Author> Expires January 6, 2014 [Page 6]
INTERNET DRAFT <Document Title> July 5, 2013
- Transporting information about local conditions in the resource
server to an authorization server for each policy decision (or on a
regular basis) introduces delays and/or adds additional messages
exclusively for the purpose of performing access control.
- Local conditions may have changed at the time of enforcement.
We therefore target enforcement and local decisions to take place in
the constrained device hosting the resource, or in a proxy-type
device offloading a severely constrained device hosting the
resource.
We express local conditions as constraints under which an externally
granted authorization decision is valid, and which are verified at
the time and location of enforcement. For example if using XACML,
such constraints can be expressed by Obligations.
In order to convey the authorization decisions (including local
decision constraints) from the authorization server to the device
where access control is enforced we use authorization assertions,
which are digitally signed data objects containing authorization
information. Examples of authorization assertions are SAML XACML
authorization decision assertions [SAML-XACML] and OAuth 2.0 MAC
tokens [I-D.ietf-oauth-v2-http-mac].
The assertions need to be lightweight so that constrained devices can
parse and enforce authorization decisions. However, as this
framework is targeting a variety of different constrained devices,
protection mechanisms and use cases, we allow different assertion
formats just as we must support different authentication methods and
message protection mechanisms.
In order to encompass these different setups, this framework requires
the specification of accompanying "profile", the contents of which
are defined later in this document.
NOTES
1. The authorization server must be trusted by all involved parties,
in particular by the resource server (and the resource owner). We
assume that this trust relationship is manifested through trusted
keys established a priori in the resource server and the
authorization server (Section 7).
2. The existence of such a trust relationship, once introduced to
support authorization and access control, can be utilized to optimize
key establishment, authentication and message protection between the
<Author> Expires January 6, 2014 [Page 7]
INTERNET DRAFT <Document Title> July 5, 2013
client and the server. We define key provisioning schemes (section
7.2) that profiles of this framework may take advantage of.
2.3 Outline of Access Control Framework
We briefly outline the roles, the targeted access control procedure,
the default components of the Access Control Framework (ACF) and what
parts are specified by profiles.
The roles are:
- A Resource Owner specifying the policies for access to the
resources.
- An Authorization Server (AS) performing the authorization decision
based on the access control policies and provisioned with one or more
trusted keys from the Resource Server.
- A potentially constrained Resource Server (RS) hosting resources
and provisioned with one or more trusted keys from the AS.
- An Origin Client (OC) requesting authorization and access to a
resource. As there may be client intermediaries, e.g. forward
proxies, the actual CoAP client requesting the resource server may be
different from the origin client. When there are no other clients to
confuse with, we refer to the origin client simply as "the client".
+-----------+
| Resource |
| Owner |
| |
+-----------+
+--------+ +-----------+
| |--(A)-- Assertion Request ---------->| Authori- |
| | | zation |
| |<-(B)-- Assertion, Base Credentials ---| Server |
| Origin | +-----------+
| Client |
| | +-----------+
| |--(C)- Protected Request, Assertion -->| Resource |
| | | Server |
| |<-(D)- Protected Response -------------| |
+--------+ +-----------+
<Author> Expires January 6, 2014 [Page 8]
INTERNET DRAFT <Document Title> July 5, 2013
Figure 1: Roles and access control procedure
The default procedure for resource access works as follows (see
Figure 1):
The client requests (A) from the authorization server an assertion
for access to the resource.
The authorization server makes the authorization decision on behalf
of the resource owner and, if granted, responds (B) to the client
with an Assertion and optionally one or more Base Credentials to be
used for protecting the message exchange between client and resource
server. A base credential may e.g. be the public key of the resource
server, a public key certificate of the origin client, or a so-called
Bind Key (Section 7.2.2) bootstrapping the trust relation between the
authorization server and resource server. Additional information may
be conveyed between authorization server and the origin client, e.g.
which Message Protection Profile (see below) is being used in
communication with the resource server.
The client attaches the assertion to the request (C) submitted to the
resource server, where the request/response message exchange is
protected either using communication security, e.g. DTLS [RFC6347],
or using object security, e.g. using JWE and JWS [I-D.ietf-jose-json-
web-encryption][I-D.ietf-jose-json-web-signature]. There are also
hybrid cases where both communication and object security is used,
e.g. when the assertion signed by the authorization server is
additionally signed and/or encrypted by the client and sent over
DTLS.
In either case, the message protection may be based on a key
provisioning scheme (Section 7.2) using base credentials provided by
the authorization server. Alternatively, DTLS can be based on pre-
provisioned credentials as defined by the security modes in [I-
D.ietf-core-coap], or other secure provisioning schemes.
The resource server verifies the assertion using a trusted key,
evaluates potential local conditions and, if all conditions are met,
allows the requested action on the resource. Finally the resource
server responds (D) to the request. The response uses the same
protected message exchange mechanism as the request.
The Access Control Framework (ACF) as specified in this document
defines the roles (Section 3), the overall architecture and message
flow (presented in this section), the embedding of the assertion in
CoAP (Section 4.3), the extended access control lists (Section 7.1),
and key provisioning schemes between origin client and resource
server enabled by the authorization server (Section 7.2).
<Author> Expires January 6, 2014 [Page 9]
INTERNET DRAFT <Document Title> July 5, 2013
The reason for including key management in the access control
framework is because authorization and access control are intimately
linked to authentication and secure messaging: Authorization is
bound to certain entity, and secure messaging enables exclusive
access. Therefore it is in line with the trust model and a clear
gain in provisioning effort, and computational and memory performance
to use a common key management for the different security functions.
The different applications of this access control framework in the
different use cases are expressed in terms of profiles. A profile of
the access control framework consists of an Assertion Profile and a
client-server Message Protection Profile:
- An Assertion Profile specifies the assertion format including the
procedure for signing and verifying the assertion, and how trusted AS
keys are used (Section 4).
- A Message Protection Profile describes the protection of the
resource request/response, what keys are used (including base
credentials) and how (Section 5).
3. Roles
This section describes the roles of the components in the
authorization framework.
3.1 Resource Owner
The resource owner specifies the policies for access to the
resources. The access policy language or format for expressing
policy related conditions may be specified in an assertion profile if
it affects the format of the assertion or procedures related to
composing, signing, verifying or parsing the assertion.
The role of the resource owner is obviously an important one, but is
not directly involved in the access control framework specified here.
3.2 Authorization Server
The authorization server is acting on behalf of the resource owner
and has several functions:
1. Storing and using trusted keys of the resource server (trusted RS
keys). The establishment and regular re-establishment of the trusted
<Author> Expires January 6, 2014 [Page 10]
INTERNET DRAFT <Document Title> July 5, 2013
keys is out of scope.
2. Performing the authorization decision. How this is done is out of
scope.
3. Generating, signing, and issuing assertions for requesting clients
to be verified by a resource server and potentially intermediate
nodes. The details are specified in the assertion profile.
4. Communicating with clients (receiving access request, responding
with assertion, base credentials or other data). The details are
specified in the message protection profile.
NOTE
The authorization server must have knowledge about its resource
servers' supported assertion and communication security profiles.
3.3 Client
A client wishing to access a resource, requests an assertion from the
authorization server. If the request is granted it receives an
assertion, and optionally base credentials and other information, to
use when communicating with a resource server. The client requests
access to a resource from the resource server and attaches the
assertion. The origin client may need to encrypt and/or sign the
assertion before sending it to the resource server. The base
credentials may be used to protect message exchanges between client
and resource server. The procedures are described in the message
protection profile.
3.4 Resource Server
The resource server, is a potentially constrained device hosting the
resource owner's resources. It receives, processes and responds to
client requests. The resource server has an established trust
relation with an authorization server (identified with a trusted AS
identifier), manifested through one or more trusted AS keys. The
resource server verifies that an assertion received in an access
request is valid and from a trusted source involving a trusted AS
key. If the assertion depends on the client's identity, the resource
server verifies that the requesting client is the same as the entity
authorized by the assertion. The assertion verification and message
protection procedures are specified in the respective profiles.
<Author> Expires January 6, 2014 [Page 11]
INTERNET DRAFT <Document Title> July 5, 2013
4. Assertion profiles
The assertion is a secure object containing authorization information
passed from the authorization server via a client to the resource
server. The assertion is digitally signed by the authorization
server to enable data origin verification and integrity protection.
The assertion format is specified in assertion profile, an example is
given in Section 8.1.
4.1 Assertion requirements
In order to enable the resource server to enforce the authorization
decision, the assertion SHALL provide the following information:
o Which resource does the decision apply to.
o Which action (GET, PUT, POST, DELETE) does the decision apply to.
o Which client does the decision apply to, and how can this client be
authenticated (if necessary).
o Which authorization server has issued this assertion (AS
identifier). This information MAY be implicit from the signature of
the assertion.
o Under what other conditions is the assertion valid (expiration
date, conditions evaluated by the resource server at access time).
The assertion SHALL include an Assertion Identifier which is unique
for a given resource server. If the ACF SSK key provisioning scheme
(Section 7.2.2) is used, the assertion SHALL include a Nonce N which
is different for different assertions of a given resource server.
The nonce may be the assertion identifier.
The assertion MUST be signed by the authorization server such that it
can be verified by the resource server using a trusted key. An
assertion MAY be signed with a secret symmetric key, which is then
called the Assertion Key (AK). An assertion MAY be signed with a
private key in an asymmetric signature scheme, for example the
authorization server's private key (PrK_AS). The resource server, or
other nodes verifying the assertion, MUST have access to the relevant
key (AK or PK_AS) at the time of performing the verification.
The case of an asymmetric signature scheme is RECOMMENDED if, in
addition to the resource server, an intermediary node should also be
able to verify the assertion, since the intermediary would only
require to be provisioned with a public key rather than a secret key.
<Author> Expires January 6, 2014 [Page 12]
INTERNET DRAFT <Document Title> July 5, 2013
The assertion MAY be (partially) encrypted and signed by the origin
client, if so specified in the message protection profile. The
assertion identifier SHOULD NOT be encrypted. If the ACF SSK key
provisioning scheme is used, the Nonce, or Assertion Identifier if
that is used as nonce, SHALL NOT be encrypted.
When using a communication security profile, assertions MAY be cached
(Section 5.1.1) and there is no need for replay protection, assuming
the communication security protocol supports replay protection (e.g.
DTLS, IPsec). When using an object security profile, assertions
SHALL NOT be cached and assertion replay protection SHALL be applied
(Section 5.2.4).
4.2 Assertion wrapping
Since assertions are to be consumed by constrained devices, the
protection of the assertion must be lightweight and compact. For
example XML-Signature [XMLDSig] is not considered to fulfill this
requirement. This specification RECOMMENDS the use of JSON Web
Signatures (JWS) [I-D.ietf-jose-json-web-signature] as a means of
signing assertions. It is furthermore RECOMMENDED to use the JWS
Compact Serialization in order to further reduce the size of the
signed assertion object.
4.3 Assertion transport
The assertion needs to be delivered to the Resource Server in some
way. There are several possible methods to achieve this:
1. One alternative is to transmit the assertion in CoAP as a URI
query value. When using this option it is RECOMMENDED to use the key
"authz". A limitation with this approach is that the URI query
option in CoAP is defined as Unsafe-to-Forward, meaning that a
potential forward proxy that does not understand the authorization
query would not forward such a request.
2. Another alternative is to transport the assertion using a
dedicated CoAP option. Such an option SHOULD use an option number in
the "Specification Required" range of 256..2047. The option SHOULD
be defined as Critical, and Safe-to-Forward. It SHOULD NOT be used
as cache-key and it SHOULD NOT be repeated. The content format
SHOULD be string and the Length between 1-1023 bytes. A Default
value SHOULD NOT be specified.
3. A third alternative, if DTLS is used for communication security,
is a DTLS adaptation of the TLS Authorization Extensions [RFC5878].
<Author> Expires January 6, 2014 [Page 13]
INTERNET DRAFT <Document Title> July 5, 2013
This provides an alternative to the TLS extension defined in Section
8.2.
5. Message protection profiles
The message protection between origin client and resource server is
specified in a profile. The request/response messages may be
protected with communication security (e.g. DTLS, IPsec) or with
object security (e.g. JWE, JWS). The message protection profile
SHALL specify:
o Which security protocol is used for authentication and secure
messaging between origin client and resource server.
o Which cipher suites are used, and how cipher suite negotiations of
the security protocol are used.
o Whether the assertion is encrypted and/or signed by the client.
o Which keys are used and how they are obtained a) in the origin
client (including the use of base credentials) and b) in the resource
server.
o Which CoAP security mode is assumed (if any, [I-D.ietf-core-coap])
and what ACF key provisioning scheme (if any, section 7.2).
o How to handle intermediary nodes (Section 6).
o Processing in origin client, resource server and intermediary nodes
at sending and receiving messages.
A resource server SHALL support one and only one message protection
profile, either a communication security profile or an object
security profile. How the authorization server gets information
about the message protection profile supported by the resource server
is not in scope.
5.1 Communication security profile
A communication security profile defines the detailed security
protocol used between client and resource server in the case when
there are two security protocol phases: One security establishment
phase performing authentication and key establishment (such as DTLS
handshake protocol or IKE) and one secure messaging phase (such as
DTLS record protocol or IPsec) wherein CoAP messages are sent.
<Author> Expires January 6, 2014 [Page 14]
INTERNET DRAFT <Document Title> July 5, 2013
Communication security protocols like DTLS and IPsec provides
protection to the entire application layer protocol message including
headers, assertion and payload.
The "detailed security protocol" in the communication security
profile may also include object security components, as is
illustrated in the examples below.
Example 1: The assertion is a secure object in itself, being signed
by the authorization server, but it may be necessary to also prove
the intent of the authorized client to perform the request it is
authorized with. This may be achieved by an authentication protocol
authenticating a client as described in the assertion. Alternatively
it may be addressed with a client signature on the assertion.
Example 2: The content of the assertion may require confidentiality
protection between client and server e.g. for privacy reasons. This
may be achieved by an end-to-end communication security protocol (see
below) which encrypts the messages. Alternatively it may be addressed
with encryption by the client of the assertion.
We distinguish between the end-to-end communication security setting
where the communication security protocol runs between origin client
and resource server, and the hop-by-hop security setting where there
are intermediary nodes (Section 6.1).
In the end-to-end security setting, the resource server authenticates
the origin client. The resource server SHALL verify that the subject
authorized with the assertion coincides with the authenticated
client.
In the end-to-end security setting the client signature on the
assertion MAY be omitted (compare DTLS hop-by-hop, Section 6.1). If
communication security is established using public keys, the public
key of the client MAY be replaced with a public key identifier in the
assertion.
5.1.1 Assertion caching in resource server (informational)
There may be cases of repeated access requests from one client where
a single assertion could provide authorization of all requests, e.g.
requests within the life time of the assertion. To avoid repeatedly
sending the same assertion in each request, assertions could be
cached.
<Author> Expires January 6, 2014 [Page 15]
INTERNET DRAFT <Document Title> July 5, 2013
Assertions may support caching/multiple use i.e. that the same
assertion is valid for multiple requests.
The same assertion may be sent multiple times within a secure
session, but if the resource server supports assertion caching this
is not recommended.
Assertion caching shall only be used with session based communication
security profiles and if supported by the resource server. The
assertion shall be deleted when the session expires.
Assertions shall be verified before caching. Not all parts of the
assertion need to be cached. If caching is done, the assertion
identifier, client identifier, local conditions, resource identifier,
and the action shall be cached. Local conditions in the assertion
shall be verified at each request or, considering Observe (Section
6.3), before each response.
After communication security has been established with a resource
server supporting caching of assertions, on reception of a request,
the following access control priority sequence shall be used:
1) If the client identifier is category A (Section 7.1), the request
is granted. In this case, further access control processing is
omitted.
2) Else if the client identifier is category B check for a cache hit.
If a matching assertion is found, verify the local conditions and
grant access if they are fulfilled.
3) Else if the request contains an assertion verify it, and if
successful, cache it. Then verify the local conditions, and if valid
then grant access.
TBD Assertion caching in proxies. TBD Response code if assertion is
cached
5.2 Object security profile
The authentication protocol for establishing the context of a secure
session, e.g. the DTLS handshake, may be a significant cost for a
constrained device. An alternative is to not have a security
establishment phase and instead send secure objects in CoAP request
and response.
The requirements on message protection profiles as listed in the
<Author> Expires January 6, 2014 [Page 16]
INTERNET DRAFT <Document Title> July 5, 2013
beginning of section 5 apply. In this case the required security
protocol is manifested through the processing and passing of the
secure objects.
The assertion is a secure object in itself which is passed in the
CoAP request. In addition to the assertion, the CoAP request and the
CoAP response may contain a secure payload object. The object
security profile defines what object format is being used, e.g. JWE
[I-D.ietf-jose-json-web-encryption].
Assertions MUST NOT be cached in case of an object security profile.
Assertion are one-time only, and the resource server SHALL maintain a
replay cache (Section 5.2.4).
Different request methods (GET/PUT/POST/DELETE) may have different
secure object formats for request and response.
5.2.1 GET
Assertions for GET requests SHOULD be signed by the client. The
client signature SHALL use the key indicated by the client identifier
in the assertion. In some cases, e.g. extremely constrained devices
and other settings where implicit authentication is feasible, the
client signature MAY be omitted. The assertion MAY be (partially)
encrypted by the client.
If the resource request is authorized, then the requested action is
performed and what would have been the unprotected CoAP response
payload SHALL be wrapped into a secure object and sent as response
payload. The GET response SHALL be integrity protected and MAY be
encrypted.
NOTE that in the case of implicit authentication (no client signature
on the assertion) the resource server does not establish the identity
of the requesting client. However, by protecting the response for
the authorized client, only the authorized client can get access to
the response. This is however an entry for DoS so should be used
only when the potential security consequences are considered
acceptable.
5.2.2 PUT/POST
In the PUT/POST request, the assertion or the payload SHALL be signed
by the client. The assertion and the payload MAY be (partially)
encrypted, e.g. for privacy reasons.
<Author> Expires January 6, 2014 [Page 17]
INTERNET DRAFT <Document Title> July 5, 2013
The object secure PUT/POST response payload MAY be signed or
encrypted by the resource server.
5.2.3 DELETE
Assertions for a DELETE request SHALL be signed by the client. The
object secure DELETE response payload MAY be signed or encrypted by
the resource server.
5.2.4 Assertion replay protection (informational)
In case an assertion is eavesdropped it may be replayed at a later
stage by an unauthorized party and cause unnecessary processing and
power consumption in the resource server. In the case of a
communication security protocol with replay protection this is not an
issue. In the case of an object security protocol, even if the
assertion may be in parts encrypted, it may nevertheless be
eavesdropped and replayed. For this purpose we recommend the use of
a Replay Cache where the latest legitimate requests are being stored,
as outlined in this section.
For each entry in the replay cache there are two values: the
Assertion Identifier and the associated assertion expiration date.
The replay cache is being managed in the following way during
reception of object secured requests. When a request is received:
1. The expiration date of the assertion is checked.
2. The identifier of the assertion is matched against the replay
cache.
If any of these verifications fail, the request is immediately
silently dropped to avoid unnecessary processing. The resource
server may also increase a counter that an invalid request was
received, such a counter may be used as input for a decision to e.g.
stop receiving or go to sleep a randomized time interval.
If the verifications are successful then the signature of the
assertion is verified. If that is also successful, then the a new
entry is added to the replay cache. Before a new entry is being
added, the cache is cleaned from entries associated to expired
assertions. If the cleaned replay cache is full, the new entry
pushes out the entry with shortest remaining lifetime, and if several
of equal remaining lifetimes, the oldest of these is pushed out.
The size of the replay cache and assertion lifetimes should be tuned
so that the replay cache can contain all entries corresponding to
<Author> Expires January 6, 2014 [Page 18]
INTERNET DRAFT <Document Title> July 5, 2013
valid assertions. The importance of this recommendation depends on
the impact of processing invalid requests.
6. Intermediary processing and notifications
This section describes the security implications of intermediary
processing and notifications for access control.
6.1 Intermediary nodes
There may be intermediary nodes between origin client and resource
server, including forward proxies, reverse proxies, cross-proxies,
gateways, etc. From an access control point of view the resource
server SHOULD be able to verify that a received CoAP request is
originating from the origin client referenced in the received
assertion. This has implications on the assertion and message
protection profiles.
We distinguish between the end-to-end security setting where no
intermediary nodes need be trusted and the hop-by-hop security
setting where at least one intermediary node must be trusted. Note
that an object security profile may provide end-to-end security
independently of proxies, but would not allow any inspection or
modification of the payload.
DTLS generally needs to be hop-by-hop in case of proxies, this
requires some degree of trust in a proxy which may not be acceptable
for some applications. A resource server sending back the response
via the forward proxy trusts the forward proxy with the plain text
response (e.g. a GET response) and that the proxy has established
secure communication with the origin client.
In the hop-by-hop setting, neither DTLS nor CoAP offers any means for
resource server to authenticate the origin client.
If the resource server has established DTLS with a forward proxy
which proxies requests from an origin client, then the assertion MUST
be signed by the origin client in addition to the authorization
server signature. The resource server can not authenticate the
origin client directly, but it can infer from a correctly signed
valid and fresh assertion that the origin client is authorized and
has an intent to perform the request.
Using the authorization server as a trusted party it is possible to
define a message protection profile which also provides base
<Author> Expires January 6, 2014 [Page 19]
INTERNET DRAFT <Document Title> July 5, 2013
credentials for proxies or for clients use of proxies, which support
DTLS establishment between origin client and a proxy (Section 7.3.1).
6.2 Mirror Server
The access control framework can also be applied to the scenario
where a mirror server as defined in [I-D.vial-core-mirror-proxy] is
present. In such a scenario, the resource servers behave as the
clients of the mirror server. The access control enforcement in this
case, would be made at the mirror server instead of in a constrained
resource server, and the trusted AS keys would have to be provisioned
to the mirror server. However, to a client wishing to access a
resource, the mirror server behaves as any other resource server and
is indistinguishable (transparent), thereby requiring no change for
the communication between client and the mirror server. The
communication between the mirror server and the constrained resource
server may or may not be secured, and is oblivious to the ACF
profiles used between the client and the mirror server.
6.3 Observe
The access control framework can also be applied, as it is, in the
case where the CoAP observe option [I-D.ietf-core-observe] is used.
With the observe option, the clients can register an interest in a
particular resource by sending a CoAP request containing the observe
option to a resource server. The resource server would in this case
maintain the state information for this expressed interest and send
responses on state changes only as long as the assertion and local
conditions presented in the original interest request are valid. The
local conditions may need to be verified at each state change. Once
the assertion expires, the resource server will remove any state
information for the interest expressed. The client would then have
to send a new CoAP request with an observe option expressing interest
and a new assertion for demonstrating that it is allowed access.
7. Trust management
The access control framework specified here involves at least three
entities, and thus a number of different trust relations are
possible. The framework does not make any assumptions on the a
priori trust relationship between origin client and resource server
(if any). The access control framework requires however an a priori
trust establishment between resource server and authorization server
manifested, in particular, in one or more trusted AS keys stored in
<Author> Expires January 6, 2014 [Page 20]
INTERNET DRAFT <Document Title> July 5, 2013
the resource server. How these keys are established is out of scope,
but we define different categories of keys in Section 7.1.
The primary purpose for the AS keys is to enable the resource server
to verify that an assertion received in a request from a client was
issued by the authorization server and has not been modified. Data
origin authentication and integrity verification is performed by
verifying a digital signature of the assertion. This digital
signature may either be a private key signature generated with the
private key of the authorization server (PrK_AS), or a Message
Authentication Code (MAC) calculated with a secret symmetric
Assertion Key (AK) unique for this resource server and assertion. In
the case of a private key signature, the resource server must have
access to the public key of the authorization server (PK_AS) at the
time of verifying the assertion. In the case of a MAC, the resource
server must have access to AK at the time of verifying the assertion.
Two key provisioning schemes are defined in this section.
The trusted AS keys may also be utilized for other purposes than to
support assertion verification. By means of authentication and
authorization of a client, the authorization server may invoke a
trust relation between the resource server and the client. This is
the main purpose of the key provisioning schemes detailed later in
this section. For example, the AS may create a certificate of a
public key of the client which can be verified with an AS key. As
another example, the AS may create a secret Bind Key for the origin
client which the resource server can derive from a nonce and an AS
key (Section 7.2.2). The public key or the bind key of the client
can subsequently be used by the resource server e.g. for
authentication of and secure messaging with a hitherto unknown
client. The latter is detailed in the message protection profiles.
7.1 Access Control Lists
Considering that different deployments may have very different access
control requirements we want to keep the simple access control scheme
indicated in [I-D.ietf-core-coap], and allow a gradual extension to
comply with more advanced access control settings.
The use of an access control lists in the resource server containing
identities of exchanged public keys, or pre-shared keys, of clients
[I-D.ietf-core-coap] provides an easily described criterion for
determining if a requesting client is allowed to establish secure
communications: Clients that can be authenticated as one in the list
are allowed. In the absence of any other access control,
authenticated clients are also implicitly authorized to access any
resource ("all-or-nothing" access control).
<Author> Expires January 6, 2014 [Page 21]
INTERNET DRAFT <Document Title> July 5, 2013
Similarly with a list of root trust anchors in security mode
Certificate [I-D.ietf-core-coap]: Clients that can be authenticated
using a public key certificate signed by a trust root from the list,
are allowed to establish secure communication (and potentially to
become implicitly authorized). In this case the list contains
identities of trust roots which are trusted with issuing certificates
to authorized clients.
We propose to maintain backward compatibility with these access
control lists but at the same time enable a distinction between
authentication/secure communication and authorization. There SHALL
be two categories of client keys/identities in the access control
lists of resource servers:
o Category A: identities or keys of clients which are allowed to set
up secure communication to a resource server, and to access all
resources.
o Category B: identities or keys of clients which are allowed to set
up secure communication, but access to a resource requires an
appropriate valid assertion.
Requests from clients in category A requires no assertion and can
bypass the access control.
Clients that have been authorized access to a resource by an
authorization server should obviously have the right to set up secure
communication to this resource server, and thus are in category B.
Hence the authorization server constitutes a trust root for clients
of category B. The root trust anchor is in this case a trusted AS
key.
Summarizing, there are four kinds of access control lists: Category
A, its trust anchors, Category B, and its trust anchors. Not all
lists need to be populated. Implementations complying with the
security mode RawPublicKey [I-D.ietf-core-coap] define access control
lists of category A. For implementations complying with the present
specification category B trust anchors are necessary. In Section 7.3
we show examples that the latter access control list may also be
sufficient.
One example of a member of the category B access control list is a
pre-provisioned, semi-trusted forward proxy which is allowed to set
up secure communication with a resource server, but without gaining
access to any resource.
NOTES
<Author> Expires January 6, 2014 [Page 22]
INTERNET DRAFT <Document Title> July 5, 2013
1. While the trusted AS key is a category B trust anchor, the
property of trusted AS keys relate to verification of assertions, and
not all category B trust anchors are necessarily used for verifying
assertions.
2. For object security the trusted AS keys are sufficient for
determining access rights as there is no need to set up secure
communication first. There is no access without assertion in the
object security setting - corresponding to category A of the
communication security setting. The reason for excluding this option
is that in the object security setting there is always at least one
object to be verified by the resource server and there is no
generality lost in assuming that this object is the assertion.
TBD - change of access control lists: Can the ACL in itself be a
resource that can be accessed like any other and whose changes can be
authorized with the methods proposed here?
7.2 Key provisioning schemes
There are two basic key provisioning schemes defined in this access
control framework: the ACF PK scheme built on public keys exchanged
between RS and AS, and the ACF SSK scheme built on a shared secret
key between RS and AS. The key provisioning schemes define which
keys are assumed to be provisioned to what nodes, and how these keys
can be used for deriving and/or provisioning of other keys.
The key provisioning schemes apply both to communication security and
object security. The assertion is by definition a secure object.
The key management is more complex for communication security than
object security and assertions, since the former involves key
management both for communication security and for secure objects.
Note that these key provisioning schemes are complementing the
Security Modes defined in the DTLS binding of CoAP [I-D.ietf-core-
coap] and may replace the need for provisioning keys between resource
server and a client. See examples of Section 7.3.
7.2.1 ACF PK Scheme
The ACF PK scheme assumes that the public key of the resource server,
PK_RS, is provisioned to the authorization server and vice-versa; the
public key of the assertion server PK_AS is provisioned to the
resource server. The trusted AS key is in this case PK_AS. With
this scheme the assertion is signed by the authorization server with
its private key PrK_AS and verified by the resource server using
PK_AS.
<Author> Expires January 6, 2014 [Page 23]
INTERNET DRAFT <Document Title> July 5, 2013
The content of the assertion provides a secure information channel
from the authorization server to the resource server, and may be used
as a means for provisioning. For example, the public key of the
origin client, PK_OC transported within the signed assertion to the
resource server is integrity protected.
When an origin client requests an assertion for access to a resource,
the public key of this resource server can be attached in the
response as one of the base credentials, as a means to provision
PK_RS to this origin client.
As an alternative to provisioning PK_OC to the resource server in an
assertion, the authorization server may issue a public key
certificate for PK_OC as a base credential together with the response
carrying the assertion. This certificate may then be used by the
origin client in a certificate based authentication protocol with the
resource server. PK_AS is in this case a category A or category B
trust anchor. A similar provisioning scheme is also applicable to
trust establishment with a forward proxy, see Section 7.3.1.
7.2.2 ACF SSK Scheme
The ACF SSK scheme assumes that there is a 128 bit shared secret key
SSK between resource server and authorization server, and specifies
how to derive the assertion key AK and the Bind Key BK from SSK. The
trusted AS key is in this case SSK. The assertion is signed by the
authorization server with AK and verified by the resource server with
AK.
We assume that the shared secret key SSK is pseudo-random, i.e. not
biased. It may for example be the result of a randomness extraction
step from an initial key material IKM as defined in [RFC5869].
AK and BK is derived from SSK by the authorization server and
resource server through a data expansion step as defined in
[RFC5246]:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...
where '+' indicates concatenation and A() is defined as:
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
<Author> Expires January 6, 2014 [Page 24]
INTERNET DRAFT <Document Title> July 5, 2013
In the present case:
o hash is SHA-256,
o 'secret' is SSK - the shared secret, and
o 'seed' is the nonce, N.
The nonce N associated to the resource access request is defined by
the authorization server. A Nonce SHALL NOT be reused with the same
SSK. Since the nonce is required for key derivation, it must be
available when they key is needed by the resource server.
With one iteration of the P_SHA256, the output data of 256 bits is
defined to be the concatenation of the two 128 bit keys AK and BK,
where AK is the Assertion Key and BK is the Bind Key:
AK + BK = P_SHA256(SSK, N)
How the assertion key and the bind key is used in protecting the
assertion and client-server communication, respectively, is defined
in an ACF profile.
7.3 Key provisioning examples
The CoAP security modes makes assumptions on what keys are
provisioned in the resource server.
o In security mode PreSharedKey there is a list of keys corresponding
to trusted nodes. With the terminology in Section 7.1, these clients
may be of category A or B.
o In security mode RawPublicKey there is a list of identities of
trusted nodes, these clients may be of category A or B.
o In security mode Certificate there is a list of trust anchors,
these trust anchors may be of category A or B.
This access control framework requires the provisioning of a trusted
AS key. In either of the cases above, the additional effort of
provisioning a trusted AS key, which in particular is a category B
trust anchor, is negligible.
This section takes the opposite standpoint: assuming the use of this
access control framework with the authorization server functionality
and trusted AS key provisioned to the resource server, what other
keys (if any) need to be pre-provisioned to the resource server and
what keys can be communicated during the access request procedure?
<Author> Expires January 6, 2014 [Page 25]
INTERNET DRAFT <Document Title> July 5, 2013
Phrased differently: To what extent could this access control
framework remove the need for, or simplify, the provisioning of keys?
7.3.1 The authorization server as certification authority
Given that the trusted AS key may be used as a category A/B trust
anchor, the authorization server may issue public key certificates to
origin clients that are verified in the resource server. This
removes the need to pre-provision client public keys to the resource
server.
The origin client may also use certificates signed by the
authorization server to set up DTLS with an intermediary node such as
a forward proxy. This would require the proxy to be provisioned with
PK_AS, which however is a natural assumption: A forward proxy may
also perform firewall functionality on behalf of the resource server;
to verify some properties of the assertions and drop requests with
e.g. expired assertions, assertions with invalid signatures, etc.
Alternatively, the TLS Authorization Extensions [RFC5878] may be used
with the assertion replacing the need for a certificate.
7.3.2 The authorization server for configuration of raw public keys
Since the origin client has a secure channel to the authorization
server which is a trusted party, the origin client can obtain trusted
information directly from the authorization server. The public key
of the resource server can e.g. be provided as a base credential,
removing the need to pre-provision resource server public key to the
origin client.
7.3.3 The assertion as an authentication token
There are two aspects of authentication tokens considered here.
1. The assertion may contain the public key of the client thereby
carrying authentication information about the client.
2. The assertion may be signed by the client thereby constitute a
verifiable token for authentication of the client.
Given that the assertion contains the public key of the client, the
resource server may use the assertion to establish DTLS in security
mode RawPublicKey with the client, removing the need to pre-provision
client public keys to the resource server or to pre-provision or use
client public key certificates.
<Author> Expires January 6, 2014 [Page 26]
INTERNET DRAFT <Document Title> July 5, 2013
The use of an origin client signature of the assertion provides an
additional means for authenticating the client, removing the need for
a separate secure payload object, or providing authentication
information over multiple hops.
7.3.4 Using the assertion to transport the nonce
The assertion provides transport of the nonce to the origin client
and resource server.
In the ACF SSK scheme, with object security, the transportation of
nonce in the assertion enables the resource server to derive of the
bind key, which removes the need to pre-provision shared secret keys
between origin client and resource server.
7.3.5 TLS extension for transport of nonce
The authentication protocol may provide transport of the nonce
between origin client and resource server.
In the ACF SSK scheme, with DTLS, the transportation of a nonce in a
dedicated TLS extension (Section 8.2) enables the resource server to
derive the bind key, which removes the need to pre-provision shared
secret keys between origin client and resource server.
8. ACF Profiles
8.1 Assertion Profile: Compact SAML-XACML
In this section we give an example of an assertion profile, using
SAML [SAML] and XACML [XACML]. This profile is based on the SAML 2.0
Profile of XACML Version 2.0 [SAML-XACML] with a number of
significant changes to this profile, in order to account for the
constrained nature of the resource host.
Since the full syntax of XACML Requests, Responses, and SAML
assertions includes a large number of features, we have defined a
subset of both standards, in order to simplify the processing on the
resource server. Furthermore the XML representation of this subset
is too verbose for efficient transmission over limited channels,
therefore we have defined a compact JSON-based notation of this SAML
and XACML subset.
SAML assertions have the following required elements:
<Author> Expires January 6, 2014 [Page 27]
INTERNET DRAFT <Document Title> July 5, 2013
- An assertion identifier
- The issue instant
- The SAML version number
- The Issuer of the assertion
Furthermore the following optional elements are relevant for the
purposes of this profile:
- The Subject of the assertion
- A Statement (in our case an authorization statement)
The SAML 2.0 Profile of XACML defines an XACML authorization decision
statement as a sequence of an XACML Response and an optional XACML
Request. It is obvious in our case that the Request MUST be part of
the statement to give the necessary context, otherwise it would be
impossible to determine what the Response applies to.
The following restrictions have been defined to create a useful
subset of the SAML assertion format:
- The assertion identifier SHALL be a 128 bit random number encoded
as UUID [RFC4122].
- The issue instant is encoded in UTC form without time zone
component.
- The SAML version number is implicitly assumed to have the value
"2.0".
- The encoding of the Issuer is up to the implementers, but it SHOULD
enable consumers of the assertion to determine the identity of the
trusted entity that issued this assertion, and thus to derive the key
used to verify the signature of the assertion.
- The Subject SHALL either contain a subject identifier that can be
used to bind the assertion to a subject in some way that is implicit
to the consumer, or a subject's public key that can be used in an
authentication scheme.
- The Statement SHALL NOT contain an XACML Response. The Response is
implicitly assumed to contain a PERMIT decision. An entity
generating assertion MUST NOT generate assertions for decisions other
than PERMIT. If the XACML Response contained XACML Obligations these
MUST be included in the Statement. It is RECOMMENDED not to write
<Author> Expires January 6, 2014 [Page 28]
INTERNET DRAFT <Document Title> July 5, 2013
Policies that would result in more than one Obligation in a Response.
The resource server MUST know how to process the Obligation,
otherwise it MUST reject the assertion and deny the request with
error message.
- The XACML Request MUST contain the two single attributes
identifying the resource and the action. The subject identifier MUST
NOT be part of the Request since it is inferred from the SAML subject
identifier. The resource identifier SHALL be the resource URI,
without the scheme name. The query part MAY also be omitted if that
level of granularity is not desired in the access control policies.
The action identifier SHALL be one of the values: GET, POST, PUT,
DELETE. In the case of a POST or PUT action, the payload value of
the action SHALL be encoded as an action attribute with the attribute
identifier "VAL". The entity generating the assertion MUST discard
all other attributes from the Request.
The following compact encoding defines the assertion format in this
profile, listing the JSON elements in the order in which they are
expected to appear in the final assertion object:
- The assertion identifier SHALL use the member name "ID".
- The issue instant SHALL use the member name "II".
- The Issuer SHALL use the member name "IS".
- The Subject element SHALL use the member name "SK" if it represents
a subject-key, where it is assumed that the consuming device and the
issuer of the assertion share a common understanding of the type of
key that is encoded in that value. If the Subject element is an
identifier, it SHALL use the member name "SU".
- The Statement SHALL be a JSON object with the name "ST" containing
the following members:
o If the XACML Response contained any Obligations, they SHALL be
represented in JSON objects or members with the name "OB", the
content or value format of these objects MUST be understood by the
consuming device.
o The action identifier SHALL use the member name "ACT".
o If the action is a PUT or POST, the payload value SHALL use the
member name "VAL".
o The resource identifier SHALL use the member name "RES".
<Author> Expires January 6, 2014 [Page 29]
INTERNET DRAFT <Document Title> July 5, 2013
In order to protect the integrity of the assertion JWS [I-D.ietf-
jose-json-web-signature] SHALL be used. If only the AS is supposed to
sign the assertion it is RECOMMENDED to use JWS Compact
Serialization, if an additional signature by the the origin client is
required (see Sections 5.2.1-5.2.3) it is RECOMMENDED to use JWS JSON
Serialization. If the origin client is required to encrypt the
assertion, this MUST be performed in the same way as specified for
the payload in Section 8.3, where the encrypted plaintext is the JWS
Compact Serialization of the assertion signed by the AS.
Implementations using the ACF PK Scheme (see Section 7.2.1) MUST
support the ES256 algorithm. PrK_AS MUST be used for generating the
signature and PK_AS for verifying the signature.
Implementations using the ACF SSK Scheme (see Section 7.2.2) MUST
support the HS256 algorithm. The Assertion Key AK MUST be used as
key for generating the message authentication code.
The algorithms corresponding to the identifiers above are specified
in [I-D.ietf-jose-json-web-algorithms].
In order to verify the assertion, the RS needs to perform the
following steps:
1. Verify if the assertion has expired. This profile assumes that
each RS uses a fixed validity time for any assertion. Therefore
expiration can be easily checked by verifying the time elapsed since
the issue instant. In cases where the RS lacks the means to measure
time reliably, this step is skipped.
2. Verify if the assertion was issued by a trusted AS, by checking
the Issuer field of the assertion.
3. Verify that the assertion applies to the CoAP request, i.e. that
it applies to the same resource and action.
4. Verify that the origin client is the Subject of the assertion.
This might not be possible if there are intermediary nodes, in this
case the assertion can have an additional signature by the OC to
confirm its intent to perform the authorized action. Note that
certain actions allow implicit authentication (see Sections 5.2.1-
5.2.3), in which case this step can be skipped.
5. Verify the AS signature of the assertion.
6. If the assertion contains any Obligations, check that these are
satisfied.
<Author> Expires January 6, 2014 [Page 30]
INTERNET DRAFT <Document Title> July 5, 2013
The following example illustrates an assertion generated according to
this profile, without the JWS signature:
01 {
02 "ID": "ID_ffda55f9...097bdd21e6",
03 "II": "2013-02-15T10:02:52Z",
04 "IS": "AAA-Server",
05 "SK": "BvDgLAXSHe...0RLhfwS1fue",
06 "ST": {
07 "OB":{
08 "NB":"09:00:00Z",
09 "NA":"17:00:00Z"
10 },
11 "ACT": "GET"
12 "RES": "node346/tempSensor"
13 }
14 }
Note that the assertion shown would have a size of 208 bytes without
pretty printing. The corresponding assertion following the XML
representation of SAML and XACML would be 2281 bytes large. Also
note that this assertion carries an obligation on the time interval
during which access is allowed (NB = not before, NA = not after).
This obligation must be pre-defined on the consuming device so that
it can parse and enforce it.
8.2 Communication Security Profile: DTLS PSK with Bind Key
This section gives an example of a communication security profile
based on DTLS PSK [RFC4279] using the bind key (BK) of the ACF SSK
key provisioning scheme as if it was a pre-shared key. PSK-cipher
suites and cipher suite negotiations are identical.
The setup is identical to the CoAP security mode PreSharedKey [I-
D.ietf-core-coap] with the exception that the key BK is not pre-
provisioned to the resource server but needs to be derived from a
nonce and the shared secret key SSK (Section 7.2.2).
Using the coaps:// schema, DTLS security context is established
before the CoAP request in which the assertion is sent. Therefore,
in order to derive a bind key to be used in the DTLS handshake the
nonce needs also to be sent in the DTLS handshake.
<Author> Expires January 6, 2014 [Page 31]
INTERNET DRAFT <Document Title> July 5, 2013
When using this profile in an end-to-end communication security
setting, the nonce SHALL be included as a DTLS extension in
ClientHello.
The extension type is defined as follows:
enum {
key_derivation(19), (65535)
} ExtensionType;
The "extension_data" field of this extension contains a
"key_derivation_data" value, defined as follows:
struct {
opaque nonce[16];
opaque as_id<1..32>;
} key_derivation_data
The following modifications to the DTLS handshake SHALL apply:
Before composing the ClientHello message, the origin client reads
out the nonce and the AS identifier from the assertion and composes
the key_derivation extension as defined above. This extension is
sent in the ClientHello message.
After receiving the ClientHello message, the resource server looks
up the SSK based on the AS identifier, and computes BK as described
in section 7.2.2, using the provided nonce. BK is used as the PSK
from here on, and the protocol proceeds as specified in [RFC4279].
8.3 Object Security Profile: JWE-protected CoAP payload
This section gives an example of an object security profile, i.e.
protection of CoAP payload by means of secure objects. When using
this profile the Javascript Object Signing and Encryption (JOSE)
standards SHALL be used. Section 5.2 and its subsections specify
when a payload or assertion is to be signed and encrypted. If a
payload is to be signed but not encrypted the JSON Web Signature
(JWS) standard [I-D.ietf-jose-json-web-signature] SHALL be used. If
a payload is to be signed and encrypted the JSON Web Encryption
(JWE) standard [I-D.ietf-jose-json-web-encryption] SHALL be used.
If only a single signature is needed on the assertion, it is
RECOMMENDED to use the Compact Serialization instead of the JSON
Serialization in order to keep the payload size small.
Implementations using the ACF PK Scheme (see Section 7.2.1), MUST
<Author> Expires January 6, 2014 [Page 32]
INTERNET DRAFT <Document Title> July 5, 2013
support the ES256 JWS algorithm. For JWE the ECDH-ES key sharing
algorithms MUST be supported, and for authenticated encryption the
A128GCM algorithm MUST be supported.
Implementations using the ACF SSK Scheme (see Section 7.2.2) MUST
support the HS256 algorithms for JWS. For JWE the dir key sharing
algorithm MUST be supported together with the A128GCM authenticated
encryption algorithm.
Implementations using the A128GCM algorithm MUST ensure that the
specific key freshness requirements of the GCM mode are observed
(see [NIST-SP-800-38D] Section 8.3).
The algorithms corresponding to these identifiers are specified in
[I-D.ietf-jose-json-web-algorithms].
9. Security Considerations
The present framework aims to protect the resources on resource
servers, the servers themselves, and the services offered. The
means proposed to protect these assets is to enforce more granular
access restrictions on accessing the devices than all-or-nothing.
Due to the setup of the framework, there is also a need to protect
the authorization decisions and the keys used to protect the entire
resource access procedure.
The authorization server is a Trusted Third Party from the point of
view of the resource owner, which if compromised could e.g. issue
assertions to unauthorized parties or use a bind key to decrypt an
eavesdropped GET response secure object payload.
In order to enforce a policy decision, the resource server must
authenticate the requesting client, and match the identifier of the
authenticated entity with the subject identifier of the assertion.
As a consequence, in the case of DTLS, the handshake protocol must
potentially be executed without knowing that the request will be
authorized which opens up for a potential DoS attack.
Comparing with authorization using category A identifiers of the
access control lists (equivalent to [I-D.ietf-core-coap]), an
unauthorized CoAP request masquerading as a legitimate will also not
be detected until in the third pass of DTLS handshake.
DTLS introduces stateless cookies in ClientHello to prevent DoS
attacks. The server having received a ClientHello without cookie
from an unverified client sends a HelloVerifyRequest message
expecting the client to return ClientHello with a cookie
<Author> Expires January 6, 2014 [Page 33]
INTERNET DRAFT <Document Title> July 5, 2013
corresponding to the parameter values. Only if the cookie can be
successfully verified by the server will the DTLS handshake protocol
continue. These cookies are unfortunately not very useful in the
setting where the client is much more powerful than the server, and
the very sending of a HelloVerifyRequest may cost much more than
e.g. a verification of a digital signature (e.g. a MAC).
If DTLS Handshake is considered a serious threat for DoS, an
alternative approach is to carry some lightweight (short and easily
computed) keyed integrity information in a TLS extension (TBD) of
the ClientHello. Using the established key material, the server can
infer with reasonable assurance if a request is legitimate and drop
other requests.
While DTLS offers bundled encryption and integrity protection of
both payload and headers, the object security approach allows for a
trade-off between protection against performance. Depending on the
trust model, assertion and payload may need to be encrypted because
eavesdropping will reveal information about the client's request,
which may be privacy sensitive. Wrapping of the payloads as secure
objects allows differentiated protection of the content based on its
sensitiveness.
10. IANA Considerations
<IANA considerations text>
TBD: Text about CoAP option numbers (see 4.3). Text about DTLS/TLS
extension (see 8.2).
<Author> Expires January 6, 2014 [Page 34]
INTERNET DRAFT <Document Title> July 5, 2013
11. References
11.1 Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", draft-ietf-
core-coap-18 (work in progress), June 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2 Informative References
[I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and Keranen, A., "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-04
(work in progress), April 2013.
[SAML]
Cantor, S., Kemp, J., Philpott, R., Maler, E., "Assertions
and Protocols for the OASIS Security Assertion Markup
Language(SAML) V2.0", OASIS, March 2005.
[XACML]
Rissanen, E., "eXtensible Access Control Markup Language
(XACML) Version 3.0", OASIS, September 2012.
[SAML-XACML]
Rissanen E., and Lockhart H., "SAML 2.0 Profile of XACML ,
Version 2.0", OASIS, August 2010.
[I-D.ietf-oauth-v2-http-mac]
Mills, W. and Tschofenig H., Ed., "OAuth 2.0 Message
Authentication Code (MAC) Tokens", draft-ietf-oauth-v2-
http-mac-03 (work in progress), February 2013.
[I-D.ietf-jose-json-web-encryption]
Jones, M., Rescorla, E., and Hildebrand J., "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption-11
(work in progress), May 2013.
[I-D.ietf-jose-json-web-signature]
Jones, M., Bradley, J., and Sakimura N., "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature-11
<Author> Expires January 6, 2014 [Page 35]
INTERNET DRAFT <Document Title> July 5, 2013
(work in progress), May 2013.
[XMLDSig]
Eastlake, D., Reagle, J., Solo, D., Hirsch, F., and
Roessler T., "XML Signature Syntax and Processing (Second
Edition)", W3C Recommendation, June 2008.
[I-D.vial-core-mirror-proxy]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
proxy-01 (work in progress), July 2012.
[I-D.ietf-core-observe]
Hartke, K., "Observing Resources in CoAP", draft-ietf-
core-observe-08 (work in progress), February 2013.
[I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)", draft-ietf-jose-
json-web-algorithms-11 (work in progress), May 2013.
[NIST-SP-800-38D]
Dworkin, M., "Recommendation for Block Cipher Modes of
Operation: Galois/Counter Mode (GCM) and GMAC", NIST
Special Publication 800-38D, November 2007.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC5878] Brown, M. and R. Housley, "Transport Layer Security (TLS)
Authorization Extensions", RFC 5878, May 2010.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869, May 2010.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4279] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
<Author> Expires January 6, 2014 [Page 36]
INTERNET DRAFT <Document Title> July 5, 2013
RFC 4279, December 2005.
Authors' Addresses
Goeran Selander
Ericsson
Farogatan 6
16480 Kista
SWEDEN
EMail: goran.selander@ericsson.com
Mohit Sethi
Ericsson
Hirsalantie 11
02420 Jorvas
FINLAND
EMail: mohit.m.sethi@ericsson.com
Ludwig Seitz
SICS Swedish ICT AB
Scheelevagen 17
22370 Lund
SWEDEN
EMail: ludwig@sics.se
<Author> Expires January 6, 2014 [Page 37]