Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-00.txt

From: [email-masked]
Date: Mon, 21 Dec 2015 10:34:26 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Authentication and Authorization for Constrained Environments Working Group of the IETF.

        Title           : Authorization for the Internet of Things using OAuth 2.0
        Authors         : Ludwig Seitz
                          Goeran Selander
                          Erik Wahlstroem
                          Samuel Erdtman
                          Hannes Tschofenig
	Filename        : draft-ietf-ace-oauth-authz-00.txt
	Pages           : 43
	Date            : 2015-12-21

Abstract:
   This memo defines how to use OAuth 2.0 as an authorization framework
   with Internet of Things (IoT) deployments, thus bringing a well-known
   and widely used security solution to IoT devices.  Where possible
   vanilla OAuth 2.0 is used, but where the limitations of IoT devices
   require it, profiles and extensions are provided.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mohit Sethi <[email-masked]>
Date: Sat, 26 Dec 2015 18:34:01 +0200

Hi

Here is my review of the OAuth draft. Comments are listed here 
section-wise.
----------------------------------------------------------------------

1. Introduction

- Managing authorization of users, services and their devices with the 
help of dedicated authorization servers (AS)
- MS: Managing authorization of users, services and devices with ..... 
(it was not clear who "their" refers to? Do the devices belong to the 
users or the services?)

- In its simplest form the authorization task can be described as 
granting access to a resource hosted on a device, the resource server (RS).
- MS: In its simplest form the authorization task can be described as 
granting access to a requesting client, for a resource hosted on a 
device, the resource server (RS).

- We envision that end consumers and enterprises will want to manage 
their Internet of Things (IoT) devices in the same style and this desire 
will increase with the number of exposed services and capabilities 
provided by applications hosted on the IoT devices.
- MS: We envision that end consumers and enterprises will want to manage 
access-control and authorization for their Internet of Things (IoT) 
devices in the same style.
- Also, I am not sure if I understand how this desire would increase the 
services and capabilities provided by applications hosted on IoT 
devices. Perhaps this could be elaborated. ??

- constrained in various ways including processing, memory, code, 
energy, etc., as
- MS:  constrained in various ways including processing, memory, 
code-size, energy, etc., as

- with different kinds of constrainedness
- MS: with different kinds of constraints

- for example to support lower the over-the-wire message size and 
smaller code size
- MS: for example to support smaller over-the-wire message size and 
smaller code size

3.2 CoAP

- Where HTTP uses headers and query-strings to convey additional
- MS: While HTTP uses headers and query-strings to convey additional

3.3 Object Security
- Whereas OSCOAP integrity protects specific CoAP message meta-data like 
request/response code
- MS: While OSCOAP integrity protects specific CoAP message meta-data 
like request/response code

4. Protocol Interactions
- For the description in this document we assume that the client has 
been registered to an AS.  Registration means that the two share 
credentials, configuration parameters and that some form of 
authorization has taken place.  These credentials are used to protect 
the token request by the client and the transport of access tokens and 
client information from AS to the client.
- MS: To me this fairly complex and needs to be described better. I 
understand that this document may not standardize how the client 
discovers and registers to an AS, but there still needs to be some 
description on how this is done in practice. While currently a client 
can discover an RS (resource-server) using a resource directory or DNS 
Service discovery, how does it find out which AS is responsible for the 
given RS. In the web-world this works rather well with re-directs but I 
am not sure how this would work in the scenarios described in the draft. 
I see a related issue on git as well: 
https://github.com/LudwigSeitz/ace-oauth/issues/22

-  The client may include permissions it seeks to obtain, and 
information about the type of credentials it wants to use (i.e., 
symmetric or asymmetric cryptography).
- MS: The client MAY include permissions it seeks to obtain, and 
information about the type of credentials it wants.
- I also think that the text should probably say SHALL/SHOULD instead of 
MAY. The client should include the permission it seeks.

- Communication security between client and RS may be based on 
pre-provisioned keys/security contexts or dynamically established to the 
RS via the PoP token; and to the client via the client information.
- MS: Communication security between client and RS may be based on 
pre-provisioned keys/security contexts or dynamically established. The 
RS authenticates the client via the PoP token; and the client 
authenticates the RS via the client information.

- which conveys authorization information to the RS that may be used for 
subsequent resource requests, and
- MS: which conveys authorization information to the RS that may be used 
by the client for subsequent resource requests, and

5.1 Communication Security Protocol
-  The client and the RS might not have any prior knowledge about each 
other, therefore the AS needs to help them to establish a security 
context or at least a key.  The AS does this by indicating communication 
security protocol ("csp") and additional key parameters in the client 
information.
- MS: How does the client know about AS in the first place? Refers to my 
previous comment on how can a client discover the AS?

- configured more tightly with additional client information parameters, 
like x5c, x5t or x5t#S256.
- MS: some explanation on how these parameters can be used would be 
beneficial. Or a reference to where I can find more information.

- To use OSCOAP and OSCON requires security context to be established, 
which can be provisioned with PoP token and client information
- MS: To use OSCOAP and OSCON requires security context to be 
established, which can be provisioned inside the PoP token and client 
information

- token is larger than 255 bytes it should not be sent as a CoAP option
- MS: token is larger than 255 bytes it SHALL NOT be sent as a CoAP option

6.1 Client and Resource Server are Offline

- A: The client first generates a public-private key pair used for 
communication security with the RS.
- MS: Does the client generate a new key pair for every RS. Can they be 
re-used across RS? I assume key generation can be expensive for some 
devices?

- a value the that the temperature sensor identifies itself with.
- MS: a value that the temperature sensor identifies itself with.

- The client sends the POST request to /token at AS.  The request 
contains the public key of the client and the Audience parameter set to 
"tempSensorInLivingRoom".
- MS: There is no public-key in the request payload of Figure 3? Also 
some explanation of 'client_id' and 'client_secret' would be useful. I 
checked the appendix and didn't find enough information on what is the 
role of client_secret?

- MS: Perhaps the role of iat attribute in figure 5 could be explained 
in text.

6.2 Resource Server Offline

- The following example shows interactions between a client (AC control unit
- MS: AC (access-control) control unit can be confusing. Don't use the 
acronym. Instead use air-conditioning control unit.

- The client then sends the PoP token to the /authz-info resource in the 
RS.  This is a plain CoAP request, i.e. no DTLS/OSCOAP between client 
and RS, since the token is integrity protected between AS and RS.
- MS: Shouldn't the token also be encrypted? If not, any one on the path 
can see the symmetric-key and act on behalf of the real client.

6.3 Token Introspection with an Offline client

- and thus defers to respond the client with a status code until step E 
and only acknowledges on the CoAP message layer  indicated with a dashed 
line).
- MS: Which status code is this? Is it an HTTP status code? CoAP 
response code?

Appendix A:
- which has an impact of choice of message format and protocol.
- MS:  which has an impact on the choice of message format and protocol.

- protocols contribute to the communication overhead and can in some 
cases can be optimized.
- MS: protocols contribute to the communication overhead and can in some 
cases be optimized.

Appendix B:
- In case of introspection it may be useful with access tokens which are 
not self-contained.
- MS: In case of introspection, it may be beneficial to utilize access 
tokens which are not self-contained.
- Also worth mentioning that this allows for more dynamic revocation.

General comments:
- MS: I like the fact that there can be different deployment scenarios 
that can be supported with this architecture. But I am wondering if this 
can actual lead to unknown security vulnerabilities? When should a AS 
give short-lived access tokens and when should they be long-lived. Can't 
a client always pretend that it will be offline and ask for long-lived 
tokens. How does the AS check whether a client is really 
resource-constrained or not? How can a user configure in the AS who can 
get short-lived tokens and who can get long-lived tokens?

- MS: How are the cipher suites negotiated. What happens when the 
constrained-client and constrained-RS don't speak the same elliptic 
curve parameters? I see there is a related git issue: 
https://github.com/LudwigSeitz/ace-oauth/issues/21.

/--Mohit

On 12/21/2015 08:34 PM, [email-masked] wrote:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace