Internet DRAFT - draft-greevenbosch-ace-pull-model
draft-greevenbosch-ace-pull-model
ace B. Greevenbosch
Internet-Draft D. He
Intended status: Standards Track D. Zhang
Expires: June 20, 2015 R. Sun
Huawei Technologies
December 17, 2014
ACE Pull Model
draft-greevenbosch-ace-pull-model-01
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 June 20, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
Greevenbosch, et al. Expires June 20, 2015 [Page 1]
Internet-Draft ACE Pull Model December 2014
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.
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 June 20, 2015 [Page 2]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 3]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 4]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 5]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 6]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 7]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 8]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 9]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 10]
Internet-Draft ACE Pull Model December 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 June 20, 2015 [Page 11]
Internet-Draft ACE Pull Model December 2014
Ruinan Sun
Huawei Technologies
Huawei Industrial Base
Bantian, Longgang District
Shenzhen 518129
China
Email: sunruinan@huawei.com
Greevenbosch, et al. Expires June 20, 2015 [Page 12]
