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]
