Internet DRAFT - draft-secheverria-ace-client-disadvantaged
draft-secheverria-ace-client-disadvantaged
Network Working Group S. Echeverria
Internet-Draft CMU SEI
Intended status: Informational L. Seitz
Expires: September 9, 2019 RISE
D. Klinedinst
G. Lewis
CMU SEI
March 8, 2019
ACE Clients in Disadvantaged Networks
draft-secheverria-ace-client-disadvantaged-00
Abstract
This document describes a set of recommendations to use when
implementing ACE/OAuth 2.0 clients that are working in disadvantaged
networks. Issues such as token revocation have a much higher
priority in scenarios where Resource Servers are IoT devices, and
network connectivity is limited and intermittent.
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 https://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 9, 2019.
Copyright Notice
Copyright (c) 2019 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
(https://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
Echeverria, et al. Expires September 9, 2019 [Page 1]
Internet-Draft DIL ACE Clients March 2019
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. Sample Scenario . . . . . . . . . . . . . . . . . . . . . . . 3
3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Use of Client Introspection for Token Revocation . . . . 3
3.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2. Specific Recommendations . . . . . . . . . . . . . . 4
3.1.3. Alternatives . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Authentication and authorization in IoT (Internet of Things) devices
can be difficult due to constraints in terms of memory, processing,
user interface, power and communication bandwidth. OAuth 2.0 and
derived standards, such as ACE, can be still applied to these
scenarios, often with some modifications. However, when IoT devices
are working in disadvantaged networks, there are even greater
constraints in terms of communication bandwidth. Nodes in
disadvantaged networks operate in what are called DIL environments
(disconnected, intermittent, limited), which means that there is
limited and unreliable connectivity between nodes with potentially
periods of full disconnection. This document will focus on practices
that are recommended for clients using ACE/OAuth 2.0 while working
with IoT devices in disadvantaged networks.
There are cases in which a client may need to obtain further
information about a token without communicating with a Resource
Server (RS). One such case is when a client needs to know the active
status of a token that it possesses. This is particularly useful in
disadvantaged environments where RS impersonation and sabotage are
likely threats.
Section 2 describes a sample scenario and Section 3 describes
recommendations for client implementation, including the use of
client introspection: ensuring only authorized clients can perform
client introspection, enabling decryption of self-contained tokens,
and limiting information returned in the introspection response.
Echeverria, et al. Expires September 9, 2019 [Page 2]
Internet-Draft DIL ACE Clients March 2019
2. Sample Scenario
A sample scenario is the following: let's assume we have IoT devices
that are deployed over a large area to monitor it after an
earthquake. These IoT devices may be small sensors of different
types (temperature, motion detectors, etc.) that are constantly
collecting information from their environment. Each of these IoT
devices will act as an RS, and we want to be able to give
authorization to access their resources to mobile clients. The
Authorization Server (AS) will be mostly static, or slow moving; it
could be deployed in a nearby building, or carried along in vehicles
if there is no central location. Clients would most likely be
smartphones or tablets, carried by users in the field. Due to the
mobility of the clients and the large area over which the RSs are
deployed, clients would only intermittently have connectivity to both
the AS and to each RS. Clients would ask the AS for access tokens
when they are in range of the AS, and use the tokens to get
information from the RSs when they are in range of the IoT devices.
In this situation, being opportunistic about what to do when a client
gets in range of an AS is an important thing to consider. It is also
highly likely that clients or RSs may be impersonated or sabotaged.
This makes it a high priority to identify tokens associated to a
compromised RS or sent to a compromised client.
A specific situation for this would be if the AS admin learns that a
certain RS has been compromised. The AS does not have constant
connectivity to clients, so it can't let them know right away about
the issue. However, it wants to prevent all clients that had tokens
to communicate with that RS that they should no longer use those
tokens. The AS admin can manually mark all tokens issued to that RS
as an audience as revoked (internally). However, a means to let
clients know about the revocation of their tokens would be needed.
3. Recommendations
3.1. Use of Client Introspection for Token Revocation
3.1.1. Procedure
One way to let clients know when a token has been revoked is to
extend the existing protocol to add specific messages to handle this.
But an alternative, simpler way would be to use client introspection.
The end goal is to be able to revoke tokens for a RS that has been
compromised, by letting clients poll information about the tokens,
and then letting them know that they have been revoked.
Echeverria, et al. Expires September 9, 2019 [Page 3]
Internet-Draft DIL ACE Clients March 2019
A client can opportunistically poll an AS using the same
introspection mechanism defined in the OAuth 2.0 Token Introspection
RFC [RFC7662], to obtain information on whether a specific token is
still valid or not. That RFC defines a method for querying an
Authorization Server (AS) for metadata about a token. The
introspection process focuses on how a Resource Server (RS) could
benefit from this information. This is because, in most cases, the
token is assumed to be opaque to the client, as it is intended to be
a secure way of sending information to a RS, without the client being
able to modify it.
This same mechanism can be used to detect revoked tokens
opportunistically whenever a client gets in range of an AS. It
should work in the following way:
1- A client that gets in range of the AS, uses that opportunity to
contact the AS and to ask it about the state of its non-expired
tokens. More specifically, it sends a client introspection request
for each of the non-expired tokens it is using.
2- The AS replies to the client with information about whether each
token is "active" or not. For every token that has been revoked, it
returns that the token is not active.
3- The client receives the response and purges non-active tokens from
its list of tokens.
Thus the client will be protected from contacting the compromised RS.
Of course, this does not prevent the client from contacting the RS
before it can access the AS and ask about the tokens, but there is
not much that can be done about it until the client is able to
communicate with the AS.
3.1.2. Specific Recommendations
The following recommendations are useful to consider when
implementing client introspection:
1- The AS should have a way to limit which clients are allowed to
send introspection requests. This ensures that only clients that
really do need the information are allowed access to it.
2- The "kid" header parameter as defined in [RFC7519] and [RFC8152]
should be used when the token is encrypted in a structured
information object such as a JSON Web Token (JWT) [RFC7519] or CBOR
Web Token (CWT) [RFC8392]. The AS can store a key ID in this header
that can be associated with the RS key used during encrypted token
creation. If the AS does this when generating every encrypted token,
Echeverria, et al. Expires September 9, 2019 [Page 4]
Internet-Draft DIL ACE Clients March 2019
then it should always be able to decrypt that token on an
introspection request coming from a client or from a RS.
This is needed because an encrypted token can only be decrypted if
the proper key is known. When an RS performs introspection, the AS
can use the identity of the RS as a hint to find the related key.
However, if a client is performing the introspection request, the AS
receiving the request needs more information to know what audience
the encrypted token was issued for in order to decrypt it properly.
3- Only the value of the "active" parameter should be returned for
introspection requests coming from clients. An introspection
response has several parameters, but all of them are optional except
for the "active" parameter. The "active" parameter can be used to
indicate that a token has been revoked, and does not provide any
information about the claims, which the client should usually not
need. This prevents the disclosure of additional information to the
client.
3.1.3. Alternatives
An alternative way to handle token revocation would be to prevent the
AS from issuing more tokens for the same RS/audience, and for the
client to request a new token each time it is in range of the AS. In
this case, tokens would not be revoked, but rather clients would be
implicitly notified to no longer contact a specific RS. However,
this has at least two downsides. First, a client would have to
request a new token each time it is in range of an AS, constantly, to
be able to detect token revocation by getting the token request to be
denied. This could lead to many tokens issued to the same client and
for the same RS in a short period of time, which may not be even used
in that timeframe. In addition, this generates additional traffic in
an already constrained network. Second, client would be interpreting
a denial to issue a token from an AS as a warning not to contact that
RS anymore. This could lead the client to dump a previous token that
it has for that RS, to prevent potentially dangerous contact with it.
However, the denial may be for other reasons, but there is no way to
differentiate when denying a token request to a client. Thus, a
client may end up dumping working tokens because of a potentially
different issue with new token generation. In summary, this option
depends on the client making too many assumptions to successfuly
prevent it from accessing a compromised RS. Using client
introspection to detect revoked tokens is a much simpler and direct
way of handling this issue.
Another similar alternative to revoking tokens is to issue tokens
with very short lifetimes. In this case, even if a device having a
token is compromised, the short lifetime will make that token expire
Echeverria, et al. Expires September 9, 2019 [Page 5]
Internet-Draft DIL ACE Clients March 2019
quickly, making revocation notifications unnecessary. The main
problem with this option in disadvantaged networks is that clients
will not often be in range of the AS that issues the tokens or of the
RS they want to use the token with. Thus, if tokens have very short
lifetimes, they may not last long enough for a client to actually
send that token to the RS it needs to contact. Or even if it does,
if the token expires shortly afterwards, the client will not be able
to contact that or other RS in the same audience again until it comes
in range of the AS to obtain a new token. Thus, in this type of
environments, the lifetime of a token must be carefully balanced in
relation to its intended use and the frequency the devices will be in
range of each other.
4. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
There are some potential security issues with the recommendations
described in this document. Because the AS would accept
introspection requests from a client, claim information associated to
the tokens and not intended for a client could be sent back to it in
a response. The recommendations above explicitly indicate to only
send the "active" parameter as the response to this type of request,
but it is still up to the implementation to do this properly, and to
properly identify a device as a client (or more specifically as a
device to send limited information to in a reply). If this is
properly done, compromised or rogue clients sending introspection
requests would not be able to obtain more information than the token
active status from these types of introspection requests.
6. Acknowledgements
7. Normative References
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015,
<https://www.rfc-editor.org/info/rfc7662>.
Echeverria, et al. Expires September 9, 2019 [Page 6]
Internet-Draft DIL ACE Clients March 2019
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
Authors' Addresses
Sebastian Echeverria
CMU SEI
Ludwig Seitz
RISE
Dan Klinedinst
CMU SEI
Grace Lewis
CMU SEI
Echeverria, et al. Expires September 9, 2019 [Page 7]
