Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt

[Ludwig Seitz]

On 2016-10-18 10:34, Cigdem Sengul wrote:

Hello Ludwig,

Thanks for adding the new sections on requirements on profiles and the
examples in the appendix are quite useful too.
I list minor typos and request for clarification/consistency below. Hope
it helps.


[...]

Hello Cigdem,

thank you very much for your review. I have addressed your issues in the 
draft and provided answers inline for your convenience.


Regards,

Ludwig




Requests for clarification:




Page 6/Access Token: "The access token is protected against
modifications using a MAC or

a digital signature, which is added by the AS”


Question: Are access tokens also confidentiality protected e.g.,
encrypted by the AS, to be consumed by RS?


It depends on the encoding of the token, with CWT you indeed have the 
possibility to encrypt the token.


Added text to clarify this.

https://github.com/LudwigSeitz/ace-oauth/issues/62



Page 11/Section 4/Token Introspection Response: "The AS can additionally
return information that the RS needs to pass on to the client in the
form of a client token. The latter is used to establish keys for mutual
authentication between client and RS, when the client has no direct
connectivity to the AS.”


Question: The client still should have had an initial connectivity to
the AS, and has acquired an initial access token, right? This seems to be what
is described in Page 24.

Correct. Clarified this in section 7.4. and added a reference to this 
section in section 4.


https://github.com/LudwigSeitz/ace-oauth/issues/63


Page 15/Figure 4:

Question: Is the grant_type in this example “client_credentials” or
“password”?

The client_id and client_secret parameters can be used with any grant as 
specified in section 2.3.1. of the OAuth 2.0 RFC. This is indeed 
intended to be a client_credentials grant_type.

Do not confuse this with the "password" parameter of the
resource owner password credentials grant.

https://github.com/LudwigSeitz/ace-oauth/issues/64



Page 17/Figure 5:

Question: Shouldn’t the example contain the “profile” parameter, which
was “REQUIRED” in the response in the previous paragraphs.


Right, that was an oversight.

https://github.com/LudwigSeitz/ace-oauth/issues/65



Page 19/20/CoSE_Encrypted:

Question: Is this confirmation parameter used when passing the key to
the client as a response to POST to /token? Or is it used when passing
client token through RS? From Page 24, it seems to be former.
Added a clarification as to how the confirmation parameter is used in 
section 6.4.5.


https://github.com/LudwigSeitz/ace-oauth/issues/66




Page 27/Section 8.1:

"Profiles of this framework MAY define other methods for token
transport. Implementations conforming to this framework MUST implement
this method of token transportation.”

Question: Do you mean “this framework” or “this draft”. Just want to be
absolutely sure, that profiles MAY define other methods for token
transport.


Added a clarification in the terminology section.

https://github.com/LudwigSeitz/ace-oauth/issues/67



Page 28/Section 9: "Using a single

shared secret with multiple authorization server “

Question: There is a type here. “Server” should be “servers” but
shouldn’t this be “Resource servers”?


Yes are right, that was a textual error.

https://github.com/LudwigSeitz/ace-oauth/issues/68



Page 44/Appendix B: “Resource Server”

Question: Is introspection option excluded here deliberately? “ The
sentence: "Optionally: Check that the matching tokens are still valid
(if this is possible.)” Is this the hint for the introspection?


No it is not, this was a simple oversight.

https://github.com/LudwigSeitz/ace-oauth/issues/69


--
Ludwig Seitz, PhD   SICS Swedish ICT AB
Ideon Science Park, Building Beta 2
Scheelevägen 17, SE-223 70 Lund
Phone +46(0)70-349 92 51

The RISE institutes SP, Swedish ICT and Innventia are merging in order 
to create a unified institute sector and become a stronger innovation 
partner for businesses and society. At the end of the year we will 
change our name to RISE. Read more at www.ri.se/en/about-rise




smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt

[Samuel Erdtman]

Thanks for reading and commenting.

I have looked at the minor typos for now, see inline

Working draft can be found here https://github.com/LudwigSeitz/ace-oauth

//Samuel

On Tue, Oct 18, 2016 at 10:34 AM, Cigdem Sengul 
wrote:

> Hello Ludwig,
>
> Thanks for adding the new sections on requirements on profiles and the
> examples in the appendix are quite useful too.
> I list minor typos and request for clarification/consistency below. Hope
> it helps.
>
> Minor typos:
> ==
>
> Page 5/Section 3.1/ OAuth2.0: "The RS makes a POST request to /introspect
> on the AS and
>
>   receives information about the access token contain in the
>   response”.
>
>   ==> Remove “contain”?
>
>
fixed


>
> Page 8/Section 3.2: "and also to support security for CoAP over
>
>different transport in a uniform way,”
>
>   ==> “over a different transport”
>
>
fixed


>
> Page 8/Section 4: " RFC 7744  [RFC7744 
> ] describes many different
>
>IoT use cases but there two preferred grant types”
>
>  ==>"there are two"
>
>
fixed


>
> Page 9/Section 4: "the OAuth client itself is constraint.  In such a “
>
> ==> “the OAuth client itself is constrained.”
>
>
fixed


>
> Page 9/Section 4: "which is often accomplished using
>
>an commissioning tool.”
>
> ==>  “a commissioning tool”
>
>
fixed


>
> Page 10/Section 4/Access Token Response: "More
>
>   information about these parameters can be found in in Section 6.4 
> .”
>
> ==> Remove the second “in”
>
>
fixed


>
> Page 16/Section 6.2/AS-to-Client Response: "The content of the successful 
> reply MUST be encoded as CBOR map,
>
>containing paramters as specified "
>
> ==> “paramters” typo
>
>
fixed


>
> Page 20/Figure 8/caption: "Confirmation parameter”
>
>   ==> typo in “parameter”
>
>
fixed


>
> Page 24/Just below Figure 14: "The client token is a COSE_Encrytped object”
>
> ==> typo in “COSE_Encrytped”
>
>
fixed


>
> Page 26/Section 8: "same way as specified for the "cnf" parameter in section
>
>Section 6.4.5 
> .”
>
> ==> Remove duplicate “section”
>
>
fixed


>
> Page 29/10.1/cnf description: "Description: Key to use to prove the right to 
> use an access token,
>
>   as defined in [RFC7800 ].”
>
> ==> Drop the first “to use”. “Key to prove the right to use an access token”?
>
>
fixed


>
> Page 30/10.1/aud description: “Description: reference to"
>
> ==> “r” capital in reference
>
>
fixed


>
> Page 30/10.1/profile description: “The communication and communication 
> security profile”
>
> ==> “communication” duplicate.
>
>
The profile will define both communication, e.g. COAP or HTTP, and
communication security, e.g. DTLS or COSE. So it might be useful that this
is called out


>
> Page 30/10.2/cnf: "Description: Key to use to prove the right to use”
>
> ==> Drop the first “to use”
>
>
fixed


>
> Page 32/10.6.1/Profile description: “over view”
>
> ==> “overview"
>
>
fixed


>
>
>
> Requests for clarification:
>
> 
>
>
> Page 6/Access Token: "The access token is protected against modifications 
> using a MAC or
>
>   a digital signature, which is added by the AS”
>
>
> Question: Are access tokens also confidentiality protected e.g., encrypted by 
> the AS, to be consumed by RS?
>
> It seems to be the case according to Page 9:
>
> "Established keying material between the AS and the RS allows
>
>the AS to apply cryptographic protection to the access token to
>ensure that its content cannot be modified, and if needed, that the
>content is confidentiality protected.”
>
>
> Page 11/Section 4/Token Introspection Response: "The AS can additionally
>
>   return information that the RS needs to pass on to the client in
>   the form of a client token.  The latter is used to establish keys
>   for mutual authentication between client and RS, when the client
>   has no direct connectivity to the AS.”
>
>
> Question: The client still should have had an initial connectivity to the AS,
>
> and has acquired an initial access token, right? This seems to be what is 
> described in Page 24.
>
>
> Page 15/Figure 4:
>
> Question: Is the grant_type in this example “client_credentials” or 
> “password”?
>
>
> Page 17/Figure 5:
>
> Question: Shouldn’t the example contain the “profile” parameter, which was 
> “REQUIRED” in the response in the previous paragraphs.
>
>
> Page 19/20/CoSE_Encrypted:
>
> Question: Is this confirmation parameter used when passing the key to the 
> client as a response to POST to /token? Or is it used when passing client 
> token through RS? From Page 24, it seems to be former.
>
>
> Page 27/Section 8.1:
>
> "Profiles of this framework MAY define other
>methods for token transport.  Impleme

Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt

[Cigdem Sengul]

Hello Ludwig,

Thanks for adding the new sections on requirements on profiles and the
examples in the appendix are quite useful too.
I list minor typos and request for clarification/consistency below. Hope it
helps.

Minor typos:
==

Page 5/Section 3.1/ OAuth2.0: "The RS makes a POST request to /introspect
on the AS and

  receives information about the access token contain in the
  response”.

  ==> Remove “contain”?


Page 8/Section 3.2: "and also to support security for CoAP over

   different transport in a uniform way,”

  ==> “over a different transport”


Page 8/Section 4: " RFC 7744 
[RFC7744 ] describes many
different

   IoT use cases but there two preferred grant types”

 ==>"there are two"


Page 9/Section 4: "the OAuth client itself is constraint.  In such a “

==> “the OAuth client itself is constrained.”


Page 9/Section 4: "which is often accomplished using

   an commissioning tool.”

==>  “a commissioning tool”


Page 10/Section 4/Access Token Response: "More

  information about these parameters can be found in in Section
6.4 .”

==> Remove the second “in”


Page 16/Section 6.2/AS-to-Client Response: "The content of the
successful reply MUST be encoded as CBOR map,

   containing paramters as specified "

==> “paramters” typo


Page 20/Figure 8/caption: "Confirmation paramter”

  ==> typo in “parameter”


Page 24/Just below Figure 14: "The client token is a COSE_Encrytped object”

==> typo in “COSE_Encrytped”


Page 26/Section 8: "same way as specified for the "cnf" parameter in section

   Section 6.4.5
.”

==> Remove duplicate “section”


Page 29/10.1/cnf description: "Description: Key to use to prove the
right to use an access token,

  as defined in [RFC7800 ].”

==> Drop the first “to use”. “Key to prove the right to use an access token”?


Page 30/10.1/aud description: “Description: reference to"

==> “r” capital in reference


Page 30/10.1/profile description: “The communication and communication
security profile”

==> “communication” duplicate.


Page 30/10.2/cnf: "Description: Key to use to prove the right to use”

==> Drop the first “to use”


Page 32/10.6.1/Profile description: “over view”

==> “overview"




Requests for clarification:




Page 6/Access Token: "The access token is protected against
modifications using a MAC or

  a digital signature, which is added by the AS”


Question: Are access tokens also confidentiality protected e.g.,
encrypted by the AS, to be consumed by RS?

It seems to be the case according to Page 9:

"Established keying material between the AS and the RS allows

   the AS to apply cryptographic protection to the access token to
   ensure that its content cannot be modified, and if needed, that the
   content is confidentiality protected.”


Page 11/Section 4/Token Introspection Response: "The AS can additionally

  return information that the RS needs to pass on to the client in
  the form of a client token.  The latter is used to establish keys
  for mutual authentication between client and RS, when the client
  has no direct connectivity to the AS.”


Question: The client still should have had an initial connectivity to the AS,

and has acquired an initial access token, right? This seems to be what
is described in Page 24.


Page 15/Figure 4:

Question: Is the grant_type in this example “client_credentials” or “password”?


Page 17/Figure 5:

Question: Shouldn’t the example contain the “profile” parameter, which
was “REQUIRED” in the response in the previous paragraphs.


Page 19/20/CoSE_Encrypted:

Question: Is this confirmation parameter used when passing the key to
the client as a response to POST to /token? Or is it used when passing
client token through RS? From Page 24, it seems to be former.


Page 27/Section 8.1:

"Profiles of this framework MAY define other
   methods for token transport.  Implementations conforming to this
   framework MUST implement this method of token transportation.”

Question: Do you mean “this framework” or “this draft”. Just want to
be absolutely sure, that profiles MAY define other methods for token
transport.


Page 28/Section 9: "Using a single

   shared secret with multiple authorization server “

Question: There is a type here. “Server” should be “servers” but
shouldn’t this be “Resource servers”?


Page 44/Appendix B: “Resource Server”

Question: Is introspection option excluded here deliberately? “ The
sentence: "Optionally: Check that the matching tokens are still valid
(if this is possible.)” Is this the hint for the introspection?

 Hope this helps,
--Cigdem Sengul
Senior Researcher
Nominet

On Wed, Oct 12, 2016 at 12:37 PM, Ludwig Seitz  wrote:

>

[Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-03.txt

[Ludwig Seitz]

Hello ACE,

we have uploaded a new version of our draft, addressing mainly the 
review comments from Renzo and adding a number of clarifications about 
the /token, /introspect and /authz-info endpoints.


Please review this version and send us comments, if we get enough 
feeback we might be able to produce another version before the cut-off.



Regards,

Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-03.txt
Date: Wed, 12 Oct 2016 04:35:28 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Erik Wahlstroem 
, Goeran Selander 
, Samuel Erdtman , 
Hannes Tschofenig 



A new version of I-D, draft-ietf-ace-oauth-authz-03.txt
has been successfully submitted by Ludwig Seitz and posted to the
IETF repository.

Name:   draft-ietf-ace-oauth-authz
Revision:   03
Title:  Authentication and Authorization for Constrained Environments 
(ACE)
Document date:  2016-10-12
Group:  ace
Pages:  56
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-03.txt

Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-03


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments.  The
   framework is based on a set of building blocks including OAuth 2.0
   and CoAP, thus making a well-known and widely used authorization
   solution suitable for IoT devices.  Existing specifications are used
   where possible, but where the constraints of IoT devices require it,
   extensions are added and profiles are defined.




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.

The IETF Secretariat




smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace