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

From: Ludwig Seitz <[email-masked]>
Date: Wed, 12 Oct 2016 13:37:29 +0200

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: [email-masked]
To: Ludwig Seitz <[email-masked]>, Erik Wahlstroem 
<[email-masked]>, Goeran Selander 
<[email-masked]>, Samuel Erdtman <[email-masked]>, 
Hannes Tschofenig <[email-masked]>

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

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 18 Oct 2016 09:34:29 +0100

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 <https://tools.ietf.org/html/rfc7744>
[RFC7744 <https://tools.ietf.org/html/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 <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#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
<https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#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 <https://tools.ietf.org/html/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 <[email-masked]> wrote:

> 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
>
>
> To: Ludwig Seitz <[email-masked]>, Erik Wahlstroem <
> [email-masked]>, Goeran Selander <[email-masked]>,
> Samuel Erdtman <[email-masked]>, Hannes Tschofenig <
> [email-masked]>
>
>
> URL: https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-au
> thz-03.txt
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-03
>
> Abstract:
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>
>

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 19 Oct 2016 07:18:35 +0200

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 <[email-masked]>
wrote:

> I list minor typos and request for clarification/consistency below. Hope
> it helps.
>
> Minor typos:
> ==========
>
fixed

>       ==> “over a different transport”
fixed

>
> Page 8/Section 4: " RFC 7744 <https://tools.ietf.org/html/rfc7744> [RFC7744 <https://tools.ietf.org/html/rfc7744>] describes many different
>
fixed

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

>     ==>  “a commissioning tool”
fixed

>       information about these parameters can be found in in Section 6.4 <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#section-6.4>.”
>
fixed

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

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

>     ==> typo in “COSE_Encrytped”
fixed

>    Section 6.4.5 <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03#section-6.4.5>.”
>
fixed

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

> ==> “r” capital in reference
fixed

>
> Page 30/10.1/profile description: “The communication and communication security profile”
>
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

> ==> Drop the first “to use”
fixed

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

> Page 6/Access Token: "The access token is protected against modifications using a MAC or
>
> Question: Are access tokens also confidentiality protected e.g., encrypted by the AS, to be consumed by RS?
>
> and has acquired an initial access token, right? This seems to be what is described in Page 24.
>
>
> Page 15/Figure 4:
>
> Question: Shouldn’t the example contain the “profile” parameter, which was “REQUIRED” in the response in the previous paragraphs.
>
>
> 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:
>
> Question: Do you mean “this framework” or “this draft”. Just want to be absolutely sure, that profiles MAY define other methods for token transport.
>
>
> Question: There is a type here. “Server” should be “servers” but shouldn’t this be “Resource servers”?
>
>
> 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
>

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 25 Oct 2016 14:58:42 +0200

> I list minor typos and request for clarification/consistency below. Hope
[...]

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:

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

> 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

> Question: Is the grant_type in this example “client_credentials” or
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

> was “REQUIRED” in the response in the previous paragraphs.
Right, that was an oversight.

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

> 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

> shouldn’t this be “Resource servers”?
Yes are right, that was a textual error.

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

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