| CoRE Working Group | S. Gerdes |
| Internet-Draft | O. Bergmann |
| Intended status: Standards Track | C. Bormann |
| Expires: August 18, 2014 | Universität Bremen TZI |
| February 14, 2014 |
Delegated CoAP Authentication and Authorization Framework (DCAF)
draft-gerdes-core-dcaf-authorize-02
This specification defines a protocol for delegating client authentication and authorization in a constrained environment for establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS to transfer authorization information and shared secrets for symmetric cryptography between entities in a constrained network. A resource-constrained node can use this protocol to delegate authentication of communication peers and management of authorization information to a trusted host with less severe limitations regarding processing power and memory.
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 August 18, 2014.
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 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.
The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is a transfer protocol similar to HTTP which is designed for the special requirements of constrained environments. A serious problem with constrained devices is the realization of secure communication. The devices only have limited resources such as memory, stable storage (such as disk space) and transmission capacity and often lack input/output devices such as keyboards or displays. Therefore, they are not readily capable of using common protocols. Especially authentication mechanisms are difficult to realize, because the lack of stable storage severely limits the number of keys the system can store. Moreover, CoAP has no mechanism to distinguish access rights for different clients (authorization).
The DCAF architecture is designed to relieve the constrained nodes from managing keys for numerous devices by introducing authorization servers which conduct the authentication and authorization for their nodes. To achieve this, access tokens are used. A device which wants to access a constrained node’s resource first has to gain permission in the form of a token from the node’s authorization server.
As fine-grained authorization is not always needed on constrained devices, DCAF supports an implicit authorization mode where no authorization information is exchanged.
The main goals of DCAF are the setup of a Datagram Transport Layer Security (DTLS) [RFC6347] channel with symmetric pre-shared keys (PSK) [RFC4279] and to securely transmit authorization tickets.
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 RFC 2119 [RFC2119].
Resource Server (RS): A constrained device that hosts resources the Client wants to access.
Client (C): A device that wants to access resources on the Resource Server.
Authorization Server (AS): The node that conducts authentication and authorization for a Resource Server. An Authorization Server can be responsible for a single or multiple devices or even for a whole network. A Resource Server can have multiple Authorization Servers.
Authentication Manager (AM): The node that conducts authentication on behalf of the Client.
Resource Owner: The principal that owns the resource and controls its access permissions.
Access ticket: Contains the authentication and, if necessary, the authorization information needed to access a resource. A Ticket consists of the Ticket Face and the Ticket Verifier
Authorization information: Contains all information needed by RS to decide if C is privileged to access a resource in a specific way.
Authentication information: Contains all information needed by RS to decide if the entity in possession of a certain key is verified by the authorization server.
Access information: Contains authentication information and, if necessary, authorization information.
Ticket Face: The part of the ticket which is generated for the Resource Server. It contains the authorization information and all information needed by the Resource Server to verify that it was granted by AS.
Ticket Verifier: The part of the ticket which is generated for the Client. It enables the client to verify that it is communicating with an appropriate RS.
Explicit authorization: The Authorization Server informs the Resource Server in detail which privileges are granted to the Client.
Implicit authorization: The Authorization Server informs the Resource Server that the Client is authorized to access any resource on RS in any way, without specifying the privileges in detail.
Within the DCAF Architecture each Resource Server (RS) has one or more Authorization Servers (AS) which conduct the authentication and authorization for RS. RS and AS share a symmetric key which has to be exchanged initially to provide for a secure channel. The mechanism used for this is not in the scope of this document.
To gain access to a specific resource on a Resource Server, a client (C) has to request an access ticket from one of the Authorization Servers serving RS either directly or, if it is a constrained device, using its Authentication Manager (AM). In the following, we always discuss the AM role separately, even if that is co-located within a (more powerful) C.
If AS decides that C is allowed to access the resource, it generates a DTLS pre-shared key (PSK) for the communication between C and RS and wraps it into an access ticket. For explicit access control, AS adds the detailed access permissions to the ticket in a way that RS can interpret. After presenting the ticket to RS, C and RS can communicate securely.
To be able to provide for the authentication and authorization services, the Authorization Servers have to fulfill several requirements:
The DCAF protocol comprises three parts:
In Figure 1, a DCAF protocol flow is depicted (messages in square brackets are optional):
AM C RS AS | <== DTLS chan. ==> | | <== DTLS chan. ==> | | | [Resource Req.-->] | | | | | | | | [<-- AS Info.] | | | | | | | <-- Access Req. | | | | | | | | <===== TLS/DTLS channel (AM/AS Mutual Authentication) =====> | | | | | | Ticket Request ------------------------------------------> | | | | | | <------------------------------------------ Ticket Grant | | | | | | Ticket Transm. --> | | | | | | | | | <== DTLS chan. ==> | | | | Auth. Res. Req. -> | |
Figure 1: Protocol Overview
To determine the Authorization Server in charge of a resource hosted at the Resource Server (RS), the Client (C) MAY send an initial Unauthorized Resource Request message to RS. RS then denies the request and sends the address of its Authorization Server (AS) back to the Client.
Instead of the initial Unauthorized Resource Request message, C MAY look up the desired resource in a resource directory (cf. [I-D.ietf-core-resource-directory]) that lists RS’s resources as discussed in Section 9.
Once C knows AS’ address, it can send a request for authorization to AS using its own Authentication Manager (AM). AS authenticates AM, who serves as a trusted introducer for C, and decides if C is allowed to communicate with RS and access the requested resource. If it is, AS generates an access ticket for C. The ticket contains keying material for the establishment of a secure channel and, if necessary, a representation of the permissions C has for the resource. C keeps one part of the access ticket and presents the other part to RS to prove its right to access. With their respective parts of the ticket, C and RS are able to establish a secure channel.
The following sections specify how CoAP is used to interchange access-related data between RS and AS so that AS can provide C and RS with sufficient information to establish a secure channel, and simultaneously convey authorization information specific for this communication relationship to RS.
This document uses Concise Binary Object Representation (CBOR, [RFC7049]) to express authorization information as set of attributes passed in CoAP payloads. Notation and encoding options are discussed in Section 5.
The optional Unauthorized Resource Request message is a request for a resource hosted by RS for which no proper authorization is granted. RS MUST treat any CoAP request as Unauthorized Resource Request message when any of the following holds:
Note: These conditions ensure that RS can handle requests autonomously once access was granted and a secure channel has been established between C and RS.
Unauthorized Resource Request messages MUST be denied with a client error response. In this response, the Resource Server MUST provide proper AS Information to enable the Client to request an access ticket from RS’s Authorization Server as described in Section 3.3.
The response code MUST be 4.01 (Unauthorized) in case the sender of the Unauthorized Resource Request message is not authenticated, or if RS has no valid access ticket for C. If RS has authorization information for C but not for the resource that C has requested, RS MUST reject the request with a 4.03 (Forbidden). If RS has authorization information for C but they do not cover the action C requested on the resource, RS MUST reject the request with a 4.05 (Method Not Allowed).
The AS Information Message is sent by RS as a response to an Unauthorized Resource Request message (see Section 3.2) to point the sender of the Unauthorized Resource Request message to RS’s Authorization Server. The AS information is a set of attributes containing an absolute URI (see Section 4.3 of [RFC3986]) that specifies the Authorization Server in charge of RS.
The message MAY also contain a timestamp generated by RS.
Figure 2 shows an example for an AS Information message payload using CBOR diagnostic notation. (Refer to Section 5 for a detailed description of the available attributes and their semantics.)
4.01 Unauthorized
Content-Format: application/dcaf+cbor
{"AS": "coaps://as-rs.example.com/authorize", "TS": 168537}
Figure 2: AS Information Payload Example
In this example, the attribute AS points the receiver of this message to the URI “coaps://as-rs.example.com/authorize” to request access permissions. The originator of the AS Information payload (i.e. RS) uses a local clock that is loosely synchronized with a time scale common between RS and AS (e.g., wall clock time). Therefore, it has included a time stamp on its own time scale that is used as a nonce for replay attack prevention. Refer to Section 4.1 for more details concerning the usage of time stamps to ensure freshness of access tickets.
The examples in this document are written in CBOR diagnostic notation to improve readability. Figure 3 illustrates the binary encoding of the message payload shown in Figure 2.
a2 # map(2)
62 # text(2)
4153 # "AS"
78 23 # text(35)
636f6170733a2f2f61732d72732e6578
616d706c652e636f6d2f617574686f72
697a65 # "coaps://as-rs.example.com/authorize"
62 # text(2)
5453 # "TS"
1a 00029259 # unsigned(168537)
Figure 3: AS Information Payload Example encoded in CBOR
To retrieve an access ticket for the resource that C wants to access, C sends an Access Request to its authentication manager AM. The Access Request is constructed as follows:
The request URI identifies a resource at AM for handling authorization requests from C. The URI SHOULD be announced by AM in its resource directory as described in Section 9.
The message payload is constructed from the AS information that RS has returned in its AS Information message (see Section 3.3) and information that C provides to describe its intended request(s). The Access Request MUST contain the following attributes:
An example Access Request from C to AM is depicted in Figure 4. (Refer to Section 5 for a detailed description of the available attributes and their semantics.)