draft-ietf-ace-actors-03.txt   draft-ietf-ace-actors-04.txt 
ACE Working Group S. Gerdes ACE Working Group S. Gerdes
Internet-Draft Universitaet Bremen TZI Internet-Draft Universitaet Bremen TZI
Intended status: Informational L. Seitz Intended status: Informational L. Seitz
Expires: September 2, 2016 SICS Swedish ICT AB Expires: March 4, 2017 SICS Swedish ICT AB
G. Selander G. Selander
Ericsson Ericsson
C. Bormann, Ed. C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
March 01, 2016 August 31, 2016
An architecture for authorization in constrained environments An architecture for authorization in constrained environments
draft-ietf-ace-actors-03 draft-ietf-ace-actors-04
Abstract Abstract
Constrained-node networks are networks where some nodes have severe Constrained-node networks are networks where some nodes have severe
constraints on code size, state memory, processing capabilities, user constraints on code size, state memory, processing capabilities, user
interface, power and communication bandwidth (RFC 7228). interface, power and communication bandwidth (RFC 7228).
This document provides terminology, and identifies the elements that This document provides terminology, and identifies the elements that
an architecture needs to address, providing a problem statement, for an architecture needs to address, providing a problem statement, for
authentication and authorization in these networks. authentication and authorization in these networks.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2016. This Internet-Draft will expire on March 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24 8.3. Authentication . . . . . . . . . . . . . . . . . . . . . 24
8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24 8.4. Server-side Authorization . . . . . . . . . . . . . . . . 24
8.5. Client-side Authorization Information . . . . . . . . . . 25 8.5. Client-side Authorization Information . . . . . . . . . . 25
8.6. Server-side Authorization Information . . . . . . . . . . 25 8.6. Server-side Authorization Information . . . . . . . . . . 25
8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26 8.7. Resource Access . . . . . . . . . . . . . . . . . . . . . 26
8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26 8.8. Keys and Cipher Suites . . . . . . . . . . . . . . . . . 26
8.9. Network Considerations . . . . . . . . . . . . . . . . . 26 8.9. Network Considerations . . . . . . . . . . . . . . . . . 26
8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27 8.10. Legacy Considerations . . . . . . . . . . . . . . . . . . 27
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27 9.1. Physical Attacks on Sensor and Actuator Networks . . . . 27
9.2. Time Measurements . . . . . . . . . . . . . . . . . . . . 29 9.2. Clocks and Time Measurements . . . . . . . . . . . . . . 29
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. Informative References . . . . . . . . . . . . . . . . . . . 29 12. Informative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Constrained nodes are small devices with limited abilities which in Constrained nodes are small devices with limited abilities which in
many cases are made to fulfill a specific simple task. They have many cases are made to fulfill a specific simple task. They have
limited hardware resources such as processing power, memory, non- limited hardware resources such as processing power, memory, non-
volatile storage and transmission capacity and additionally in most volatile storage and transmission capacity and additionally in most
cases do not have user interfaces and displays. Due to these cases do not have user interfaces and displays. Due to these
constraints, commonly used security protocols are not always easily constraints, commonly used security protocols are not always easily
applicable. applicable.
skipping to change at page 4, line 23 skipping to change at page 4, line 23
is.) is.)
We therefore group the logical functional entities by whether they We therefore group the logical functional entities by whether they
can be assigned to a constrained device ("constrained level") or need can be assigned to a constrained device ("constrained level") or need
higher function platforms ("less-constrained level"); the latter does higher function platforms ("less-constrained level"); the latter does
not necessarily mean high-function, "server" or "cloud" platforms. not necessarily mean high-function, "server" or "cloud" platforms.
Note that assigning a logical functional entity to the constrained Note that assigning a logical functional entity to the constrained
level does not mean that the specific implementation needs to be level does not mean that the specific implementation needs to be
constrained, only that it _can_ be. constrained, only that it _can_ be.
The description assumes that some form of setup (aspects of which are
often called provisioning and/or commissioning) has already been
performed and at least some initial security relationships important
for making the system operational have already been established.
This document provides some terminology, and identifies the elements This document provides some terminology, and identifies the elements
an architecture needs to address, representing the relationships an architecture needs to address, representing the relationships
between the logical functional entities involved; on this basis, a between the logical functional entities involved; on this basis, a
problem description for authentication and authorization in problem description for authentication and authorization in
constrained-node networks is provided. constrained-node networks is provided.
1.1. Terminology 1.1. Terminology
Readers are required to be familiar with the terms and concepts Readers are required to be familiar with the terms and concepts
defined in [RFC4949], including "authentication", "authorization", defined in [RFC4949], including "authentication", "authorization",
skipping to change at page 11, line 8 skipping to change at page 11, line 8
V V V V
------- ------- ------- -------
| C | -- requests resource --> | RS | Constrained Level | C | -- requests resource --> | RS | Constrained Level
------- <-- provides resource -- ------- ------- <-- provides resource -- -------
Figure 6: CAS combined with AS Figure 6: CAS combined with AS
2.3. Information Flows 2.3. Information Flows
We now formulate the problem statement in terms of the information We now formulate the problem statement in terms of the information
flows the architecture focuses on. flows the architecture focuses on. (While the previous section
discusses the architecture in terms of abstract devices and their
varying roles, the actual protocols being standardized define those
information flows and the messages embodying them: "RESTful
architectures focus on defining interfaces and not components"
([REST], p. 116).)
The interaction with the nodes on the principal level, RO and RqP, is The interaction with the nodes on the principal level, RO and RqP, is
not involving constrained nodes and therefore can employ an existing not involving constrained nodes and therefore can employ an existing
mechanism. The less-constrained nodes, CAS and AS, support the mechanism. The less-constrained nodes, CAS and AS, support the
constrained nodes, C and RS, with control information, for example constrained nodes, C and RS, with control information, for example
permissions of clients, conditions on resources, attributes of client permissions of clients, conditions on resources, attributes of client
and resource servers, keys and credentials. This control information and resource servers, keys and credentials. This control information
may be rather different for C and RS, reflecting the intrinsic may be rather different for C and RS, reflecting the intrinsic
asymmetry with C initiating the request for access to a resource, and asymmetry with C initiating the request for access to a resource, and
RS acting on a received request, and C finally acting on the received RS acting on a received request, and C finally acting on the received
skipping to change at page 21, line 11 skipping to change at page 21, line 15
o RS needs to authenticate AS, and C needs to authenticate CAS, to o RS needs to authenticate AS, and C needs to authenticate CAS, to
ensure that the authorization information and related data comes ensure that the authorization information and related data comes
from the correct source. from the correct source.
o CAS and AS may need to authenticate each other, both to perform o CAS and AS may need to authenticate each other, both to perform
the required business logic and to ensure that CAS gets security the required business logic and to ensure that CAS gets security
information related to the resources from the right source. information related to the resources from the right source.
o In some use cases RS needs to authenticate some property of C, in o In some use cases RS needs to authenticate some property of C, in
order to map it to the relevant authorization information. In order to map it to the relevant authorization information. In
other use cases, authentication and authorization of C may be other applications, authentication and authorization of C may be
implicit, for example by encrypting the resource representation implicit, for example by encrypting the resource representation
the RS only providing access to those who possess the key to the RS only providing access to those who possess the key to
decrypt. decrypt.
o C may need to authenticate RS, in order to ensure that it is o C may need to authenticate RS, in order to ensure that it is
interacting with the right resources. Alternatively C may just interacting with the right resources. Alternatively C may just
verify the integrity of a received resource representation. verify the integrity of a received resource representation.
o CAS and AS need to authenticate their communication partner (C or o CAS and AS need to authenticate their communication partner (C or
RS), in order to ensure it serves the correct device. RS), in order to ensure it serves the correct device.
skipping to change at page 24, line 21 skipping to change at page 24, line 24
and memory overheads in the context of constrained devices. and memory overheads in the context of constrained devices.
* The RAM requirements of DTLS handshakes with public key * The RAM requirements of DTLS handshakes with public key
cryptography are prohibitive for certain constrained devices. cryptography are prohibitive for certain constrained devices.
* Certificate-based DTLS handshakes require significant volumes * Certificate-based DTLS handshakes require significant volumes
of communication, RAM (message buffers) and computation. of communication, RAM (message buffers) and computation.
o A solution will need to consider support for a simple scheme for o A solution will need to consider support for a simple scheme for
expiring authentication and authorization information on devices expiring authentication and authorization information on devices
which are unable to measure time (cf. section Section 9.2). which are unable to measure time (cf. Section 9.2).
8.3. Authentication 8.3. Authentication
o RS needs to authenticate AS to ensure that the authorization o RS needs to authenticate AS to ensure that the authorization
information and related data comes from the correct source. information and related data comes from the correct source.
o Similarly, C needs to authenticate CAS to ensure that the o Similarly, C needs to authenticate CAS to ensure that the
authorization information and related data comes from the correct authorization information and related data comes from the correct
source. source.
skipping to change at page 29, line 5 skipping to change at page 29, line 5
Since it does not make sense to design a solution for a situation 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 that cannot be protected against we assume there is no need to
protect assets which are exposed during a physical attack. In protect assets which are exposed during a physical attack. In
other words, either an attacker does not have physical access to other words, either an attacker does not have physical access to
the sensor or actuator device, or if it has, the attack shall only the sensor or actuator device, or if it has, the attack shall only
have effect during the period of physical attack, and shall be have effect during the period of physical attack, and shall be
limited in extent to the physical control the attacker exerts limited in extent to the physical control the attacker exerts
(e.g., must not affect the security of other devices.) (e.g., must not affect the security of other devices.)
9.2. Time Measurements 9.2. Clocks and Time Measurements
Measuring time with certain accuracy is important to achieve certain Measuring time and keeping wall-clock time with certain accuracy is
security properties, for example to determine whether a public key important to achieve certain security properties, for example to
certificate, access token or some other assertion is valid. determine whether a public key certificate, access token, or some
other assertion, is valid.
Dynamic authorization in itself requires the ability to handle expiry Dynamic authorization in itself requires the ability to handle expiry
or revocation of authorization decisions or to distinguish new or revocation of authorization decisions or to distinguish new
authorization decisions from old. authorization decisions from old.
For certain categories of devices we can assume that there is an For certain categories of devices we can assume that there is an
internal clock which is sufficiently accurate to handle the time internal clock which is sufficiently accurate to handle the time
measurement requirements. If RS can connect directly to AS it could measurement requirements. If RS can connect directly to AS, this
get updated in terms of time as well as revocation information. relationship can be used to update RS in terms of time, removing some
uncertainty, as well as to directly provide revocation information,
removing authorizations that are no longer desired.
If RS continuously measures time but can't connect to AS or other If RS continuously measures time but can't connect to AS or another
trusted source, time drift may have to be accepted and it may not be trusted source of time, time drift may have to be accepted and it may
able to manage revocation. However, it may still be able to handle be harder to manage revocation. However, it may still be able to
short lived access rights within some margins, by measuring the time handle short lived access rights within some margins, by measuring
since arrival of authorization information or request. the time since arrival of authorization information or request.
Some categories of devices in scope may be unable measure time with Some categories of devices in scope may be unable measure time with
any accuracy (e.g. because of sleep cycles). This category of any accuracy (e.g. because of sleep cycles). This category of
devices is not suitable for the use cases which require measuring devices is not suitable for the use cases which require measuring
validity of assertions and authorizations in terms of absolute time. validity of assertions and authorizations in terms of absolute time.
10. IANA Considerations 10. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 30, line 25 skipping to change at page 30, line 32
[I-D.hardjono-oauth-umacore] [I-D.hardjono-oauth-umacore]
Hardjono, T., Maler, E., Machulak, M., and D. Catalano, Hardjono, T., Maler, E., Machulak, M., and D. Catalano,
"User-Managed Access (UMA) Profile of OAuth 2.0", draft- "User-Managed Access (UMA) Profile of OAuth 2.0", draft-
hardjono-oauth-umacore-14 (work in progress), January hardjono-oauth-umacore-14 (work in progress), January
2016. 2016.
[I-D.koster-core-coap-pubsub] [I-D.koster-core-coap-pubsub]
Koster, M., Keranen, A., and J. Jimenez, "Publish- Koster, M., Keranen, A., and J. Jimenez, "Publish-
Subscribe Broker for the Constrained Application Protocol Subscribe Broker for the Constrained Application Protocol
(CoAP)", draft-koster-core-coap-pubsub-04 (work in (CoAP)", draft-koster-core-coap-pubsub-05 (work in
progress), November 2015. progress), July 2016.
[I-D.selander-ace-object-security] [I-D.selander-ace-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security of CoAP (OSCOAP)", draft-selander-ace- "Object Security of CoAP (OSCOAP)", draft-selander-ace-
object-security-03 (work in progress), October 2015. object-security-05 (work in progress), July 2016.
[OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A., [OSCAR] Vucinic, M., Tourancheau, B., Rousseau, F., Duda, A.,
Damon, L., and R. Guizzetti, "OSCAR: Object Security Damon, L., and R. Guizzetti, "OSCAR: Object Security
Architecture for the Internet of Things", CoRR vol. Architecture for the Internet of Things", CoRR vol.
abs/1404.7799, 2014. abs/1404.7799, 2014.
[REST] Fielding, R. and R. Taylor, "Principled design of the
modern Web architecture", ACM Trans. Inter. Tech. Vol.
2(2), pp. 115-150, DOI 10.1145/514183.514185, May 2002.
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., [RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L.,
Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and
D. Spence, "AAA Authorization Framework", RFC 2904, DOI D. Spence, "AAA Authorization Framework", RFC 2904,
10.17487/RFC2904, August 2000, DOI 10.17487/RFC2904, August 2000,
<http://www.rfc-editor.org/info/rfc2904>. <http://www.rfc-editor.org/info/rfc2904>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
DOI 10.17487/RFC4120, July 2005, DOI 10.17487/RFC4120, July 2005,
<http://www.rfc-editor.org/info/rfc4120>. <http://www.rfc-editor.org/info/rfc4120>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246,
RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <http://www.rfc-editor.org/info/rfc6749>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, DOI 10.17487/ Constrained-Node Networks", RFC 7228,
RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>. <http://www.rfc-editor.org/info/rfc7228>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC Protocol (HTTP/1.1): Message Syntax and Routing",
7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>. <http://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252,
RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>. <http://www.rfc-editor.org/info/rfc7252>.
[RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M., [RFC7744] Seitz, L., Ed., Gerdes, S., Ed., Selander, G., Mani, M.,
and S. Kumar, "Use Cases for Authentication and and S. Kumar, "Use Cases for Authentication and
Authorization in Constrained Environments", RFC 7744, DOI Authorization in Constrained Environments", RFC 7744,
10.17487/RFC7744, January 2016, DOI 10.17487/RFC7744, January 2016,
<http://www.rfc-editor.org/info/rfc7744>. <http://www.rfc-editor.org/info/rfc7744>.
Authors' Addresses Authors' Addresses
Stefanie Gerdes Stefanie Gerdes
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63906 Phone: +49-421-218-63906
Email: gerdes@tzi.org Email: gerdes@tzi.org
Ludwig Seitz Ludwig Seitz
 End of changes. 26 change blocks. 
39 lines changed or deleted 57 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/