ace B. Greevenbosch Internet-Draft D. He Intended status: Standards Track D. Zhang Expires: April 28, 2015 Huawei Technologies October 25, 2014 ACE Pull Model draft-greevenbosch-ace-pull-model-00 Abstract This specification defines a protocol which enables resource constrained nodes to perform authentication and authorization operations in a constrained environment. By using this protocol, a resource constrained node can delegate the authentication of communication peers and management of authorization information to a trusted third party with less severe limitations regarding processing power and memory. This specification is based on the pull model architecture. Note Discussion and suggestions for improvement are requested, and should be sent to ace@ietf.org. 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 28, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Greevenbosch, et al. Expires April 28, 2015 [Page 1] Internet-Draft ACE Pull Model October 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Justification . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Authorization Flow . . . . . . . . . . . . . . . . . . . . . . 5 4. Message Designs . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Resource Request Message . . . . . . . . . . . . . . . . . 6 4.2. Access Token Request Message . . . . . . . . . . . . . . . 6 4.3. Access Token Response Message . . . . . . . . . . . . . . 7 4.4. Resource Response Message . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Authentication/DTLS Channel Setup . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Greevenbosch, et al. Expires April 28, 2015 [Page 2] Internet-Draft ACE Pull Model October 2014 1. Introduction In this memo, constrained nodes are referred to as small devices with limited abilities. In many cases, a constrained node is designed for a single simple task. Constrained nodes have limited resources in terms of processing power, memory, non-volatile storage and transmission capacity. Additionally, in most cases constrained nodes do not have user interfaces or displays. The use cases and requirements for authentication and authorization aspects of constrained environments are discussed in [I-D.seitz-ace-usecases], and the actors involved in authentication and authorization in a constrained environment are discussed in [I-D.gerdes-ace-actors]. In [RFC2904], three basic models are specified: the push model, the pull model and the agent model. The usage of the push model in constrained environments is discussed in [I-D.selander-core-access-control] and [I-D.gerdes-ace-dcaf-authorize], that is, the Client pushes the access token to the Resource Server for authorization verification. This specification proposes to use the pull model for authorization, that is, the Resource Server pulls an access token from the Authorization Server for authorization verification. 1.1. Justification For constrained environments, different use cases require different authorization models. In [I-D.seitz-ace-usecases], several use cases are specified. In some use cases, especially the offline use cases, a client does not have direct access to the Authorization Server, but only has access to a Resource Server, whereas the Resource Server has access to the Authorization Server. Using the home automation scenario as an example, the remote controller in the home is a Client, the temperature sensor on the air conditioner is a resource. The remote controller can only connect to the air conditioner by bluetooth. As a Resource Server, the air conditioner can always connect to the Authorization Server via the home gateway. In this case, the Client has to send a resource access request to the Resource Server, and the Resource Server contacts the Authorization Server to obtain authorization decisions. In the resource-centric access mode, or when the resource servers belong to different resource owners/authority entities, or when a client only knows the IP of the target resource server, the pull model can significantly reduce the overhead imposed by communicating with the Authorization Server. Greevenbosch, et al. Expires April 28, 2015 [Page 3] Internet-Draft ACE Pull Model October 2014 The pull model does not significantly modify the existing client- server communication interfaces, but requires less interaction on the client end compared with the push model, which benefits the constrained client devices. In addition, when using the push model, the authentication and authorization operations are performed at the same time. This may introduce certain inflexibility. For instance, after a client has obtained a token to access a certain resource, the owner of the resource may want to change its policies and refuse to provide the client access to the resource. In this case, an additional mechanism needs to be provided to alarm the resource server that the token is no longer valid. This makes system more complex. However, this issue does not exist when using the pull model. There is no single authentication and authorization model that can satisfy all the use cases in constraint environments. Both the push model and the pull model should be considered, and they should be supported by constraint devices and function complementary of each other, offering lightweight communication and flexibility to the network. In this specification, a pull model based authentication and authorization protocol for constraint environment is described. 1.2. Terminology 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. Architecture This section specifies the architectural model. It follows the pull sequence as specified in [RFC2904], section 3.1.2. As depicted in Figure 1, the Client sends a resource access request to the Resource Server (1), which forwards it to the Authorization Server (2), which evaluates the request and returns an appropriate response to the Resource Server (3), which provides a resource access response to the Client (4). Greevenbosch, et al. Expires April 28, 2015 [Page 4] Internet-Draft ACE Pull Model October 2014 +-------------------------+ +--------+ | Resource Domain | | | | +-------------------+ | | | | | Authorization | | | | | | Server | | | | | +-------------------+ | | Client | | /|\ | | | | | 2| |3 | | | | | \|/ | | | 1 | +-------------------+ | | |------------+->| Resource | | | |<-----------+--| Server | | | | 4 | +-------------------+ | +--------+ | | +-------------------------+ Figure 1: Authorization Architecture Model Note that in this architecture, the Authentication Manager specified in [I-D.gerdes-ace-actors] is not shown, because it is not involved in the authorization flows. It is assumed that the Authentication Manager can help the Client and Resource Server to perform mutual authentication. In addition, the Authentication Manager could either be merged with the Client or with the Authorization Server. 3. Authorization Flow Figure 2 provides a high level view of the authorization flow. Client Resource Server Authorization Server | | | | [1 Resource Request-->] | | | | | | | [2 Access Token Request -->] | | | | | | [<--3 Access Token Response] | | | | | [<--4 Resource Response] | | | | | Figure 2: Pull Model Authorization Flows The detailed flow is explained below: Step 1: Client sends resource access request to Resource Server; Greevenbosch, et al. Expires April 28, 2015 [Page 5] Internet-Draft ACE Pull Model October 2014 Step 2: Resource Server forwards resource access request to Authorization Server; Step 3: Authorization Server evaluates the request and returns an access token to Resource Server; Resource Server verifies the access token; Step 4: Resource Server sends resource access response to the Client. 4. Message Designs There are four main messages involved in the authorization flows: "Resource Request", "Access Token Request", "Access Token Response" and "Resource Response". 4.1. Resource Request Message The resource request message is sent from the Client to the Resource Server, and it is used to request resources on the Resource Server. This message includes IP address and port of the Resource Server, resource URI, targeted operation to the resource and Client identifier. The transport protocol for this message is CoAP (Constrained Application Protocol) and the semantics follow [RFC7252]. Client identifier can be transported by NodeId option as specified in [I-D.li-core-coap-node-id-option]. 4.2. Access Token Request Message The access token request message is used by the Resource Server to request an access token from the Authorization Server. The transport protocol for this message is also CoAP and the semantics follow [RFC7252]. The Access Token Request message is constructed as follows: 1. The request method is POST. 2. The Uri-Host and Uri-Port specify the IP address and port of the Authorization Server. When this information is already available through a lower layer protocol, e.g. UDP and IP, the options SHOULD be omitted. 3. The request URI is "Authorization-Handling". It identifies a resource at the Authorization Server for handling authorization requests. Greevenbosch, et al. Expires April 28, 2015 [Page 6] Internet-Draft ACE Pull Model October 2014 4. The message payload contains a data structure that describes the action and resource for which Client requests an access token. The data structure is defined in [I-D.gerdes-ace-dcaf-authorize]. 5. The Content-Format of the payload is application/dcaf+cbor according to [I-D.gerdes-ace-dcaf-authorize]. Note that client identifier transported as NodeId option in the Resource Request message is transported in the Description field defined in [I-D.gerdes-ace-dcaf-authorize]. The Description field is a descriptive label of the initiator of the authorization request. 4.3. Access Token Response Message The access token response message is used by the Authorization Server to send an access token to the Resource Server. The transport protocol for this message is also CoAP and the semantics follow [RFC7252]. The Access Token Response message is constructed as follows: 1. The response code is 2.05 Content or 4.xx if there is an error. 2. The Uri-Host and Uri-Port options specify the IP address and port of the Resource Server. When this information is already available through a lower layer protocol, e.g. UDP and IP, the options SHOULD be omitted. 3. The message payload contains a data structure that contains an access token. The data structure is defined in [I-D.gerdes-ace-dcaf-authorize]. 4. The Content-Format of the payload is application/dcaf+cbor according to [I-D.gerdes-ace-dcaf-authorize]. 4.4. Resource Response Message The resource response message is used by the Resource Server to provide resources to the Client. It contains the response to the resource request. The transport protocol for this message is CoAP (Constrained Application Protocol) and the semantics follow [RFC7252]. Especially, the resource response is the CoAP response to the CoAP request that contained the resource request. Since, due to contacting the AS, there may be some time between request and response, the RS MAY refrain from piggybacking for a CON request, as described in [RFC7252]. 5. Examples This section shows one message exchange example from the Client to Greevenbosch, et al. Expires April 28, 2015 [Page 7] Internet-Draft ACE Pull Model October 2014 request the temperature sensor value on the Resource Server. Note that some message headers or options are omitted for simplicity, e.g. Token, Message-Id. Also, the message body is represented in JSON, although in reality it is encoded in CBOR. Resource request message from Client to Resource Server: Code: GET URI-Host: example.resourceserver.com URI-Port: 5683 URI-Path: temp4 Node-Id: Client_Identifier1234 Figure 3: Resource Request Message Example Access token request message from Resource Server to Authorization Server: Code: POST URI-Host: example.authorizationserver.com URI-Port: 5683 URI-Path: Authorization-Handling Content-Format: application/dcaf+cbor Payload: { AI: ["coaps://example.resourceserver.com/temp4", 1], D: Client_Identifier1234, TS: 168537 } Figure 4: Access Token Request Message Example Access token response message from Authorization Server to Resource Server: Greevenbosch, et al. Expires April 28, 2015 [Page 8] Internet-Draft ACE Pull Model October 2014 Code: 2.05 URI-Host: example.resourceserver.com URI-Port: 5683 Max-Age: 86400 Content-Format: application/dcaf+cbor Payload: { F: { AI: [ "/temp4", 7 ], D: Client_Identifier1234, TS: 0("2014-08-27T10:06:12.391"), L: 86400, G: hmac_sha256 }, V: h'b2dd4e409c2d36a7423da3c87e571999 0b778ebd2c7d3730729a7fcde26c7201' } Figure 5: Access Token Response Message Example Resource response message from Resource Server to Client: Code: 2.05 URI-Host: 10.66.167.122 URI-Port: 5683 Content-Format: text/plain Payload: 23 Figure 6: Resource Response Message Example 6. Authentication/DTLS Channel Setup It is assumed that the Client and the Resource Server can get the symmetric keys before they exchange any message. The key can be manually deployed in advance or under the help of Authentication Manager and Authorization Server. TBD: how to setup DTLS channel between Client and Resource Server. 7. IANA Considerations TBD. Greevenbosch, et al. Expires April 28, 2015 [Page 9] Internet-Draft ACE Pull Model October 2014 8. Security Considerations Note that communication security is not specified here. It can be based on DTLS ([RFC6347]) or object security. Please refer to [I-D.seitz-ace-design-considerations] for more discussions. More security considerations are TBD. 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. 10.2. Informative References [I-D.gerdes-ace-actors] Gerdes, S., "Actors in the ACE Architecture", draft-gerdes-ace-actors-01 (work in progress), July 2014. [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.li-core-coap-node-id-option] Li, K. and G. Wei, "CoAP Option Extension: NodeId", draft-li-core-coap-node-id-option-01 (work in progress), June 2014. Greevenbosch, et al. Expires April 28, 2015 [Page 10] Internet-Draft ACE Pull Model October 2014 [I-D.seitz-ace-design-considerations] Seitz, L. and G. Selander, "Design Considerations for Security Protocols in Constrained Environments", draft-seitz-ace-design-considerations-00 (work in progress), February 2014. [I-D.seitz-ace-usecases] Seitz, L., Gerdes, S., Selander, G., Mani, M., and S. Kumar, "ACE use cases", draft-seitz-ace-usecases-01 (work in progress), July 2014. [I-D.selander-core-access-control] Selander, G., Sethi, M., and L. Seitz, "Access Control Framework for Constrained Environments", draft-selander-core-access-control-02 (work in progress), February 2014. Authors' Addresses Bert Greevenbosch Huawei Technologies Huawei Base, Bantian, Longgang District Shenzhen, Guangdong 518129 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 Dacheng Zhang Huawei Technologies Q14, Huawei, Huanbao Yuan, 156 Beiqing Road, Haidian District Beijing 100095 China Email: zhangdacheng@huawei.com Greevenbosch, et al. Expires April 28, 2015 [Page 11]