Internet DRAFT - draft-seitz-ace-problem-description
draft-seitz-ace-problem-description
ACE Working Group L. Seitz
Internet-Draft SICS Swedish ICT
Intended Status: Informational G. Selander
Expires: September 10, 2015 Ericsson
March 9, 2015
Problem Description for Authorization in Constrained Environments
draft-seitz-ace-problem-description-03
Abstract
We present a problem description for authentication and authorization
in constrained-node networks, i.e. networks where some devices have
severe constraints on memory, processing, power and communication
bandwidth.
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
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) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Seitz & Selander Expires September 10, 2015 [Page 1]
INTERNET DRAFT Problem description for ACE March 9, 2015
(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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Authorization . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Communication Security . . . . . . . . . . . . . . . . . . 7
3.4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 8
4. Assumptions and Requirements . . . . . . . . . . . . . . . . . 8
4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Constrained Devices . . . . . . . . . . . . . . . . . . . . 9
4.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . 10
4.4 Authorization . . . . . . . . . . . . . . . . . . . . . . . 10
4.5 Authorization Information . . . . . . . . . . . . . . . . . 11
4.6 Resource Access . . . . . . . . . . . . . . . . . . . . . . 11
4.7 Keys and Cipher Suites . . . . . . . . . . . . . . . . . . . 12
4.8 Network Considerations . . . . . . . . . . . . . . . . . . . 12
4.9 Legacy Considerations . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1 Physical Attacks on Sensor and Actuator Networks . . . . . . 13
5.2 Time Measurements . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Seitz & Selander Expires September 10, 2015 [Page 2]
INTERNET DRAFT Problem description for ACE March 9, 2015
1. Introduction
Authorization is the process of deciding what an entity ought to be
allowed to do. This memo is about properties of security protocols
to enable explicit and dynamic authorization of clients to access a
resource at a server, in particular in constrained environments when
the client and/or server are constrained nodes.
Relevant use cases are provided in [I-D.ietf-ace-usecases], which
also lists some authorization problems derived from the use cases.
In this memo we present a more specific problem description for
authentication and authorization in constrained RESTful environments
together with a detailed set of assumptions and requirements (cf.
section 4).
1.1 Terminology
Certain security-related terms are to be understood in the sense
defined in [RFC4949]. These terms include, but are not limited to,
"authentication", "authorization", "confidentiality", "(data)
integrity", "message authentication code", and "verify".
RESTful terms including "resource", "representation", etc. are to be
understood as used in HTTP [RFC7231] and CoAP [RFC7252].
Terminology for constrained environments including "constrained
device", "constrained-node network", "class 1", etc. are defined in
[RFC7228].
"Explicit" authorization is used here to describe the ability to
specify in some detail which entity has access to what and under what
conditions, as opposed to "implicit" authorization where an entity is
either allowed to access everything or nothing.
"Dynamic" authorization means that the access control polices and the
parameters on which they are evaluated may change during normal
operations, as opposed to "static" authorization meaning that access
control policies cannot be changed during normal operations and may
require some special procedure such as out-of-band provision.
2. Background
We assume a client-server setting, where a client wishes to access
some resource hosted by a server. Such resources may e.g. be sensor
data, configuration data, or actuator settings. Thus access to a
resource could be by different methods, some of which change the
state of the resource. In this memo, we consider the REST setting
Seitz & Selander Expires September 10, 2015 [Page 3]
INTERNET DRAFT Problem description for ACE March 9, 2015
i.e. GET, POST, PUT and DELETE, and application protocols in scope
are HTTP [RFC7231] and CoAP [RFC7252].
We assume that the roles of client and server are not fixed, i.e. a
node which is client could very well be server in some other context
and vice-versa. Further we assume that in some cases, clients are
not previously known to servers, thus we cannot assume that the
server has access control policies specific to that client when the
client initiates communication.
Finally we also assume that in a significant number of cases, the
server and/or the client are too constrained to handle the evaluation
of complex access control policies and related configuration on their
own. Many authorization solutions involve a centralized, trusted
third party, supporting the client and/or resource server. A trusted
third party provides a more scalable way to centrally manage
authorization policies, in order to ensure consistent authorization
decisions. The physical separation of policy decision and policy
enforcement is an established principle in policy based management,
e.g. [RFC2748].
Borrowing from OAuth 2.0 [RFC6749] terminology we name the entities:
client (C), resource server (RS), authorization server (AS - the
third party), and resource owner (RO). RO is in charge of the access
control policies implemented in the AS governing the actions of RS.
However, the RO need not be active in a constrained device access
control setting, so we cannot rely on timely interactions with the
RO. In the target setting RS is typically constrained, C may be
constrained, whereas AS is not assumed to be constrained.
Since RS is constrained, we assume that it needs to offload
authorization policy management and/or authorization decision making
to AS. This means that some authorization information needs to be
transferred from AS to RS.
Protecting information carried between AS and RS, requires some a
priori established cryptographic keys. How those keys are
established is out of scope for this problem description.
AS may for example be implemented as a cloud service, in a home
server, or in a smartphone. C and RS may or may not have
connectivity to AS at the time of the access request, e.g. because
they cannot handle multiple, simultaneous connections. Another
reason for intermittent connectivity may be that constant
connectivity is not affordable (e.g. due to limited battery power, or
a sensor mobility business case for which cellular connectivity cost
too much or is not available). Obviously, in order for a client
request to reach RS there must be connectivity between C and RS, but
Seitz & Selander Expires September 10, 2015 [Page 4]
INTERNET DRAFT Problem description for ACE March 9, 2015
that could be a short range technology such as Bluetooth, ZigBee, or
NFC. Furthermore, if there is not sufficient authorization
information about C in RS, and neither C nor RS can access AS, access
requests will be denied. Therefore we assume that either C or RS can
access AS at some point in time, prior to the client's request.
As a summary, there are potentially three information flows that
needs to be protected (see Figure):
1. The transfer of authorization information from AS to RS
2. The transfer of cryptographic keys or credentials from AS to RS
and C, respectively
3. The access request/response procedure between C and RS
+---------------+
| Authorization |
| Server |
| |
+---------------+
/ \ Authorization
Credentials, / \ Information
Keys / \
/ \ Credentials,
/ \ Keys
V V
+--------+ +-----------+
| Client | | Resource |
| |<---- Access procedure --->| Server |
| | | |
+--------+ +-----------+
Figure. Information flows that needs to be protected.
Only showing origin and destination, actual
flow may pass intermediary nodes.
NOTE:
The information flow in 1. above enables RO to control the
interactions of a constrained RS by means of access control policies.
There is an ongoing discussion about an analogous information flow
enabling the stakeholder associated to C ("Requesting Party" in UMA
Seitz & Selander Expires September 10, 2015 [Page 5]
INTERNET DRAFT Problem description for ACE March 9, 2015
terminology [I-D.hardjono-oauth-umacore]) to control the interactions
of a constrained C by means of policies. While this would not be
policies for access control to resources, it could be useful in
certain settings which require dynamically changing interaction
patterns with a constrained client without updating firmware. Such a
solution could potentially reuse all security components required to
protect the information flow in 1., so no additional specifications
would be needed. This aspect is not discussed further in this draft.
3. Problem Description
A number of problems needs to be solved in order to achieve explicit
and dynamic authorization, as is described in this section.
3.1. Authorization
The core problem we are trying to solve is authorization. The
following problems related to authorization need to be addressed:
o AS needs to transfer authorization information to RS.
o The transferred authorization information needs to follow a
defined format and encoding, which must be efficient for
constrained devices, considering size of authorization
information and parser complexity.
o The RS needs to be able to verify the authenticity of the
authorization information. There is a trade-off here between
processing complexity and deployment complexity.
o The RS needs to enforce the authorization decisions of the AS.
The authorization information it obtained from AS might require
additional policy evaluation (e.g. matching against local access
control lists, evaluating local conditions). The required
"policy evaluation" at the RS needs to be adapted to the
capabilities of the constrained device.
o Finally, as is indicated in the previous bullet, for a
particular authorization decision there may be different kinds
of authorization information needed, and these pieces of
information may be transferred to RS at different times and in
different ways prior to or during the client request.
3.2. Authentication
The following problems need to be addressed, when considering
Seitz & Selander Expires September 10, 2015 [Page 6]
INTERNET DRAFT Problem description for ACE March 9, 2015
authentication:
o RS need to authenticate AS to ensure that the authorization
information and related data comes from the correct source.
o C may need to to authenticate AS to ensure that it gets security
information related to the resources from the right source.
o In some use cases RS needs to authenticate some property of C,
in order to bind it to the relevant authorization information.
In other use cases, authentication and authorization of C may be
implicit, e.g. by encrypting the resource representation the RS
only providing access to those who possess the key to decrypt.
o C may need to authenticate RS, in order to ensure that it is
interacting with the right resources. Alternatively C may just
verify the integrity of a received resource representation.
o AS may need to authenticate its communication partner (either C
or RS), in order to ensure it serves the correct device.
3.3. Communication Security
There are different alternatives to provide communication security,
and the problem here is to choose the optimal one for each scenario.
We list the available alternatives:
o Session-based security at transport layer such as DTLS [RFC6347]
offers security, including integrity and confidentiality
protection, for the whole application layer exchange. However,
DTLS may not provide end-to-end security over multiple hops.
Another problem with DTLS is the cost of the handshake protocol,
which may be too expensive for constrained devices especially in
terms of memory and power consumption for message transmissions.
o An alternative is object security at application layer, e.g.
using [I-D.selander-ace-object-security]. Secure objects can be
stored or cached in network nodes and provide security for a
more flexible communication model such as publish/subscribe
(compare e.g. CoRE Mirror Server [I-D.koster-core-coapmq]). A
problem with object security is that it can not provide
confidentiality for the message headers.
o Hybrid solutions using both session-based and object security
are also possible. An example of a hybrid is where
authorization information and cryptographic keys are provided by
Seitz & Selander Expires September 10, 2015 [Page 7]
INTERNET DRAFT Problem description for ACE March 9, 2015
AS in the format of secure data objects, but where the resource
access is protected by session-based security.
3.4. Cryptographic Keys
With respect to cryptographic keys, we see the following problems
that need to be addressed:
o Symmetric vs Asymmetric Keys
We need keys both for protection of resource access and for
protection of transport of authentication and authorization
information. Do we want to support solutions based on
asymmetric keys or symmetric keys in both cases?
There are classes of devices that can easily perform symmetric
cryptography, but consume considerably more time/battery for
asymmetric operations. On the other hand asymmetric
cryptography has benefits e.g. in terms of deployment.
o Key Establishment
How are the corresponding cryptographic keys established?
Considering section 3.1 there must be a binding between these
keys and the authorization information, at least in the sense
that AS must be able to specify a unique client identifier which
RS can verify (using an associated key).
One of the use cases of [I-D.ietf-ace-usecases] describes
spontaneous change of access policies - e.g. giving a hitherto
unknown client the right to temporarily unlock your house door.
In this case C is not previously known to RS and a key must be
provisioned by AS.
o Revocation and Expiration
How are keys replaced and how is a key that has been compromised
revoked in a manner that reaches all affected parties, also
keeping in mind scenarios with intermittent connectivity?
4. Assumptions and Requirements
In this section we list a set of candidate assumptions and
requirements to make the problem description in the previous sections
more concise and precise.
4.1 Architecture
Seitz & Selander Expires September 10, 2015 [Page 8]
INTERNET DRAFT Problem description for ACE March 9, 2015
The architecture consists of at least the following types of nodes:
o RS hosting resources, and responding to access requests
o C requesting access to resources
o AS supporting the access request/response procedure by providing
authorization information to RS.
- AS may also provide other services such as authenticating C
on behalf of RS, or providing cryptographic keys or
credentials to C and/or RS to secure the request/response
procedure.
o The architecture may contain intermediary nodes between any pair
of C, RS and AS, such as e.g. forward/reverse proxies in the
CoRE architecture. The solution shall not unduly restrict the
use of intermediaries.
- The architecture shall support session based security and
data object security.
4.2 Constrained Devices
o C and/or RS may be constrained in terms of power, processing,
communication bandwidth, memory and storage space, and moreover
- unable to manage complex authorization policies
- unable to manage a large number of secure connections
- without user interface
- without constant network connectivity
- unable to precisely measure time
- required to save on wireless communication due to high power
consumption
o AS is not a constrained device.
o All devices under consideration can process symmetric
cryptography without incurring an excessive performance penalty.
- We assume the use of a standardized symmetric key algorithm,
such as AES.
Seitz & Selander Expires September 10, 2015 [Page 9]
INTERNET DRAFT Problem description for ACE March 9, 2015
- Except for the most constrained devices we assume the use of
a standardized cryptographic hash function such as SHA-256.
o Public key cryptography requires additional resources (e.g. RAM,
ROM, power, specialized hardware).
o A DTLS handshake involves significant computation,
communication, and memory overheads in the context of
constrained devices.
- The RAM requirements of DTLS handshakes with public key
cryptography are prohibitive for certain constrained devices.
- Certificate-based DTLS handshakes require significant volumes
of communication, RAM (message buffers) and computation.
o The solution shall support a simple scheme for expiring
authentication and authorization information on devices which
are unable to measure time (cf. section 5.2).
4.3 Authentication
o RS need to authenticate AS to ensure that the authorization
information and related data comes from the correct source.
o Depending on use case, C, RS or AS may need to authenticate each
other.
4.4 Authorization
o The authorization decision is based on credentials presented by
C, the requested resource, the RESTful method, and local context
in RS at the time of the request, or on any subset of this
information.
o The authorization decision is taken either by AS or RS.
o The authorization decision is enforced by RS.
- RS needs to have access to authorization information in order
to verify that C is allowed to access the resource as
requested.
- RS needs to make sure that it provides resource access only
to authorized clients.
o Apart from authorization for access to a resource, authorization
may also be required for access to information about a resource
Seitz & Selander Expires September 10, 2015 [Page 10]
INTERNET DRAFT Problem description for ACE March 9, 2015
(e.g. resource descriptions).
o The solution may need to be able to support the delegation of
access rights.
4.5 Authorization Information
o Authorization information is transferred from AS to RS using
Agent, Push or Pull mechanisms [RFC2904].
o RS shall authenticate that the authorization information is
coming from AS.
o The authorization information may also be encrypted end-to-end
between AS and RS.
o RS may not be able to communicate with AS at the time of the
request from C.
o RS may store or cache authorization information.
o Authorization information may be pre-configured in RS.
o Authorization information stored or cached in RS shall be
possible to change. The change of such information shall be
subject to authorization.
o Authorization policies stored on RS may be handled as a
resource, i.e. information located at a particular URI, accessed
with RESTful methods, and the access being subject to the same
authorization mechanics. AS may have special privileges when
requesting access to the authorization policy resources on RS.
o There may be mechanisms for C to look up the AS which provides
authorization information about a particular resource.
4.6 Resource Access
o Resources are accessed in a RESTful manner using GET, PUT, POST,
DELETE.
o By default, the resource request shall be integrity protected
and may be encrypted end-to-end from C to RS. It shall be
possible for RS to detect a replayed request.
o By default, the response to a request shall be integrity
protected and encrypted end-to-end from RS to C. It shall be
possible for C to detect a replayed response.
Seitz & Selander Expires September 10, 2015 [Page 11]
INTERNET DRAFT Problem description for ACE March 9, 2015
o RS shall be able to verify that the request comes from an
authorized client
o C shall be able to verify that the response to a request comes
from the intended RS.
o There may be resources whose access need not be protected (e.g.
for discovery of the responsible AS).
4.7 Keys and Cipher Suites
o AS and RS have established cryptographic keys. Either AS and RS
share a secret key or each have the other's public key.
o The transfer of authorization information is protected with
symmetric and/or asymmetric keys.
o The access request/response can be protected with symmetric
and/or asymmetric keys.
o There must be a mechanism for RS to establish the necessary
key(s) to verify and decrypt the request.
o There must be a mechanism for C to establish the necessary
key(s) to verify and decrypt the response.
o There must be a mechanism for C to look up the supported cipher
suites of a RS.
4.8 Network Considerations
o The solution shall prevent network overload due to avoidable
communication with AS.
o The solution shall prevent network overload by compact
authorization information representation.
o The solution shall optimize the case where authorization
information does not change often.
o The solution where possible shall support an efficient mechanism
for providing authorization information to multiple RSs, for
example when multiple entities need to be configured or change
state.
4.9 Legacy Considerations
Seitz & Selander Expires September 10, 2015 [Page 12]
INTERNET DRAFT Problem description for ACE March 9, 2015
o The solution shall work with existing infrastructure.
o The solution shall support authorization of access to legacy
devices.
5. Security Considerations
The entire document is about security. Security considerations
applicable to authentication and authorization in RESTful
environments are provided in e.g. OAuth 2.0 [RFC6749].
In this section we focus on specific security aspects related to
authorization in constrained-node networks.
5.1 Physical Attacks on Sensor and Actuator Networks
The focus of this work is on constrained-node networks consisting of
connected sensors and actuators. The main function of such devices
is to interact with the physical world by gathering information or
performing an action. We now discuss attacks performed with physical
access to such devices.
The main threats to sensors and actuator networks are:
o Unauthorized access to data to and from sensors and actuators,
including eavesdropping and manipulation of data.
o Denial-of-service making the sensor/actuator unable to perform
its intended task correctly.
A number of attacks can be made with physical access to a device
including probing attacks, timing attacks, power attacks, etc.
However, with physical access to a sensor or actuator device it is
possible to directly perform attacks equivalent of eavesdropping,
manipulating data or denial of service. For example:
o Instead of eavesdropping the sensor data or attacking the
authorization system to gain access to the data, the attacker
could make its own measurements on the physical object.
o Instead of manipulating the sensor data the attacker could
change the physical object which the sensor is measuring,
thereby changing the payload data which is being sent.
o Instead of manipulating data for an actuator or attacking the
authorization system, the attacker could perform an unauthorized
action directly on the physical object.
Seitz & Selander Expires September 10, 2015 [Page 13]
INTERNET DRAFT Problem description for ACE March 9, 2015
o A denial-of-service attack could be performed physically on the
object or device.
All these attacks are possible by having physical access to the
device, since the assets are related to the physical world.
Moreover, this kind of attacks are in many cases straightforward
(requires no special competence or tools, low cost given physical
access, etc.)
As a conclusion, if an attacker has physical access to a sensor or
actuator device, then much of the security functionality elaborated
in this draft is not effective to protect the asset during the
physical attack.
Since it does not make sense to design a solution for a situation
that cannot be protected against we assume there is no need to
protect assets which are exposed during a physical attack. In other
words, either an attacker does not have physical access to the sensor
or actuator device, or if it has, the attack shall only have effect
during the period of physical attack.
5.2 Time Measurements
Measuring time with certain accuracy is important to achieve certain
security properties, for example to determine whether a public key
certificate, access token or some other assertion is valid.
Dynamic authorization in itself requires the ability to handle expiry
or revocation of authorization decisions or to distinguish new
authorization decisions from old.
For certain categories of devices we can assume that there is an
internal clock which is sufficiently accurate to handle the time
measurement requirements. If RS can connect directly to AS it could
get updated in terms of time as well as revocation information.
If RS continuously measures time but can't connect to AS or other
trusted source, time drift may have to be accepted and it may not be
able to manage revocation. However, it may still be able to handle
short lived access rights within some margins, by measuring the time
since arrival of authorization information or request.
Some categories of devices in scope may be unable measure time with
any accuracy (e.g. because of sleep cycles). This category of
devices is not suitable for the use cases which require measuring
validity of assertions and authorizations in terms of absolute time.
Seitz & Selander Expires September 10, 2015 [Page 14]
INTERNET DRAFT Problem description for ACE March 9, 2015
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgements
The authors would like to thank Carsten Bormann, Stefanie Gerdes,
Sandeep Kumar, John Mattson, Corinna Schmitt, Mohit Sethi, Hannes
Tschofenig, Vlasios Tsiatsis and Erik Wahlstroem for contributing to
the discussion, giving helpful input and commenting on the 00-
version. The authors would also like to acknowledge input provided
by draft-gerdes-ace-actors [I-D.gerdes-ace-actors] and by Hummen et
al. [HUM14delegation].
8. References
8.1 Informative References
[I-D.ietf-ace-usecases]
Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. Kumar, "ACE use
cases", draft-ietf-ace-usecases-02 (work in progress), February
2015.
[I-D.hardjono-oauth-umacore]
Hardjono, T., Maler, E., Machulak, M. and D. Catalano, "User-Managed
Access (UMA) Profile of OAuth 2.0", draft-hardjono-oauth-umacore-12
(work in progress), February 2015.
[I-D.selander-ace-object-security] Selander G., Mattsson J., and L.
Seitz, "Object Security for CoAP", draft-selander-ace-object-
security-00 (work in progress), October 2014.
[I-D.koster-core-coapmq]
Koster, M., Keranen A., and J. Jimenez "Message Queueing in the
Constrained Application Protocol (CoAP)", draft-koster-core-coapmq-00
(expired), July 2014
[I-D.gerdes-ace-actors]
Gerdes, S., "Actors in the ACE Architecture", draft-gerdes-ace-
actors-02 (work in progress), October 2014.
[HUM14delegation] Hummen, R., Shafagh, H., Raza, S., Voigt, T.,
Wehrle, K., "Delegation-based Authentication and Authorization for
the IP-based Internet of Things", 11th IEEE International Conference
on Sensing, Communication, and Networking (SECON'14), June 30 - July
3, 2014.
Seitz & Selander Expires September 10, 2015 [Page 15]
INTERNET DRAFT Problem description for ACE March 9, 2015
[RFC2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan,
R., and A. Sastry, "The COPS (Common Open Policy Service)
Protocol", RFC 2748, January 2000, <http://www.rfc-
editor.org/info/rfc2748>.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, August
2000, <http://www.rfc-editor.org/info/rfc2904>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI
36, RFC 4949, August 2007, <http://www.rfc-
editor.org/info/rfc4949>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012,
<http://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012, <http://www.rfc-
editor.org/info/rfc6749>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7231] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Semantics and Content",
RFC 7231, June 2014, <http://www.rfc-
editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
Authors' Addresses
Ludwig Seitz
SICS Swedish ICT AB
Scheelevagen 17
22370 Lund
SWEDEN
EMail: ludwig@sics.se
Goeran Selander
Ericsson
Farogatan 6
Seitz & Selander Expires September 10, 2015 [Page 16]
INTERNET DRAFT Problem description for ACE March 9, 2015
16480 Kista
SWEDEN
EMail: goran.selander@ericsson.com
Seitz & Selander Expires September 10, 2015 [Page 17]
