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

From: Samuel Erdtman <[email-masked]>
Date: Sun, 3 Jan 2016 20:12:30 +0100

Hi Mohit,

Thanks for your detailed review. see comments inline.

On Sat, Dec 26, 2015 at 5:34 PM, Mohit Sethi <[email-masked]>
wrote:

> 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?)
>

Samuel: I see your point, an interpretation could be that it is either or
(user or service), depending on the situation, I think some of the other
authors needs to pitch in here to share there understanding.

>
> - 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).
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
> - 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.
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

- 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. ??
>
>
Samuel: The formulation might be a bit fuzzy, my interpretation is the
other way around as services and capabilities of applikations increases the
desire to protect them will increase.
How about changing the formulation of the second part of the sentence from
"and this desire will increase with the number of exposed services and
capabilities provided by applications hosted on the IoT devices" to ". As
service and capabilities  of IoT devices are increasing the desire to
protect in the same way will increase"?

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

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

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

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
> - 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
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

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

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
>
> 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
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
>
>
> 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
>
>
Samuel: It is a good comment and as you have notised there is a registered
issue related to the topic, I have added your comment and linked to this
email

> -  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.
>

Samuel: I think the reason for MAY is to really keep the amount of data to
a minimum but keeping the possibility. In addition to key type, scope would
be a natural thing to include. However I live with SHOULD, bet before we
change it would be good if others could express there opinions on the
topic.

>
> - 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.
>

 Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

> - 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
>

 Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
>
>
> 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?
>

Samuel: This is something we need to workout by resolving
https://github.com/LudwigSeitz/ace-oauth/issues/22, it might be that it
should be defined in this specification or in other.

>
> - 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.
>

Samuel: x5c, x5t or x5t#S256 are attributes form the JOSE (JWS,
https://tools.ietf.org/html/rfc7515) specification defining a way to
referee to certificates. I have added a reference to the them in the
document. However it might be good to describe them further and the use in
this context, it relates a bit to
https://github.com/LudwigSeitz/ace-oauth/issues/25

>
> - 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
>

Samuel: I´m sure if this is an improvement, e.g. if the PoP token would be
a reference token and introspection used then the security context does not
come inside the token but as a response to the introspection request. There
is an issue registered regarding reference tokens
https://github.com/LudwigSeitz/ace-oauth/issues/11

>
> - 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
>

 Samuel: I lack in my CoAP knowledge, is there a CoAP limit of 255 then
SHALL NOT would be preferable but if it is not it might be preferable to
use SHOUL NOT to have a bit of flexibility.

>
>
> 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?
>

Samuel: In general I would say that the client can use the same key pair
with multiple RSes, but should know the security and privacy implications.
e.g. privacy wise it would be possible for RSes to track the Client in a
way that is not desirable and security wise the key would need to rotate
more often. I have added an issue to add text regarding this.
https://github.com/LudwigSeitz/ace-oauth/issues/26

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

Samuel: Good catch

> - 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?
>

Samuel: the reason for not having a key in the request could be that the
key is symmetric and, but that could be clearer. This relates to the CSP
(communication security protocol) that might need to be more specific e.g.
DTLS-PreSharedKey or DTLS-RawPublicKey. Some of this is somewhat covered by
https://github.com/LudwigSeitz/ace-oauth/issues/4
For 'client_id' and 'client_secret' I don´t know if it should be explained
here (in this document) or refereed to the OAuth2 description, opinions?

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

And/or referensed to the description under JOSE, opinions?

>
>
> 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.
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
> - 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.
>

Samuel: The symmetric key in the token would always be encrypted with the
key of the audience (RS) if I understand the OAuth2 PoP architecture
correct https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-07

>
>
>
> 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?
>

Samuel: I´m not sure I would like to have something like HTTP 202 Accepted
but I cannot find such code for CoAP closes thing I find is 2.01 Created.
Suggestions?

>
>
>
> 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.
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
> - 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.
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

>
>
> 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.
>

Samuel: I thinks your proposal is an improvement and has updated the
working copy with it.

> - Also worth mentioning that this allows for more dynamic revocation.
>

Samuel: Introspection can be done on self contained tokens too, i.e.
checking revocation state of a token.

>
>
>
> 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?
>

Samuel: When registering the client dynamically or as a precondition It
could be configured what kind of token the client are allowed to request,
in the same way as which scopes it can get authorization for.

>
> - 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.

Samuel: As you mentioned the issue addresses som of this, then since both
client and RS have a relation to AS I think AS should issue tokens and keys
that are compatible. This view of things in combination with the referred
issue could solve this as I see it.

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