Internet DRAFT - draft-greevenbosch-ace-comparison
draft-greevenbosch-ace-comparison
ACE B. Greevenbosch
Internet-Draft D. He
Intended status: Informational R. Sun
Expires: June 20, 2015 Huawei Technologies
December 17, 2014
Comparison of different proposals for ACE
draft-greevenbosch-ace-comparison-01
Abstract
This document investigates the different solutions in the ACE working
group. It highlights both similarities and differences. In
addition, it provides a security analysis for the different
solutions.
Note that the views and comments in this document are solely based on
its authors' interpretation, and do not necessarily represent the
opinions of the authors of the discussed 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 June 20, 2015.
Copyright 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
(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
Greevenbosch, et al. Expires June 20, 2015 [Page 1]
Internet-Draft ACE comparison December 2014
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.
Greevenbosch, et al. Expires June 20, 2015 [Page 2]
Internet-Draft ACE comparison December 2014
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proposals Comparison . . . . . . . . . . . . . . . . . . . . . 4
3.1. DCAF . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. CoAP server and CoAP client functionality . . . . . . 5
3.2.3. "AUTH" CoAP option . . . . . . . . . . . . . . . . . . 6
3.3. OAUTH . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. OAuth IoT . . . . . . . . . . . . . . . . . . . . . . 6
3.3.3. OAuth bearer token . . . . . . . . . . . . . . . . . . 7
3.3.4. OAuth introspection . . . . . . . . . . . . . . . . . 7
3.4. Two-way authentication for IoT (TWAI) . . . . . . . . . . 7
3.4.1. Basic authentication . . . . . . . . . . . . . . . . . 8
3.4.2. Authorization . . . . . . . . . . . . . . . . . . . . 8
3.5. Pull Model . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Comparison of the proposals . . . . . . . . . . . . . . . 9
3.6.1. Comparison table . . . . . . . . . . . . . . . . . . . 9
4. Architectural Models Comparison . . . . . . . . . . . . . . . 12
4.1. Push Model . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Brief Introduction . . . . . . . . . . . . . . . . . . 12
4.1.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Pull Model . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Brief Introduction . . . . . . . . . . . . . . . . . . 14
4.2.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Agent Model . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1. Brief Introduction . . . . . . . . . . . . . . . . . . 15
4.3.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Push/Confirm Model . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Brief Introduction . . . . . . . . . . . . . . . . . . 16
4.4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 17
4.5. Indirect Push Model . . . . . . . . . . . . . . . . . . . 17
4.5.1. Brief Introduction . . . . . . . . . . . . . . . . . . 17
4.5.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . 18
4.6. Recommendations . . . . . . . . . . . . . . . . . . . . . 19
5. Security considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Greevenbosch, et al. Expires June 20, 2015 [Page 3]
Internet-Draft ACE comparison December 2014
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
In the ACE working group, there are various proposals to resolve the
authentication and authorization issue. This document investigates
the different proposals, and compares their similarities and
differences.
The following proposals are investigated:
o DCAF
o EAP
o OAUTH
o Two-way authentication for IoT (TWAI)
o Pull Model (PULL)
In addition, this document compares different possible architectures,
and evaluates their advantages and disadvantages.
The views and comments in this document are solely based on its
authors' interpretation, and do not necessarily represent the
opinions of the authors of drafts for the discussed solutions.
3. Proposals Comparison
3.1. DCAF
3.1.1. Overview
The DCAF proposal is defined in [I-D.gerdes-ace-dcaf-authorize].
In the proposal, the client (C) and resource server (RS) want to
communicate securely. To setup a cryptographic channel, they need to
communicate with an Authorization Server (AS), which generates a
token with a secret to be used during the DTLS handshake.
C does not directly communicate with the AS, but uses an
Greevenbosch, et al. Expires June 20, 2015 [Page 4]
Internet-Draft ACE comparison December 2014
Authorization Manager (AM) as intermediary. The AM and AS
communicate through a secure channel, the nature of which is out of
scope. This AM extracts the key for the client and provides it to
the client through a secure channel. In addition, an access token
contains another copy of the key, but encrypted using a key shared
between AS and RS.
The access token format is specified. It signals permissions through
[I-D.bormann-core-ace-aif].
3.1.2. Scope
The following items are left out of scope of DCAF:
o Secure channel setup between AM and AS
o Shared secret exchange between AS and RS
3.2. EAP
3.2.1. Overview
The document [I-D.marin-ace-wg-coap-eap] defines an EAP [RFC3748]
authentication solution for CoAP. The EAP protocol is a framework
for authentication, allowing for customized solutions. Examples of
protocols using EAP include RADIUS [RFC2865] and Diameter [RFC6733].
The EAP solution includes a handshake between the EAP peer and the
EAP authenticator. In most cases, the EAP peer can be considered a
CoAP server, whereas the EAP authenticator is a CoAP client.
After the handshake, the EAP peer and EAP authenticator have a common
Master Session Key, which they can use to setup a DTLS connection or
for authentication for (as yet) unencrypted CoAP exchanges.
3.2.2. CoAP server and CoAP client functionality
Authentication could be started when the EAP peer and EAP
authenticator discover each other.
When starting the authentication, the EAP Peer sends a CoAP GET to
the EAP Authenticator, whereas in subsequent messages the EAP
Authenticator sends CoAP POST and PUT messages. This means that both
EAP Peer and EAP Authenticator need to implement both CoAP server and
CoAP client functionality.
It is, however, to note that the EAP Authenticator can initiate the
authentication by itself, in which case the client functionality is
Greevenbosch, et al. Expires June 20, 2015 [Page 5]
Internet-Draft ACE comparison December 2014
not required for the EAP peer.
An Authentication, Authorization and Accounting (AAA) server may be
deployed. Such AAA server is mentioned in [RFC3748], and both RADIUS
[RFC2865] and Diameter [RFC6733] define AAA servers. However, the
authorization in RADIUS and Diameter is not fine grained, it is a
simple all or nothing question. Thus, RADIUS and/or Diameter would
need adaptation to cater for CoAP specific requirements, or a new AAA
protocol may need to be defined.
3.2.3. "AUTH" CoAP option
The authentication allows the exchange of cryptographic material.
After authentication, this material is referred to using the new
"AUTH" CoAP option. This AUTH option is only used for integrity
protection of the related message, encryption is yet to be defined.
The EAP proposal mentions defining the cryptographic material needed
to setup an encrypted DTLS channel in a future version of the
proposal.
3.3. OAUTH
3.3.1. Overview
There are currently three documents that aim at adapting OAUTH v2.0
[RFC6749] for CoAP:
o [I-D.tschofenig-ace-oauth-iot] gives a general overview of how
OAuth 2.0 can be adopted to cater for the IOT.
o [I-D.tschofenig-ace-oauth-bt] defines how a bearer token can be
used in IoT.
o [I-D.wahlstroem-ace-oauth-introspection] defines a method for a
client or resource server to query an OAuth authorization server
to determine meta-information about an OAuth token using the CoAP
protocol.
3.3.2. OAuth IoT
The document [I-D.tschofenig-ace-oauth-iot] describes the
communication between the client and the authorization server. It is
to be noted that OAuth was originally designed for HTTP and hence
needs adaptations to cater for CoAP.
To obtain an access permission to a resource, the client first needs
to acquire an access token from the AS. This access token contains
Greevenbosch, et al. Expires June 20, 2015 [Page 6]
Internet-Draft ACE comparison December 2014
signalling of the Access Token Scope, which indicates which kind of
operations the Access Token enables. The Access Token Scope is
proprietary in OAuth, and hence would need to be defined for this
particular application.
The Access Token Request and Response are sent over DTLS. This means
that the client and AS must have a DTLS connection before exchange of
the Access Token can be achieved. Authentication of the client and
AS is considered part of the DTLS channel setup, and not further
specified.
The OAuth 2.0 specification leaves discovery of AS and registration
of the client with the AS out of scope. It does, however, require
verification of client credentials by the AS. In HTTP, such
credentials could consist of a password ([RFC6749], section 2.3.1).
It is currently unclear which key material is used to setup an
encrypted channel between client and RS.
3.3.3. OAuth bearer token
The document [I-D.tschofenig-ace-oauth-bt] defines how OAuth v2.0
Bearer Tokens from [RFC6750] can be used for CoAP. The Bearer Token
is used by the client to prove to the server that it has access
rights to certain resources. The server has to inspect the existence
and value of the Bearer Token, and return an error if the check
fails.
The Bearer Token is used as proof of the identity of the client to
the server, and hence needs to be kept secret to avoid spoofing.
3.3.4. OAuth introspection
The Access Token is associated with permissions for the client to
access a resource. However, the Access Token is an opaque string,
which is hard to interpret from the client or server side. Hence
there is a need for [I-D.wahlstroem-ace-oauth-introspection], which
allows the client to send the token to an Introspection Endpoint
(usually the AS), which acquires the metadata (such as access
permissions) for the token and sends it back to the client in JSON.
The document is based on [I-D.ietf-oauth-introspection], which
defines the same technology for standard, HTTP based, OAuth.
3.4. Two-way authentication for IoT (TWAI)
The document [I-D.schmitt-ace-twowayauth-for-iot] establishes a
framework for authentication and authorization, with the explicit
Greevenbosch, et al. Expires June 20, 2015 [Page 7]
Internet-Draft ACE comparison December 2014
goal of using existing and deployed standards where possible.
The document mentions both class 2 and class 1 devices (defined in
[I-D.bormann-lwig-terms]). The document wants to provide two
solutions for the two classes, but currently only defines the
solution for class 2, whereas the solution for class 1 is still to be
defined. There are, however, already some indications of adaptations
needed to make the class 2 solution work for class 1 devices.
3.4.1. Basic authentication
The basic solution for class 2 devices is standard authentication
during the DTLS handshake, based on X.509 certificates. For class 2,
the draft proposes to use RSA key pairs. Since an RSA public key
exceeds a kilobyte, the size is not considered viable for class 1
devices. Remember also that in CoAP, the recommended maximum message
size is around 1024 bytes to avoid fragmentation. The certificates
are exchanged in DTLS, not CoAP, but the fragmentation remains a
concern. Hence for class 1 devices, the draft proposes to use
Eliptic Curve Cryptography (ECC), although the details have not yet
been described.
The X.509 certificates are authenticated by a certificate authority,
either net-wide or domain-wide.
Parsing of X.509 certificates is difficult for constrained devices.
Not only would they need to parse ASN.1 data and verify a signatures
and a possible certificate chain, they also would need to contact an
OSCP responder or consult a CRL to verify revocation status of the
X.509 certificates. In addition, they need a secure time source to
verify that the X.509 certificate has not yet expired.
3.4.2. Authorization
The draft also describes an authorization architecture. The
architecture is based on four entities:
o Subscriber
o Access control server
o Gateway
o Publisher
The idea is that the publisher aggregates data of multiple sensors,
and provides it to possibly multiple subscribers.
Greevenbosch, et al. Expires June 20, 2015 [Page 8]
Internet-Draft ACE comparison December 2014
The access control server provides access control tickets, which are
separately delivered to the publisher and the subscribers, after
which they can perform standard two-way authentication and setup the
DTLS channel.
The definition of the ticket format and the messages between
subscriber, access control server and publisher is still to be done.
The publisher may delegate its security functionality to a gateway.
3.5. Pull Model
The document [I-D.greevenbosch-ace-pull-model] defines a solution
using a pull model. When the client wants to access a resource on
the RS, the RS asks the AS for authorization. The AS then grants or
refuses the authorization.
Since the RS talks directly to the AS, there is no need for the
client to communicate with the AS. Hence the AS can (but does not
have to) reside in a domain separated from the Client.
The authorization from the AS is signalled to the RS using an
authorization ticket. This ticket has the same format as as the
authorization ticket in DCAF. It can signal permissions on a per
resource and per action basis. The client is not presented with the
access ticket, the RS parses and interprets it by itself.
The communication between RS and AS, as well as between Client and
RS, is DTLS + CoAP.
3.6. Comparison of the proposals
3.6.1. Comparison table
The following provides a list comparing the different solutions. For
TWAI, we consider the access control server the equivalent to the AS,
and abbreviate it as such.
Registration between C and AS:
o DCAF: out of scope
o EAP: not applicable
o OAuth: out of scope
o TWAI: standard DTLS
o PULL: out of scope
Client credentials:
Greevenbosch, et al. Expires June 20, 2015 [Page 9]
Internet-Draft ACE comparison December 2014
o DCAF: through relationship with AM
o EAP: out of scope
o OAuth: out of scope
o TWAI: X.509 certificates
o PULL: out of scope
Revocation of client or server:
o DCAF: out of scope, but could be done by AM or AS (no new ticket)
o EAP: AAA server could refuse new authorization
o OAuth: could be done by AS (no new ticket)
o TWAI: not defined, but OSCP and CRL should be feasible
o PULL: can be done by AS (no access grant)
Client needs to verify certificates?
o DCAF: no - delegated to AM
o EAP: ?
o OAuth: yes, from AS
o TWAI: yes, from AS
o PULL: no - delegated to AM
Pre-shared key assumptions:
o DCAF: C and AM have a pre-shared key. RS and AS have a pre-shared
key.
o EAP: ?
o OAuth: ?
o TWAI: maybe between AS and publisher/gateway?
o PULL: RS and AS have a pre-shared key.
Discovery of AS:
o DCAF: RS informs C about AS when refusing an unauthorized response
from C.
o EAP: ?
o OAuth: Preconfigured
o TWAI: Out of scope
o PULL: Preconfigured, RS contacts AS directly
Protocol for exchange of authorization information:
o DCAF: between C and AM, and between C and RS: DTLS; between AM and
AS: proprietory.
o EAP: CoAP
o OAuth: between C and AS: CoAP+DTLS. Between C and RS: DTLS?
o TWAI: to be defined
o PULL: CoAP + DTLS
Definition of new CoAP option(s):
o DCAF: no
Greevenbosch, et al. Expires June 20, 2015 [Page 10]
Internet-Draft ACE comparison December 2014
o EAP: maybe, "AUTH"
o OAuth: yes, "Bearer" and "Error"
o TWAI: no
o PULL: re-uses new "Node-Id" option
Protocol for actual data exchange between C and RS:
o DCAF: DTLS + CoAP
o EAP: CoAP + EAP or DTLS + CoAP
o OAuth: DTLS + CoAP
o TWAI: DTLS + CoAP
o PULL: DTLS + CoAP
Object security or transport security:
o DCAF: transport security
o EAP: object security (with AUTH option) or transport security
(with DTLS)
o OAuth: transport security
o TWAI: transport security
o PULL: transport security
Level of authorization:
o DCAF: resource and method level
o EAP: All or nothing
o OAuth: Resource and method level possible, through definition of
Access Token Scope
o TWAI: Resource and method level at publisher
o PULL: resource and method level
Ticket format:
o DCAF: defined
o EAP: N.A.
o OAuth: needs definition
o TWAI: needs definition
o PULL: defined (same as DCAF)
Ticket lifetime:
o DCAF: limited
o EAP: diameter provides an AVP for authorization lifetime
o OAuth: limited
o TWAI: ?
o PULL: limited
Number of parties:
o DCAF: 3/4 (AM can be merged with client)
o EAP: 2/3 (depending on deployment of AAA server)
o OAuth: 3
Greevenbosch, et al. Expires June 20, 2015 [Page 11]
Internet-Draft ACE comparison December 2014
o TWAI: 4/5 (gateway and access control server could be combined)
o PULL: 3
4. Architectural Models Comparison
According to the uploaded drafts and previous discussions in IETF 89
Toronto F2F meeting, there are several possible architectural models
to achieve authorization in a constrained environment:
o Push model
o Pull model
o Agent model
o Push/Confirm model
o Indirect push model
This section provides an analysis of these models, discusses their
advantages and disadvantages, and gives some recommendations.
4.1. Push Model
4.1.1. Brief Introduction
The push model is described in [RFC2904] and proposed in the DCAF
draft ([I-D.gerdes-ace-dcaf-authorize]).
From high level point of view, it can be depicted as follows:
Greevenbosch, et al. Expires June 20, 2015 [Page 12]
Internet-Draft ACE comparison December 2014
+-------------------------+
+--------+ | Resource Domain |
| | 1 | +-------------------+ |
| |------------+->| Authorization | |
| |<-----------+--| Server | |
| | 2 | +-------------------+ |
| Client | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------------+->| Resource | |
| |<-----------+--| Server | |
| | 4 | +-------------------+ |
+--------+ | |
+-------------------------+
Figure 1: Push Model
To simplify the architectural model, the Authentication Manager is
combined with the client in this architecture diagram.
In this model, the high level flows are described as follows:
Step 1: the client sends a request to the Authorization Server to get
an access ticket for a specific resource access request.
Step 2: the Authorization Server sends the access ticket to the
client.
Step 3: the client sends the resource access request to the Resource
Server, containing the access ticket.
Step 4: the Resource Server verifies the access ticket and returns a
resource access response.
4.1.2. Analysis
Advantage: in the push model, the message transmission and processing
workload for the Resource Server is relatively low, and message
transmission and processing workload for the client is relatively
high. Since the Resource Server is usually the most constrained
device, this model is suitable for the constrained environment.
Disadvantage: in some use cases, the client may not be able to have a
connection with Authorization Server. Then this model is not
applicable. Also, a ticket revocation mechanism may be needed, for
example in case of a security breach or policy modification. If
there is no such mechanism, during the validity period of the ticket,
Greevenbosch, et al. Expires June 20, 2015 [Page 13]
Internet-Draft ACE comparison December 2014
the client is still able to access the resource in accordance to the
old policy.
4.2. Pull Model
4.2.1. Brief Introduction
The pull model is described in [RFC2904] and proposed in the Pull
Model draft [I-D.greevenbosch-ace-pull-model].
From a high level point of view, it can be depicted as below:
+-------------------------+
+--------+ | Resource Domain |
| | | +-------------------+ |
| | | | Authorization | |
| | | | Server | |
| | | +-------------------+ |
| Client | | /|\ | |
| | | 2| |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------------+->| Resource | |
| |<-----------+--| Server | |
| | 4 | +-------------------+ |
+--------+ | |
+-------------------------+
Figure 2: Pull Model
In this model, the high level flows are described as follows:
Step 1: the client sends a resource access request to the Resource
Server.
Step 2: the Resource Server sends an authorization request to the
Authorization Server for the resource access request from the client.
Step 3: the Authorization Server evaluates the authorization request
and returns an access ticket to the Resource Server.
Step 4: the Resource Server verifies the access ticket and returns a
resource access response.
Greevenbosch, et al. Expires June 20, 2015 [Page 14]
Internet-Draft ACE comparison December 2014
4.2.2. Analysis
Advantage: in the pull model, there is no need to cache or forward
the access ticket. This can save message transmission and processing
workload for the client. This will especially be helpful if the
client is constained. Also, this model can work for use cases where
the client cannot have a direct connection with the Authorization
Server.
Disadvantage: the message transmission and processing workload for
the Resource Server is relatively high compared with the push model.
4.3. Agent Model
4.3.1. Brief Introduction
Agent model is described in [RFC2904] and this model was discussed in
IETF 89 ACE Toronto F2F meeting.
From high level point of view, it can be depicted below:
+-------------------------+
+--------+ | Resource Domain |
| | 1 | +-------------------+ |
| |------------+->| Authorization | |
| |<-----------+--| Server | |
| | 4 | +-------------------+ |
| Client | | | /|\ |
| | | 2| |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Resource | |
| | | | Server | |
| | | +-------------------+ |
+--------+ | |
+-------------------------+
Figure 3: Agent Model
In this model, the high level flows are described as follows:
Step 1: the client sends a resource access request to the
Authorization Server.
Step 2: the Authorization Server checks the client's access rights,
and sends a resource access request to the Resource Server,
containing the access ticket.
Greevenbosch, et al. Expires June 20, 2015 [Page 15]
Internet-Draft ACE comparison December 2014
Step 3: the Resource Server verifies the access ticket and returns a
resource access response to the Authorization Server.
Step 4: the Resource Server verifies the access ticket and returns a
resource access response to the client.
4.3.2. Analysis
Advantage: this model can work when the client cannot have a direct
connection with the Resource Server.
Disadvantage: the Authorization Server works as an agent, and it is
involved in the resource access process. Logically, the
Authorization Server should just take care of authentication and
authorization issues and should not mix other functionalities.
4.4. Push/Confirm Model
4.4.1. Brief Introduction
This model was discussed in IETF 89 ACE Toronto F2F meeting. The
OAuth introspection solution [I-D.wahlstroem-ace-oauth-introspection]
uses this model.
From high level point of view, it can be depicted as follows:
+-------------------------+
+--------+ | Resource Domain |
| | 1 | +-------------------+ |
| |------------+->| Authorization | |
| |<-----------+--| Server | |
| | 2 | +-------------------+ |
| | | /|\ | |
| Client | | 4 | | 5 |
| | | | \|/ |
| | 3 | +-------------------+ |
| |------------+->| Resource | |
| |<-----------+--| Server | |
| | 6 | +-------------------+ |
+--------+ | |
+-------------------------+
Figure 4: Push/Confirm Model
In this model, the high level flows are described as follows:
Step 1: the client sends a request to the Authorization Server to get
Greevenbosch, et al. Expires June 20, 2015 [Page 16]
Internet-Draft ACE comparison December 2014
an access ticket for a specific resource access request.
Step 2: the Authorization Server sends the access ticket identifier
to the client.
Step 3: the client sends a resource access request to the Resource
Server, containing the access ticket identifier.
Step 4: the Resource Server sends an authorization request to the
Authorization Server, containing the access ticket identifier.
Step 5: the Authorization Server gets the access ticket according to
the received access ticket identifier, and sends the access ticket to
the Resource Server.
Step 6: the Resource Server verifies the access ticket and returns
the resource access response to the client.
4.4.2. Analysis
Advantage: this model does not require direct transfer of the access
ticket to the client, such that transmission traffic for the client
is reduced. This model is efficient if the access ticket is
relatively large and the client is resource constrained.
Disadvantage: this model requires more processes in the whole
authorization flow. It adds a burden for the Resource Server to send
an authorization request to and get a response from the Authorization
Server. It also adds a burden for the Authorization Server to handle
requests from both the client and the Resource Server.
4.5. Indirect Push Model
4.5.1. Brief Introduction
This model was proposed in [I-D.schmitt-ace-twowayauth-for-iot].
From a high level point of view, it can be depicted as follows:
Greevenbosch, et al. Expires June 20, 2015 [Page 17]
Internet-Draft ACE comparison December 2014
+-------------------------+
+--------+ | Resource Domain |
| | 1 | +-------------------+ |
| |------------+->| Authorization | |
| |<-----------+--| Server | |
| | 4 | +-------------------+ |
| | | | /|\ |
| Client | | 2 | | 3 |
| | | \|/ | |
| | 5 | +-------------------+ |
| |------------+->| Resource | |
| |<-----------+--| Server | |
| | 6 | +-------------------+ |
+--------+ | |
+-------------------------+
Figure 5: Indirect Push Model
In this model, the high level flows are described as follows:
Step 1: the client sends an authorization request to the
Authorization Server for a specific resource access request.
Step 2: the Authorization Server verifies the authorization request
and sends an access ticket to the Resource Server.
Step 3: the Resource Server caches the received access ticket and
returns confirmation about the receipt of the access ticket.
Step 4: the Authorization Server sends an authorization response to
the client.
Step 5: the client sends a resource access request to the Resource
Server.
Step 6: the Resource Server verifies the resource access request
based on the cached access ticket and returns a resource access
response to the client.
4.5.2. Analysis
Advantage: this model does not require the client to receive the
access ticket from the Authorization Server and send the access
ticket to the Resource Server. This can reduce transmission traffic
for the client. This model is efficient if the access ticket is
relatively large and the client is resource constrained.
Disadvantage: this model requires more processes in the whole
Greevenbosch, et al. Expires June 20, 2015 [Page 18]
Internet-Draft ACE comparison December 2014
authorization flow. It adds a burden to the Resource Server to cache
the access ticket.
4.6. Recommendations
To cover different use cases, one architectural model may be
difficult to cover all the use cases. Also, too many alternative
architectural models may introduce interoperability problems. Based
on the analysis above, this memo recommends two models: the push
model and the pull model. These two models can work complementary to
each other, and can satisfy different use cases.
5. Security considerations
The complete document concerns security considerations.
6. IANA considerations
This document does not require any IANA registrations.
7. Acknowledgements
Thanks to the authors of the various drafts for their efforts to
provide a solution for authentication and authorization in
constrained environments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[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.
Greevenbosch, et al. Expires June 20, 2015 [Page 19]
Internet-Draft ACE comparison December 2014
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
RFC 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012.
[I-D.ietf-oauth-introspection]
Richer, J., "OAuth Token Introspection",
draft-ietf-oauth-introspection-00 (work in progress),
August 2014.
[I-D.bormann-core-ace-aif]
Bormann, C., "An Authorization Information Format (AIF)
for ACE", draft-bormann-core-ace-aif-01 (work in
progress), July 2014.
[I-D.bormann-lwig-terms]
Bormann, C. and M. Ersue, "Terminology for Constrained
Node Networks", draft-bormann-lwig-terms-00 (work in
progress), November 2012.
[I-D.gerdes-ace-dcaf-authorize]
Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP
Authentication and Authorization Framework (DCAF)",
draft-gerdes-ace-dcaf-authorize-00 (work in progress),
July 2014.
[I-D.greevenbosch-ace-pull-model]
Greevenbosch, B., ana.hedanping@huawei.com, a., and D.
Zhang, "ACE Pull Model",
draft-greevenbosch-ace-pull-model-00 (work in progress),
October 2014.
[I-D.marin-ace-wg-coap-eap]
Garcia, D., "EAP-based Authentication Service for CoAP",
draft-marin-ace-wg-coap-eap-01 (work in progress),
October 2014.
[I-D.schmitt-ace-twowayauth-for-iot]
Schmitt, C. and B. Stiller, "Two-way Authentication for
IoT", draft-schmitt-ace-twowayauth-for-iot-00 (work in
Greevenbosch, et al. Expires June 20, 2015 [Page 20]
Internet-Draft ACE comparison December 2014
progress), June 2014.
[I-D.tschofenig-ace-oauth-bt]
Tschofenig, H., "The OAuth 2.0 Bearer Token Usage over the
Constrained Application Protocol (CoAP)",
draft-tschofenig-ace-oauth-bt-00 (work in progress),
July 2014.
[I-D.tschofenig-ace-oauth-iot]
Tschofenig, H., "The OAuth 2.0 Internet of Things (IoT)
Client Credentials Grant",
draft-tschofenig-ace-oauth-iot-00 (work in progress),
July 2014.
[I-D.wahlstroem-ace-oauth-introspection]
Wahlstroem, E., "OAuth 2.0 Introspection over the
Constrained Application Protocol (CoAP)",
draft-wahlstroem-ace-oauth-introspection-00 (work in
progress), October 2014.
Authors' Addresses
Bert Greevenbosch
Huawei Technologies Co., Ltd.
Huawei Industrial Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: bert.greevenbosch@huawei.com
Danping He
Huawei Technologies
Q14, Huawei, Huanbao Yuan, 156 Beiqing Road, Haidian District
Beijing 100095
China
Email: ana.hedanping@huawei.com
Greevenbosch, et al. Expires June 20, 2015 [Page 21]
Internet-Draft ACE comparison December 2014
Ruinan Sun
Huawei Technologies Co., Ltd.
Huawei Industrial Base
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: sunruinan@huawei.com
Greevenbosch, et al. Expires June 20, 2015 [Page 22]
