ACE Working Group L. Seitz
Internet-Draft SICS Swedish ICT
Intended Status: Informational G. Selander
Expires: November 17, 2014 Ericsson
May 16, 2014
Problem Description for Authorization in Constrained Environments
draft-seitz-ace-problem-description-00
Abstract
We present a problem description for authentication and authorization
in constrained-node networks, i.e. networks which contain some
devices with severe constraints on power, memory, and processing
resources.
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) 2014 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 November 17, 2014 [Page 1]
INTERNET DRAFT Problem description for ACE May 16, 2014
(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 . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Communication Security . . . . . . . . . . . . . . . . . . 8
3.4. Key Management . . . . . . . . . . . . . . . . . . . . . . 9
4. Assumptions and Requirements . . . . . . . . . . . . . . . . . 10
4.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Constrained Devices . . . . . . . . . . . . . . . . . . . . 10
4.3 Authorization . . . . . . . . . . . . . . . . . . . . . . . 11
4.4 Authorization information . . . . . . . . . . . . . . . . . 11
4.5 Access to authorization information . . . . . . . . . . . . 11
4.6 Resource access . . . . . . . . . . . . . . . . . . . . . . 12
4.7 Keys and cipher suites . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1 Normative References . . . . . . . . . . . . . . . . . . . 13
8.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Seitz & Selander Expires November 17, 2014 [Page 2]
INTERNET DRAFT Problem description for ACE May 16, 2014
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. See section 1.1 for
terminology.
Relevant use cases are presented in [I-D.seitz-ace-usecases], which
also lists requirements derived from the use cases. That draft
provides a good setting for the scope of the problem area, but does
not present a detailed problem statement.
We present in this memo a problem description for authentication and
authorization in constrained environments with some more detailed
candidate assumptions and requirements (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", "encryption",
"data integrity", "message authentication code", and "verify".
RESTful terms including "resource", "representation", etc. are to be
understood as used in RFC2616 and CoAP [I-D.ietf-core-coap].
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
Seitz & Selander Expires November 17, 2014 [Page 3]
INTERNET DRAFT Problem description for ACE May 16, 2014
resource could be by different methods, some of which change the
state of the resource. In this memo, we consider the REST setting
i.e. GET, POST, PUT and DELETE, and application protocols in scope
are HTTP and CoAP [I-D.ietf-core-coap].
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
authorization decision procedure 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. Instead of having the client-server interaction
performing authentication, authorization, key establishment, etc. the
third party can be involved to offer support with one or several of
these tasks:
o One example of support is that the client is authenticated to
the third party instead of the server. To provide confidence to
the server that a certain client has indeed been authenticated,
some information identifying the authenticated client (in a
protected form) needs to be communicated from the third party
to the server, e.g. a secret key of the client.
o A second example is that the third party provides a shared
secret key to enable authentication and secure communication
between the client and server, instead of client and server
establishing this autonomously. The shared key needs to be
communicated (in a protected form) from the third party to
client and server, respectively.
o A third example is that the authorization decision is performed
by the third party instead of by the server. To provide
confidence to the server about a specific authorization
decision, some authorization information (in a protected form)
needs to be communicated from the third party to the server.
In addition, the server needs some information identifying the
client to verify that the requesting party is indeed the
authorized client, e.g. a secret key with which the server can
verify a message authentication code generated by the client.
Seitz & Selander Expires November 17, 2014 [Page 4]
INTERNET DRAFT Problem description for ACE May 16, 2014
Protecting information carried between third party and server,
requires some a priori established keys. How those keys are
established is out of scope for this problem. However, keys that are
used to protect information between third party and client are in
scope: The reason being that dynamic access control is one of the
use cases to be supported, and this may involve granting access to a
client previously unknown to the server.
Borrowing from OAuth 2.0 [RFC6749] terminology we have a client (C),
a resource server (RS), an authorization server (AS - the third
party), and a resource owner (RO). The RO does not need to be active
in an M2M access control setting, so interactions with the RO are out
of scope for this memo. In the target setting the RS is typically
constrained, C may be constrained, whereas the AS is not assumed to
be constrained. We also assume that keys are established between RS
and AS (potentially via the RO) before the protocol begins.
Since the RS is constrained, we assume that it needs to offload
authorization policy management and authorization decision making to
the AS. (NOTE: The physical separation of policy decision and policy
enforcement is an established principle in policy based management,
e.g. [RFC2748].) This means that authorization information needs to
be transferred from AS to RS. This information may be specific
access control decisions such as "client C has the right to access
this URI with this RESTful method, this payload value, under these
local conditions", "client C has the right to access these URIs" or
more indirect information "client C is in this access group". In the
latter it is assumed that the RS knows what rights are associated to
a particular access group.
The AS may for example be implemented as a cloud service, in a home
server, or in a smart phone. The client and the RS may or may not
have connectivity to AS (e.g. because the AS is switched off), or may
only have intermittent connectivity, where a connection at the time
of access request cannot be guaranteed. 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 the
RS there must be connectivity between C and RS, but that could be a
short range technology such as NFC, ZigBee, Bluetooth etc.
Furthermore, if there is no previous authorization information in the
RS about the client, and neither can access the AS, access requests
will be denied. Therefore we assume that either the client or the RS
can access the AS at some point in time, prior to the client's
request.
As a summary, there are potentially a number of information flows
Seitz & Selander Expires November 17, 2014 [Page 5]
INTERNET DRAFT Problem description for ACE May 16, 2014
that needs to be secured:
a. The transfer of authorization information from AS to RS
b. The transfer of keys or credentials from AS to RS and C,
respectively
c. The access request/response procedure between C and RS
3. Problem Description
From the background described in the previous section, we see the
following problems that need to be solved in order to achieve
explicit and dynamic authorization:
o Authorization
The RS must have access to authorization information and client
information.
Given that the relevant information has been provided to the RS,
it must be able to handle an access request (match request
against the authorization information, grant or deny the
request, and in the case of grant perform what is requested). We
call this process authorization decision enforcement.
o Authentication
Some property of the client needs to be authenticated to bind
authorization information to it.
The RS needs to establish the authenticity of authorization
information, and that is comes for a trusted AS.
Finally some property of the RS needs to be authenticated to the
client, so that the client can verify that it is communicating
with the intended RS.
o Communication Security
Communication security is needed to protect the integrity, and
sometimes the secrecy of information flows between the parties.
This includes the flow of authentication and authorization
information, but also the actual request and response upon which
access control is performed.
o Key establishment
Seitz & Selander Expires November 17, 2014 [Page 6]
INTERNET DRAFT Problem description for ACE May 16, 2014
The client and the RS need to establish keys in order to set up
secure communications
These problems are interconnected. For example when authorization
information flows from the AS to the RS, this can be solved either by
a pull or push directly from AS to RS or via the client by using some
protected data object. The authorization information must be
integrity protected by the keys established between AS and RS, and
the RS must be able to authenticate the AS as the source of this
information.
Most importantly, all the above needs to take into account potential
constrained devices.
3.1. Authorization
The core problem we are trying to solve is authorization:
o The AS needs to transfer authorization information to the RS.
This can be done through three different message sequences:
Agent, Pull or Push [RFC2904].
- In the agent sequence, the client submits its request to the
AS and the AS contacts the RS to execute the request on the
client's behalf.
- When using the pull sequence, the client contacts the RS and
the RS pulls authorization information directly from the AS
as a reaction to the client's request (as e.g. in RADIUS
[RFC2865]).
- In the push sequence, the client is used as intermediary
between the AS and the RS, and authorization information is
transferred in the form of some token (as e.g. in OAuth
[RFC6749]).
Each of these approaches has it's drawbacks and advantages in
constrained environments, which needs to be weighed against each
other.
o What does the transferred authorization information contain and
how should it be formatted/encoded? Again this must be efficient
for constrained devices, considering size of authorization
information and parser complexity.
o How does the RS verify the authenticity of the authorization
information? This strongly depends on the solution chosen for
Seitz & Selander Expires November 17, 2014 [Page 7]
INTERNET DRAFT Problem description for ACE May 16, 2014
the first bullet.
o How does the RS enforce authorization decisions of the AS? Does
the authorization information it obtained from the AS require
additional policy evaluation (e.g. matching against local access
control lists, evaluating local conditions)? What kind of policy
evaluation can we assume a constrained device to be capable of?
3.2. Authentication
The following problems need to be addressed, when considering
authentication:
o The RS needs to authenticate some property of the client, in
order to bind it to the authorization information. This could
e.g. be a digital signature or a message authentication codes
performed by the client where a corresponding key is contained
in the authorization information.
o In many use cases the client wants to authenticate the RS, in
order to ensure that it is interacting with the right
resources.
o The AS needs to authenticate its communication partner (either
client or RS) in order to avoid leaking access control policy
information.
o Since the AS has a trust relation to both client and RS, it
could also provide them with the means of mutual authentication
(similar to a Kerberos [RFC4120] server). This would make it
possible for the RS to authenticate previously unknown clients.
3.3. Communication Security
For communication security there are different alternatives that
offer various trade-offs, e.g. between performance and security.
o One is session-based security at transport layer such as DTLS
[RFC6347], which offers security, including integrity and
confidentiality protection, for the whole application layer
exchange. One cost of DTLS is the handshake protocol, which may
be expensive for constrained devices especially in terms of
wireless network communication.
o An alternative is data object security at application layer,
e.g. using JWE [I-D.ietf-jose-json-web-encryption]. Secure
objects can be stored in network nodes to handle security for a
more flexible communication model such as publish/subscribe
Seitz & Selander Expires November 17, 2014 [Page 8]
INTERNET DRAFT Problem description for ACE May 16, 2014
(compare e.g. CoRE Mirror Server [I-D.vial-core-mirror-proxy]).
However, data object security only would not provide
confidentiality for the message headers. For example,
information such as the RESTful method, the host address, and
the resource URI could be revealed.
There are other differences in security properties between session
based security and data object security, a detailed comparison is
beyond the scope of this memo.
A solution to the overall authorization problem may be based on
session-based security only, data object security only or a hybrid.
An example of a hybrid is where authorization information and keys
are provided by the AS in the format of secure objects, but where the
resource access is protected by session-based security. (For secure
objects containing authorization information, compare e.g. OAuth 2.0
MAC Tokens [I-D.ietf-oauth-v2-http-mac].)
A hybrid solution may also be useful to support a flexible trust
model, e.g. a resource representation wrapped in JWE sent over DTLS
hop-by-hop in a case where an intermediary is allowed to read the
header but not the payload.
There are no assumptions or requirements on communication security in
this version of the draft as there are ongoing discussions on this
topic.
3.4. Key Management
With respect to key management, we see the following problems that
need to be addressed:
o Symmetric vs Asymmetric
Do we want to support asymmetric or symmetric key solutions, or
both? The question applies both to protection of resource
access and transport of authentication and authorization
information.
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 keys established? Considering section
3.1 there must be a binding between these keys and the
Seitz & Selander Expires November 17, 2014 [Page 9]
INTERNET DRAFT Problem description for ACE May 16, 2014
authorization information, at least in the sense that the AS
must be able to specify a unique client identifier which the RS
can verify (using an associated key).
One of the use cases of [I-D.seitz-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 the client key is not previously known to the RS
and must be provisioned by the AS.
o Revocation and Expiration
How are the keys renewed and how is a key that has been
compromised revoked in a manner that reaches all relying
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.
The purpose of making this list is not to stipulate "the unique
problem description", but to stimulate an aligned discussion on what
assumptions and requirements the solution to the authorization
problem should be based on.
4.1 Architecture
The architecture consists of at least the following 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. The AS may also provide other
services such as authenticating C on behalf of the RS or
providing 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. translation/reverse proxies.
4.2 Constrained Devices
Seitz & Selander Expires November 17, 2014 [Page 10]
INTERNET DRAFT Problem description for ACE May 16, 2014
o C and RS are class 1 or less constrained devices
o AS is not a constrained device
o All devices can process symmetric cryptography without incurring
an excessive performance penalty
o The performance penalty for asymmetric cryptography is high for
a significant set of constrained devices
o The performance penalty for handling public key certificates and
especially public key certificate chains is high for a
significant set of constrained devices.
o The performance penalty for handling revocation lists is high
for a significant set of constrained devices.
o Wireless communication has high performance penalty for a
significant set of constrained devices
o The RS may not be able to reliably measure time
4.3 Authorization
o The authorization decision may be taken either by AS or RS
o The authorization decision are enforced by RS
o There may be mechanisms for a client to look-up the
corresponding AS for an RS
4.4 Authorization information
o The authorization information shall contain either client
capability lists, client attributes or authorization decisions
o The authorization information shall contain information to allow
the RS to verify that a requesting client is authorized
4.5 Access to authorization information
o The RS shall authenticate the authorization information coming
from the AS. The authorization information may be communicated
via the client.
o The authorization information shall be integrity protected and
may be encrypted end-to-end between the AS and the RS
Seitz & Selander Expires November 17, 2014 [Page 11]
INTERNET DRAFT Problem description for ACE May 16, 2014
o The RS may not be able to communicate with the AS at the time of
the request from a client
o The RS may store authorization information
o Authorization information stored in RS shall be possible to
change. The change of such information shall be authorized
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 the client to the RS. It
shall be possible for the RS to detect a replayed request.
o By default, the response to a request shall be integrity
protected and may be encrypted end-to-end from the RS to the
client.
o By default, the client 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
4.7 Keys and cipher suites
o The protection of access request/response between client and RS
shall support the use of symmetric and/or asymmetric keys
o The protection of authorization information shall support the
use of symmetric and asymmetric keys
o There may be a mechanism for the client to look-up the supported
cipher suites of a RS
5. Security Considerations
The entire document is about security considerations.
6. IANA Considerations
This document has no actions for IANA.
Seitz & Selander Expires November 17, 2014 [Page 12]
INTERNET DRAFT Problem description for ACE May 16, 2014
7. Acknowledgements
The authors would like to thank Vlasios Tsiatsis and John Mattson for
contributing to the discussion and giving helpful comments.
8. References
8.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.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
8.2 Informative References
[I-D.seitz-ace-usecases]
Seitz, L., Gerdes, S., and Selander, G., "ACE use cases",
draft-seitz-ace-usecases (work in progress), February
2014.
[I-D.ietf-jose-json-web-encryption]
Jones, M., Hildebrand, J., "JSON Web Encryption (JWE)",
draft-ietf-jose-json-web-encryption (work in progress),
April 2014.
[I-D.vial-core-mirror-proxy]
Vial, M., "CoRE Mirror Server", draft-vial-core-mirror-
proxy (expired), July 2012.
[I-D.ietf-oauth-v2-http-mac]
Richter, J., Mills, W., Tschofenig, H. (Ed.), Hunt, P.,
"OAuth 2.0 Message Authentication Code (MAC) Tokens",
draft-ietf-oauth-v2-http-mac (work in progress), January
2014.
[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.
Seitz & Selander Expires November 17, 2014 [Page 13]
INTERNET DRAFT Problem description for ACE May 16, 2014
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[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.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
[RFC7228] Bormann, C., Ersue, M., and Keranen, A., "Terminology for
Constrained-Node Networks", RFC 7228, May 2014.
Authors' Addresses
Ludwig Seitz
SICS Swedish ICT AB
Scheelevagen 17
22370 Lund
SWEDEN
EMail: ludwig@sics.se
Goeran Selander
Ericsson
Farogatan 6
16480 Kista
SWEDEN
EMail: goran.selander@ericsson.com
Seitz & Selander Expires November 17, 2014 [Page 14]