[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 draft-ietf-ace-actors

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/