ACE B. Greevenbosch Internet-Draft D. He Intended status: Informational Huawei Technologies Expires: April 30, 2015 October 27, 2014 Comparison of different proposals for ACE draft-greevenbosch-ace-comparison-00 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 April 30, 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 to this document. Code Components extracted from this document must Greevenbosch & He Expires April 30, 2015 [Page 1] Internet-Draft ACE comparison October 2014 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 & He Expires April 30, 2015 [Page 2] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 3] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 4] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 5] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 6] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 7] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 8] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 9] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 10] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 11] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 12] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 13] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 14] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 15] Internet-Draft ACE comparison October 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. 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 an access ticket for a specific resource access request. Greevenbosch & He Expires April 30, 2015 [Page 16] Internet-Draft ACE comparison October 2014 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 & He Expires April 30, 2015 [Page 17] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 18] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 19] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 20] Internet-Draft ACE comparison October 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 & He Expires April 30, 2015 [Page 21]