Internet DRAFT - draft-zhu-ace-offline

draft-zhu-ace-offline







ACE Working Group                                                 J. Zhu
Internet-Draft                                                    Huawei
Intended status: Informational                            March 13, 2017
Expires: September 14, 2017


                          Offline usage of ACE
                        draft-zhu-ace-offline-00

Abstract

   [I-D.ietf-ace-oauth-authz] defines a framework for both
   authentication and authorization in constrained Internet of Things
   (IoT) environments.  A constrained node in this framework may have
   constraints in computational capability, memory storage, lack of user
   interface, transmission bandwidth and/or power supply.  Battery-
   powered devices are widely used in IoT deployments and they sleep
   most of their lifetime for battery saving.  Hence, they are usually
   disconnected from other nodes.  This draft provides an overview of
   the disconnection use cases and discusses offline authentication and
   authorization solutions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Zhu                    Expires September 14, 2017               [Page 1]

Internet-Draft                 ACE Offline                    March 2017


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Case 1 Client-AS disconnection  . . . . . . . . . . . . .   5
       3.1.1.  Sub-case 1 Client instructs the RS to obtain
               authorization information from AS . . . . . . . . . .   5
       3.1.2.  Sub-case 2 Introspection Aided Token Validation . . .   7
       3.1.3.  Sub-case 3 RS caches authorization information  . . .   7
     3.2.  RS-AS disconnection . . . . . . . . . . . . . . . . . . .   7
       3.2.1.  Sub-case 1: Local Token Validation  . . . . . . . . .   7
     3.3.  Client-RS disconnection . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   [I-D.ietf-ace-oauth-authz] defines a framework for both
   authentication and authorization in constrained Internet of Things
   (IoT) environments.  The framework is based on a set of building
   blocks including OAuth 2.0 and CoAP.
   Figure 1/[I-D.ietf-ace-oauth-authz] describes the basic ACE protocol
   flow.  The diagram is repeated below.















Zhu                    Expires September 14, 2017               [Page 2]

Internet-Draft                 ACE Offline                    March 2017


      +--------+                               +---------------+
      |        |---(A)-- Token Request ------->|               |
      |        |                               | Authorization |
      |        |<--(B)-- Access Token ---------|    Server     |
      |        |       + RS Information        |               |
      |        |                               +---------------+
      |        |                                      ^ |
      |        |            Introspection Request  (D)| |
      | Client |                                      | |
      |        |             Response + Client Token  | |(E)
      |        |                                      | v
      |        |                               +--------------+
      |        |---(C)-- Token + Request ----->|              |
      |        |                               |   Resource   |
      |        |<--(F)-- Protected Resource ---|    Server    |
      |        |                               |              |
      +--------+                               +--------------+

                       Figure 1: Basic Protocol Flow

   (A) The client makes an access token request to the /token endpoint
   at the Authorization Server (AS).

   (B) The AS successfully processes the request from the client, then
   returns an access token and some RS information.

   (C) The client interacts with the resource server (RS) to request
   access to the protected resource and provides the access token.

   (D) The RS may make an introspection request to the /introspect
   endpoint at the AS to get more information about the access token.

   (E) The AS validates the token and returns the most recent parameters
   associated with it back to the RS.

   (F) The RS uses the token information to process the resource access
   request and returns the protected resources back to the client.

   Note: Step D and E are optional steps as the RS can process the
   access token information locally depending on the deployment
   configurations.

   There may be many constraints for a constrained IoT device such as
   limited computational capability, memory storage, lack of user
   interface, transmission bandwidth and/or power supply.  According to
   the [I-D.ietf-ace-actors], either the client or the RS MAY be a
   constrained node.  One critical issue for IoT ecosystems is that more
   and more constrained devices are battery-powered, e.g. smart water



Zhu                    Expires September 14, 2017               [Page 3]

Internet-Draft                 ACE Offline                    March 2017


   meters.  These battery-powered constrained devices sleep most of
   their lifetime to save power.  What's more, in deployments the
   underlying network between different nodes may vary from cellular to
   WLAN even NFC.  That means any two nodes of the ACE framework may be
   disconnected from each other.

   As a result of Figure 1, there are 3 different possible disconnection
   cases between the nodes in the ACE framework:

   1.  Client-AS disconnection

   2.  RS-AS disconnection

   3.  Client-RS disconnection

   This document provides an overview of these cases and discusses
   offline authentication and authorization solutions based on the ACE
   framework for each of the cases.

   The cases discussed in this document utilise the A to F designations
   from Figure 1 to maintain a relation to the functional steps.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this specification are to be interpreted as described
   in [RFC2119].

   This specification requires readers to be familiar with all the terms
   and concepts that are discussed in [I-D.ietf-ace-oauth-authz] and
   [RFC7252].

3.  Cases

   This section discusses the disconnection cases including:

   1.  Client-AS disconnection

   2.  RS-AS disconnection

   3.  Client-RS disconnection

   Each of the cases may have one or more sub-cases.

   For each case there is a brief description at the beginning, and then
   a possible solution for the disconnection case is discussed.




Zhu                    Expires September 14, 2017               [Page 4]

Internet-Draft                 ACE Offline                    March 2017


3.1.  Case 1 Client-AS disconnection

   In this case we consider the case where the Client is disconnected
   from the Authorization Server when the Client wants to access a
   resource on the Resource Server.  This usually happens when the
   network between client and AS goes down, but the client can
   communicate with the RS via another network.

3.1.1.  Sub-case 1 Client instructs the RS to obtain authorization
        information from AS

   This example shows the interaction between a remote controller
   (Client), a smart television (RS) and a Hub (AS).  The remote
   controller is disconnected from the AS because its WIFI function
   doesn't work well.  However it can communicate with the smart TV via
   Bluetooth.

   This access procedure involves all the steps shown in Figure 1.  In
   this case, it is assumed that there is a DTLS connection between the
   client and RS and a separate DTLS connection between the RS and AS.

   The client firstly tries to turn on the RS without any authorization
   information.

   C: The client sends a request message to the RS in order to change
   the state of the switch.  However this message does not contain any
   authorization information.

   F: After receiving the request message, the RS verifies it and sends
   an authorization verification failure response back to the client.
   The payload of the response MAY contain the AS information in order
   to instruct the client to obtain an access token from the right
   address.

   Messages C and F is shown in Figure 2.
















Zhu                    Expires September 14, 2017               [Page 5]

Internet-Draft                 ACE Offline                    March 2017


                 Resource
        Client    Server
          |         |
          |         |
      C:  +-------->| Header: PUT (T=CON, Code=0.03)
          |   PUT   | Uri-Path: switch
          |         | Payload: 1 (On)
          |         |
          |         |
      F:  |<--------+ Header: 4.01 Unauthorized
          |   4.01  |
          |         |

                      Figure 2: Authorization Failure

   After receiving the unauthorized failure message from the RS, the
   client then tries to request an access token from the AS.

   A: The client sends an authorization request to the AS.

   B: Because the client is disconnected from the AS, the access token
   request does not receive a response from the AS and the request times
   out.

   Message A and B are shown in Figure 3.

               Authorization
        Client    Server
          |         |
          |X=======X| Client is disconnected from AS
          |         |
          |         |
      A:  +-------X | Header: POST (T=CON, Code=0.02)
          |  POST   | Uri-Path: token
          |         | Payload: client_credentials
          |         |
      B:  | TIMEOUT |
          |         |

                      Figure 3: Authorization Timeout

   Question: Would it be possible to use the resource server as a proxy
   to get the authorization information?








Zhu                    Expires September 14, 2017               [Page 6]

Internet-Draft                 ACE Offline                    March 2017


3.1.2.  Sub-case 2 Introspection Aided Token Validation

   In this scenario we consider the same example shown in Section 3.1.1.
   The difference is that the client has previously (when it could
   communicate with the AS) received a pre-provisioned long-lived access
   token before it went offline.  The RS uses its online connectivity to
   validate the access token with the AS.

   Note: This is the same use case as the example described in section
   E.2 of [I-D.ietf-ace-oauth-authz].

3.1.3.  Sub-case 3 RS caches authorization information

   In this section we consider the same case mentioned in Section 3.1.1.

   It is assumed the client can communicate with the AS over a DTLS
   channel before it goes offline.  A DTLS channel is also established
   between AS and RS as well as a separate channel between the client
   and RS.

   The RS has the capability to cache client authorization information.

   Question: Would it be acceptable for the RS to have its cache managed
   by the client?

3.2.  RS-AS disconnection

3.2.1.  Sub-case 1: Local Token Validation

   In this scenario we consider the case where the resource server is
   offline, i.e. it is not connected to the AS at the time of the access
   request.  This access procedure involves steps A, B, C, and F of
   Figure 1.

   Since the resource server must be able to verify the access token
   locally, self-contained access tokens must be used.

   Note: This case is the same as the example described in section E.1
   of [I-D.ietf-ace-oauth-authz].

3.3.  Client-RS disconnection

   In this scenario we consider the case where the client is
   disconnected from resource server at the time of the access request.
   For example, both a mobile phone (Client) and a thermostat(RS) are
   connecting to a same cloud server(AS).  The phone has no connection
   to the thermostat, but the AS should provide a mechanism for the




Zhu                    Expires September 14, 2017               [Page 7]

Internet-Draft                 ACE Offline                    March 2017


   client to query the temperature remotely.  This access procedure
   involves steps A, B, D, and E of Figure 1 as shown below.

      +--------+         +---------------+         +----------+
      | Client |---(A)-->| Authorization |---(E)-->| Resource |
      |        |<--(B)---|    Server     |<--(D)---|  Server  |
      +--------+         +---------------+         +----------+

                     Figure 4: Client-RS disconnection

   In this case, it is assumed that a DTLS channel is established
   between the client & AS, and a separate DTLS connection between the
   AS & RS as well.  The AS SHOULD act as proxy and can forward the
   resource access request by the client to the RS.  The client prior to
   sending a message to the AS, tried to access the resource directly.
   However it did not get a successful response due to disconnection
   between these two nodes.  So the client then tries to access the
   resource via the AS.

   Question: Would it be acceptable for the AS to act as a proxy for
   requests to the RS?

4.  Security Considerations

   This document addresses authorised access to resources in device
   disconnection scenarios.

5.  IANA Considerations

   TBD.

6.  Acknowledgements

   TBD.

7.  Changelog

   Initial version

8.  References

8.1.  Normative References

   [I-D.ietf-ace-actors]
              Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An
              architecture for authorization in constrained
              environments", draft-ietf-ace-actors-05 (work in
              progress), March 2017.



Zhu                    Expires September 14, 2017               [Page 8]

Internet-Draft                 ACE Offline                    March 2017


   [I-D.ietf-ace-oauth-authz]
              Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
              H. Tschofenig, "Authentication and Authorization for
              Constrained Environments (ACE)", draft-ietf-ace-oauth-
              authz-05 (work in progress), February 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

Author's Address

   Jintao Zhu
   Huawei
   P.R.China

   Email: jintao.zhu@huawei.com


























Zhu                    Expires September 14, 2017               [Page 9]