Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

[Ludwig Seitz]

Sorry for slow answers on that one, holiday time here in Sweden.

Please remove me as a co-author as I will not be able to significantly 
contribute.

/Ludwig

From: Ace  On Behalf Of Ludwig Seitz
Sent: den 14 mars 2023 16:13
To: Ace Wg 
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

Same here: I’m am not aware of any IPR around this. I however need to confirm 
with my new employer that I can be co-author. Will do so ASAP.

/Ludwig

From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Grace A Lewis
Sent: den 14 mars 2023 16:00
To: Sebastian Echeverria 
mailto:sechever...@sei.cmu.edu>>; Marco Tiloca 
mailto:marco.tiloca=40ri...@dmarc.ietf.org>>;
 Daniel Migault mailto:mglt.i...@gmail.com>>; Ace Wg 
mailto:ace@ietf.org>>
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

Hello,

Same for me: I am not aware on IPR on my side and confirm I am willing to 
co-author the document.

Thanks,

Grace Lewis

__
Grace A. Lewis, Ph.D.
Principal Researcher and TAS Initiative Lead
Carnegie Mellon Software Engineering Institute
Software Solutions Division (SSD)
Tactical and AI-Enabled Systems Initiative (TAS)

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851
http://www.sei.cmu.edu/staff/glewis

The most dangerous phrase in the language is “we've always done it this way.” — 
Rear Admiral Grace Hopper


From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Sebastian Echeverria mailto:sechever...@sei.cmu.edu>>
Date: Monday, March 13, 2023 at 6:49 PM
To: Marco Tiloca 
mailto:marco.tiloca=40ri...@dmarc.ietf.org>>,
 Daniel Migault mailto:mglt.i...@gmail.com>>, Ace Wg 
mailto:ace@ietf.org>>
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt
Hello,

I am also not aware of any IPR on our side, and I confirm I’m willing to 
co-author the document.

Thanks,

---
Sebastian Echeverria
Tactical and AI-enabled Systems (TAS)
Software Engineering Institute
Carnegie Mellon University


Sebastian Echeverria

From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Marco Tiloca 
mailto:marco.tiloca=40ri...@dmarc.ietf.org>>
Date: Monday, March 13, 2023 at 3:11 PM
To: Daniel Migault mailto:mglt.i...@gmail.com>>, Ace Wg 
mailto:ace@ietf.org>>
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt
Hi Daniel and all,
On 2023-03-13 18:36, Daniel Migault wrote:
Hi everyone,

This email starts a WGLC for draft-ietf-ace-revoked-token-notification which 
ends on March 27. Please provide your support and feed backs by that time. We 
will take advantage of the IETF116 session to solve any remaining discussions 
on that draft.

I am also looking for someone interested in being the document shepherd: Please 
volunteer!

To the co-authors I am looking at:
- 1) a heads-up regarding the implementations.

==>MT
An implementation from Marco Rasori is available at [1], as building on the 
implementation of the ACE framework at [2]. It is planned to make a pull 
request of [1] onto [2].

[1] https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/

[2] https://bitbucket.org/marco-tiloca-sics/ace-java

<==

- 2) a confirmation that they are or not aware of any IPR

==>MT
I do not have and I am not aware of any IPR on this document.
<==

- 3)  a confirmation that they are willing to co-author the document.

==>MT
I am willing to be a co-author of this document.


Best,
/Marco
<==


Yours,
Logan and Daniel


On Mon, Mar 13, 2023 at 11:36 AM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Authentication and
Authorization for Constrained Environments (ACE) WG of the IETF.

   Title   : Notification of Revoked Access Tokens in the 
Authentication and Authorization for Constrained Environments (ACE) Framework
   Authors : Marco Tiloca
 Ludwig Seitz
 Francesca Palombini
 Sebastian Echeverria
 Grace Lewis
   Filename: draft-ietf-ace-revoked-token-notification-04.txt
   Pages   : 59
   Date: 2023-03-13

Abstract:
   This document specifies a method of the Authentication and
   Authorization for Constrained Environments (ACE) framework, which
   allows an Authorization Server to notify Clients and Resource Servers
   (i.e., registered devices) about revoked Access Tokens.  The method
   allows Clients and Resource Servers to access a Token Revocation List
   on the Authorization Server, with the possible additional use of
   resource observation for the Constrained Application Protocol (CoAP).
   Resulting (unsolicited) notifications of revoked Access Tokens
   complement alternative approaches such as token introspection, while
   not requiring additional en

Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

[Ludwig Seitz]

Same here: I’m am not aware of any IPR around this. I however need to confirm 
with my new employer that I can be co-author. Will do so ASAP.

/Ludwig

From: Ace  On Behalf Of Grace A Lewis
Sent: den 14 mars 2023 16:00
To: Sebastian Echeverria ; Marco Tiloca 
; Daniel Migault ; 
Ace Wg 
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt

Hello,

Same for me: I am not aware on IPR on my side and confirm I am willing to 
co-author the document.

Thanks,

Grace Lewis

__
Grace A. Lewis, Ph.D.
Principal Researcher and TAS Initiative Lead
Carnegie Mellon Software Engineering Institute
Software Solutions Division (SSD)
Tactical and AI-Enabled Systems Initiative (TAS)

4500 Fifth Ave. #5412
Pittsburgh, PA 15213
Phone: (412) 268-5851
http://www.sei.cmu.edu/staff/glewis

The most dangerous phrase in the language is “we've always done it this way.” — 
Rear Admiral Grace Hopper


From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Sebastian Echeverria mailto:sechever...@sei.cmu.edu>>
Date: Monday, March 13, 2023 at 6:49 PM
To: Marco Tiloca 
mailto:marco.tiloca=40ri...@dmarc.ietf.org>>,
 Daniel Migault mailto:mglt.i...@gmail.com>>, Ace Wg 
mailto:ace@ietf.org>>
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt
Hello,

I am also not aware of any IPR on our side, and I confirm I’m willing to 
co-author the document.

Thanks,

---
Sebastian Echeverria
Tactical and AI-enabled Systems (TAS)
Software Engineering Institute
Carnegie Mellon University


Sebastian Echeverria

From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Marco Tiloca 
mailto:marco.tiloca=40ri...@dmarc.ietf.org>>
Date: Monday, March 13, 2023 at 3:11 PM
To: Daniel Migault mailto:mglt.i...@gmail.com>>, Ace Wg 
mailto:ace@ietf.org>>
Subject: Re: [Ace] WGLC draft-ietf-ace-revoked-token-notification-04.txt
Hi Daniel and all,
On 2023-03-13 18:36, Daniel Migault wrote:
Hi everyone,

This email starts a WGLC for draft-ietf-ace-revoked-token-notification which 
ends on March 27. Please provide your support and feed backs by that time. We 
will take advantage of the IETF116 session to solve any remaining discussions 
on that draft.

I am also looking for someone interested in being the document shepherd: Please 
volunteer!

To the co-authors I am looking at:
- 1) a heads-up regarding the implementations.

==>MT
An implementation from Marco Rasori is available at [1], as building on the 
implementation of the ACE framework at [2]. It is planned to make a pull 
request of [1] onto [2].

[1] https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/

[2] https://bitbucket.org/marco-tiloca-sics/ace-java

<==


- 2) a confirmation that they are or not aware of any IPR

==>MT
I do not have and I am not aware of any IPR on this document.
<==


- 3)  a confirmation that they are willing to co-author the document.

==>MT
I am willing to be a co-author of this document.


Best,
/Marco
<==



Yours,
Logan and Daniel


On Mon, Mar 13, 2023 at 11:36 AM 
mailto:internet-dra...@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Authentication and
Authorization for Constrained Environments (ACE) WG of the IETF.

   Title   : Notification of Revoked Access Tokens in the 
Authentication and Authorization for Constrained Environments (ACE) Framework
   Authors : Marco Tiloca
 Ludwig Seitz
 Francesca Palombini
 Sebastian Echeverria
 Grace Lewis
   Filename: draft-ietf-ace-revoked-token-notification-04.txt
   Pages   : 59
   Date: 2023-03-13

Abstract:
   This document specifies a method of the Authentication and
   Authorization for Constrained Environments (ACE) framework, which
   allows an Authorization Server to notify Clients and Resource Servers
   (i.e., registered devices) about revoked Access Tokens.  The method
   allows Clients and Resource Servers to access a Token Revocation List
   on the Authorization Server, with the possible additional use of
   resource observation for the Constrained Application Protocol (CoAP).
   Resulting (unsolicited) notifications of revoked Access Tokens
   complement alternative approaches such as token introspection, while
   not requiring additional endpoints on Clients and Resource Servers.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ace-revoked-token-notification/<https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-revoked-token-notification%2F=05%7C01%7Cmarco.tiloca%40ri.se%7C6e109d1b535245f2de8c08db23e98fd8%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638143258281813215%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL

Re: [Ace] ACE status

[Ludwig Seitz]

Hello Daniel,

Could you also give us an update on draft-ietf-ace-oauth-authz and the related 
profile drafts?
(I have only noticed they are sitting in the RFC-Editor’s queue for some time).

Regards,

Ludwig

From: Ace  On Behalf Of Daniel Migault
Sent: den 23 december 2021 02:09
To: Ace Wg 
Subject: [Ace] ACE status

Hi all,

Just to remind everyone of the current status of the WG:
1. ongoing shepherd writeup for -coap-eap and -key-groupcomm.
2. WGLC for -key-groupcomm-oscore (waiting for reviews)
3. -extended-dtls-authorize / -pubsub-profile are expected to be soon in WGLC
4. revoked-token-notification and oscore-gm-admin are in progress.

Yours,
Logan and Daniel

--
Daniel Migault
Ericsson
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WG Adoption Call for bergmann-ace-extend-dtls-authorize

[Ludwig Seitz]

+1 for adoption.

/Ludwig

From: Ace  On Behalf Of Daniel Migault
Sent: den 9 november 2021 17:35
To: Ace Wg 
Subject: [Ace] WG Adoption Call for bergmann-ace-extend-dtls-authorize

Hi,

This email starts a 2 week Working Group Adoption Call for 
-bergmann-ace-extend-dtls-authorize [1]. Please provide your feedback by 
November 23.

Yours,
Logan and Daniel

[1] https://datatracker.ietf.org/doc/draft-bergmann-ace-extend-dtls-authorize/
--
Daniel Migault
Ericsson
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

This update fixes the IANA registration problems for cti and cnonce with 
respect to the OAuth 2.0 registry, as discussed on the list.

/Ludwig

-Original Message-
From: internet-dra...@ietf.org  
Sent: den 9 november 2021 08:57
To: Erik Wahlstroem ; Goeran Selander 
; Hannes Tschofenig ; 
Hannes Tschofenig ; Ludwig Seitz 
; Samuel Erdtman ; 
ace-cha...@ietf.org
Subject: New Version Notification for draft-ietf-ace-oauth-authz-46.txt


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

Name:   draft-ietf-ace-oauth-authz
Revision:   46
Title:  Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Document date:  2021-11-08
Group:  ace
Pages:  83
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-46.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-46

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
   transforming a well-known and widely used authorization solution into
   a form suitable for IoT devices.  Existing specifications are used
   where possible, but extensions are added and profiles are defined to
   better serve the IoT use cases.


  


The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Progressing draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello ACE (Cc to OAuth designated expert Justin),

The progress of draft-ietf-ace-oauth-authz is currently blocked due to an issue 
that has come to light in the IANA review process, and I'd like to solicit the 
feedback of the WG to determine how to go forward.

The issue is related to parameters used by the AS when responding to an 
Introspection query (see 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#section-5.9.2).
 Our approach so far has been to map all OAuth parameters to ACE and map all 
parameters created for the ACE interaction back to OAuth. The issue is that 
some of the ACE parameters (cnonce and cti, see Figure 16) have the datatype 
"byte string". In OAuth the Introspection parameters are formatted as JSON 
payload, which precludes the use of raw byte strings, a fact we overlooked when 
we tried to register the new parameters in the OAuth registry ( see 
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response).

My proposed fix for this would be to amend the descriptions of these two 
parameters in 5.9.2, specifying that their JSON representation is a text string 
containing the Base64url encoding of the original byte string payload.

Does the working group or the OAuth designated expert have any objections (or 
suggestions) to this approach?

Regards,

Ludwig

--
Ludwig Seitz
Infrastructure Security Analyst
Combitech AB
Djäknegatan 31 . SE-211 35 Malmö . Sweden
Phone: +46 102 160 846
ludwig.se...@combitech.com . combitech.com This e-mail is private and 
confidential between the sender and the addressee. In the event of 
misdirection, the recipient is prohibited from using, copying or disseminating 
it or any information in it. Please notify the above of any such misdirection 
Please consider the environment before printing this e-mail!


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] FW: New Version Notification for draft-ietf-ace-oauth-params-16.txt

[Ludwig Seitz]

Hello ACE,

This update fixes some nits discovered during the review of the IANA actions.

/Ludwig

-Original Message-
From: internet-dra...@ietf.org  
Sent: den 8 september 2021 08:34
To: Ludwig Seitz 
Subject: New Version Notification for draft-ietf-ace-oauth-params-16.txt


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

Name:   draft-ietf-ace-oauth-params
Revision:   16
Title:  Additional OAuth Parameters for Authorization in Constrained 
Environments (ACE)
Document date:  2021-09-07
Group:  ace
Pages:  12
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-oauth-params-16.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-16

Abstract:
   This specification defines new parameters and encodings for the OAuth
   2.0 token and introspection endpoints when used with the framework
   for authentication and authorization for constrained environments
   (ACE).  These are used to express the proof-of-possession key the
   client wishes to use, the proof-of-possession key that the
   Authorization Server has selected, and the key the Resource Server
   uses to authenticate to the client.


  


The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

This version fixes a minor error in -44 ('cti' got accidentally removed as 
Introspection response parameter).

/Ludwig

-Original Message-
From: internet-dra...@ietf.org  
Sent: den 30 augusti 2021 08:17
To: Erik Wahlstroem ; Goeran Selander 
; Hannes Tschofenig ; 
Hannes Tschofenig ; Ludwig Seitz 
; Samuel Erdtman ; 
ace-cha...@ietf.org
Subject: New Version Notification for draft-ietf-ace-oauth-authz-45.txt


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

Name:   draft-ietf-ace-oauth-authz
Revision:   45
Title:  Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Document date:  2021-08-29
Group:  ace
Pages:  83
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-45.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-45

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
   transforming a well-known and widely used authorization solution into
   a form suitable for IoT devices.  Existing specifications are used
   where possible, but extensions are added and profiles are defined to
   better serve the IoT use cases.


  


The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

This update fixes a number of nits identified during the IANA actions review 
and introduces "cti" as Introspection parameter.

/Ludwig

-Original Message-
From: internet-dra...@ietf.org  
Sent: den 25 augusti 2021 08:32
To: Erik Wahlstroem ; Goeran Selander 
; Hannes Tschofenig ; 
Hannes Tschofenig ; Ludwig Seitz 
; Samuel Erdtman ; 
ace-cha...@ietf.org
Subject: New Version Notification for draft-ietf-ace-oauth-authz-44.txt


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

Name:   draft-ietf-ace-oauth-authz
Revision:   44
Title:  Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Document date:  2021-08-24
Group:  ace
Pages:  83
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-44.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-44

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
   transforming a well-known and widely used authorization solution into
   a form suitable for IoT devices.  Existing specifications are used
   where possible, but extensions are added and profiles are defined to
   better serve the IoT use cases.


  


The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Missing Introspection parameter in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello ACE,

Since I haven’t heard an objection, I will go forward and add this to the draft.

Regards,

Ludwig

From: Daniel Migault 
Sent: den 17 augusti 2021 17:25
To: Ludwig Seitz 
Cc: ace@ietf.org
Subject: Re: [Ace] Missing Introspection parameter in draft-ietf-ace-oauth-authz

Thanks Ludwig for raising the question. If anyone has an objection, please 
express your concern by August 24. Expressing support is also more than welcome!

Yours,
Daniel

On Tue, Aug 17, 2021 at 10:24 AM Ludwig Seitz 
mailto:ludwig.se...@combitech.com>> wrote:
Hello ACE,

I want to raise one issue for group comments that has come up in conjunction 
with fixing the IANA nits for draft-ietf-ace-oauth-authz:
In figure 16 we define mappings from OAuth Token introspection parameters to 
CBOR abbreviations. These parameters (should) correspond to the claims that 
could be found in e.g., a CWT.
CWT renamed one token claim, namely 'jti' (JWT ID) into 'cti' for CWT ID. 
However, this is not reflected in the registered Introspection parameters
(https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response)
 where only 'jti' is registered. This was overlooked when we originally defined 
the mappings in figure 16.

I would therefore put the following question to the group:

Does anyone object to this draft adding 'cti' as an OAuth introspection 
parameter?

The corresponding text would go into the list of additional parameters in 
section 5.9.2 and be something along the lines of:
"cti  OPTIONAL.  The CWT ID parameter has the same meaning and processing rules 
as the "jti" parameter defined in section 3.1.2. of [RFC 7662] except that the 
value is a byte string. "

Regards,

Ludwig

--
Ludwig Seitz
Infrastructure Security Analyst
Combitech AB
Djäknegatan 31 . SE-211 35 Malmö . Sweden
Phone: +46 102 160 846
ludwig.se...@combitech.com<mailto:ludwig.se...@combitech.com> . 
combitech.com<http://combitech.com> This e-mail is private and confidential 
between the sender and the addressee. In the event of misdirection, the 
recipient is prohibited from using, copying or disseminating it or any 
information in it. Please notify the above of any such misdirection Please 
consider the environment before printing this e-mail!


___
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace


--
Daniel Migault
Ericsson
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Missing Introspection parameter in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello ACE,

I want to raise one issue for group comments that has come up in conjunction 
with fixing the IANA nits for draft-ietf-ace-oauth-authz:
In figure 16 we define mappings from OAuth Token introspection parameters to 
CBOR abbreviations. These parameters (should) correspond to the claims that 
could be found in e.g., a CWT.
CWT renamed one token claim, namely 'jti' (JWT ID) into 'cti' for CWT ID. 
However, this is not reflected in the registered Introspection parameters
(https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response)
 where only 'jti' is registered. This was overlooked when we originally defined 
the mappings in figure 16.

I would therefore put the following question to the group:

Does anyone object to this draft adding 'cti' as an OAuth introspection 
parameter?

The corresponding text would go into the list of additional parameters in 
section 5.9.2 and be something along the lines of:
"cti  OPTIONAL.  The CWT ID parameter has the same meaning and processing rules 
as the "jti" parameter defined in section 3.1.2. of [RFC 7662] except that the 
value is a byte string. "

Regards,

Ludwig

--
Ludwig Seitz
Infrastructure Security Analyst
Combitech AB
Djäknegatan 31 . SE-211 35 Malmö . Sweden
Phone: +46 102 160 846
ludwig.se...@combitech.com . combitech.com This e-mail is private and 
confidential between the sender and the addressee. In the event of 
misdirection, the recipient is prohibited from using, copying or disseminating 
it or any information in it. Please notify the above of any such misdirection 
Please consider the environment before printing this e-mail!


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Nits in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello Ace,

I'm currently dealing with some nits in draft-ietf-ace-oauth-authz that I have 
discovered during the final IANA check. For one of them I need group feedback: 

The draft defines a CBOR abbreviation for the Introspection parameter 'cti' 
which is the CWT identifier defined in RFC 8392, however it turns out that 
parameter was never defined as Introspection response parameter, it only exists 
as CWT claim.

 Can this draft just add 'cti' to the OAuth Token Introspection Response 
parameters without affecting the progress of the draft at this stage?


(For those interested, the other nits are: 1. Inconsistent IANA tables where 
some had the column "Original Specification" and some didn't for the CBOR
abbreviation mappings, 2. An obsolete reference that needed to be updated in an 
IANA entry).

/Ludwig



--
Ludwig Seitz
Infrastructure Security Analyst
Combitech AB
Djäknegatan 31 . SE-211 35 Malmö . Sweden
Phone: +46 102 160 846
ludwig.se...@combitech.com . combitech.com This e-mail is private and 
confidential between the sender and the addressee. In the event of 
misdirection, the recipient is prohibited from using, copying or disseminating 
it or any information in it. Please notify the above of any such misdirection 
Please consider the environment before printing this e-mail!


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

This draft update contains the following changes:

1. Clarification by Hannes on OAuth 2.0 description about sending tokens with 
each request
2. Clarification that CBOR is RECOMMENDED even for non-CoAP interactions
3. Clarification of the profile combining text (Thank you Olaf for the final 
text proposal!)

/Ludwig

-Original Message-
From: internet-dra...@ietf.org  
Sent: den 10 juli 2021 21:51
To: Erik Wahlstroem ; Goeran Selander 
; Hannes Tschofenig ; 
Hannes Tschofenig ; Ludwig Seitz 
; Samuel Erdtman ; 
ace-cha...@ietf.org
Subject: New Version Notification for draft-ietf-ace-oauth-authz-43.txt


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

Name:   draft-ietf-ace-oauth-authz
Revision:   43
Title:  Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Document date:  2021-07-10
Group:  ace
Pages:  83
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-43.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-43

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
   transforming a well-known and widely used authorization solution into
   a form suitable for IoT devices.  Existing specifications are used
   where possible, but extensions are added and profiles are defined to
   better serve the IoT use cases.


  


The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Ludwig Seitz]

Olaf's compromise text looks OK to me. If no one objects I'll submit this later 
today. 

/Ludwig 

Sent from my smartphone

 Olaf Bergmann wrote 

>Hi Carsten, Ludwig,
>
>I think removing the discussed is not an option as the whole discussion
>was about "something needs to be said" but not being clear about what
>this is.
>
>On 2021-07-10, Carsten Bormann  wrote:
>
>> Maybe we can combine these two into one sentence that covers a common 
>> requirement?
>
>The result would be text that makes a profile document its security
>requirements and a new profile that combines existing profiles to
>document how the combination meets these requirements.
>
>From Francesca's previous proposal and your previous proposals this
>could be:
>
>NEW^n+1:
>
>   There may be use cases where different transport and security
>   protocols are allowed for the different interactions, and, if that is
>   not explicitly covered by an existing profile, it corresponds to
>   combining profiles into a new one.  For example, a new profile could
>   specify that a previously-defined MQTT-TLS profile is used between
>   the client and the RS in combination with a previously-defined
>   CoAP-DTLS profile for interactions between the client and the AS. The
>   new profile that combines existing profiles MUST specify how the
>   existing profiles' security properties are achieved. Any profile
>   therefore MUST clearly specify its security requirements and MUST
>   document if its security depends on the combination of various
>   protocol interactions.
>
>Grüße
>Olaf
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Ludwig Seitz]

Hello Francesca, Carsten,

Sorry but I do not like what you did in the first sentence. Combining profiles 
does not necessarily equate to creating a new one, and I still don't see why we 
should needlessly request that it be so. Given an example use case where a 
client talks dtls-profile to the AS and gets token and parameters for an 
oscore-profile back for the client-RS leg, why should there be a need for a new 
profile to support this?

I also do not like that you removed the requirement to design profiles so that 
the security for the different legs of the communication (C-AS, C-RS, RS-AS) 
stands on its own.
What could happen now is that someone designs clever protocol foo that has a 
dependency between the C-AS and the C-RS communication for its security, and 
thus breaks when it is used on only one leg of this communication. I don't 
think you need to know all possible future profiles to design yours to be 
secure in that way. Note that the framework puts requirements on the security 
of future profiles, so you can assume e.g., that communication will be secure.

I propose the following alternative for discussion:

NEW^4:
There may be use cases where the transport and security protocols defined by 
different profiles are used for different steps of the same authorization flow. 
For example, an implementation could use the CoAP-DTLS profile for interactions 
between the client and the AS, obtaining the token and parameters for an 
OSCORE-profile interaction with the RS.
The security of a profile MUST NOT depend on the assumption that this profile 
is used in all steps of the authorization flow (C-AS, C-RS, RS-AS). 


/Ludwig

-Original Message-
From: Francesca Palombini  
Sent: den 5 juli 2021 18:59
To: Carsten Bormann 
Cc: Ludwig Seitz ; Daniel Migault 
; Cigdem Sengul ; Göran Selander 
; ace-cha...@ietf.org; ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on 
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hi Carsten,

I like your proposals! I changed a "define" to "specify" to remove some 
repetition, so finally the text change would be the following:

OLD:
   There may be use cases were different profiles of this framework are
   combined.  For example, an MQTT-TLS profile is used between the
   client and the RS in combination with a CoAP-DTLS profile for
   interactions between the client and the AS.  The security of a
   profile MUST NOT depend on the assumption that the profile is used
   for all the different types of interactions in this framework.

NEW:
   There may be use cases where different transport and security protocols
   are allowed for the different interactions , and, if that is not explicitly 
   covered by an existing profile, it corresponds to combining profiles into a 
new one.
   For example, a new profile could specify that a previously-defined MQTT-TLS 
profile is used between the
   client and the RS in combination with a previously-defined CoAP-DTLS profile 
for
   interactions between the client and the AS. It is REQUIRED of the new 
profile to specify the
   combination and to make sure interoperability and security properties are 
achieved.
   A profile MAY want to prepare for being combined with others by clearly 
specifying 
   its security requirements.


Francesca

On 05/07/2021, 16:36, "Carsten Bormann"  wrote:

On 2021-07-05, at 16:15, Carsten Bormann  wrote:
> 
> The last sentence is kind of obvious (I hope that the same applies to 
non-combined profiles), but Section 6.7 is short, so a little superfluity does 
not hurt.

In offline communication, I have been reminded that adding this sentence 
would appear to be appropriate :-)

NEWNEWNEW:
A profile MAY WANT TO prepare for being combined with others by clearly 
specifying its security requirements.

(Using an RFC 6919 keyword.)  I wish I didn’t have the strong feeling that 
this sentence may actually be required.

Grüße, Carsten


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Ludwig Seitz]

Hello Carsten,

Can you clarify what exactly you consider is broken and why?

I was indeed trying to attach the 'when' to both arms (token encoding and 
protocol message payload encoding), but I don't have a strong opinion on this. 
If the WG can decide how this should be I will implement.

/Ludwig

-Original Message-
From: Carsten Bormann  
Sent: den 9 juni 2021 09:15
To: Ludwig Seitz 
Cc: Francesca Palombini ; Seitz Ludwig 
; The IESG ; art-...@ietf.org; 
ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on 
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)


> In 2021-06-09, at 08:42, Ludwig Seitz  wrote:
> 
> " ... size.  Self-contained tokens and protocol message payloads are encoded 
> in CBOR when CoAP is used.”

This is not what the old NEW text says.

(The new NEW text attaches the “when” to both arms.)

The whole idea of attaching the representation choice to the protocol choice is 
broken, but if we pursue it, we at least need to make the logic clear.

(1) If you use CoAP, you use CBOR for protocol message payloads.
(2) Self-contained tokens use CBOR.
(3) No other hard limitations are implied, but of course CBOR is the format of 
choice to maximize interoperability, so deviations from that need to be 
justified.

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

This update fixes the outstanding issues related to: 
https://mailarchive.ietf.org/arch/msg/ace/mrVrwJGreSSE2yNJK1uPW0P7p0o/

/Ludwig

-Original Message-
From: internet-dra...@ietf.org  
Sent: den 9 juni 2021 08:49
To: Erik Wahlstroem ; Goeran Selander 
; Hannes Tschofenig ; 
Hannes Tschofenig ; Ludwig Seitz 
; Samuel Erdtman ; 
ace-cha...@ietf.org
Subject: New Version Notification for draft-ietf-ace-oauth-authz-42.txt


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

Name:   draft-ietf-ace-oauth-authz
Revision:   42
Title:  Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)
Document date:  2021-06-08
Group:  ace
Pages:  82
URL:
https://www.ietf.org/archive/id/draft-ietf-ace-oauth-authz-42.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-42

Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and the Constrained Application Protocol (CoAP), thus
   transforming a well-known and widely used authorization solution into
   a form suitable for IoT devices.  Existing specifications are used
   where possible, but extensions are added and profiles are defined to
   better serve the IoT use cases.


  


The IETF Secretariat


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Ludwig Seitz]

Hello Francesca,

Comments inline. Update will be posted shortly.

/Ludwig

-Original Message-
From: Francesca Palombini  
Sent: den 10 maj 2021 20:42
To: Seitz Ludwig ; The IESG 
Cc: art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; 
ace@ietf.org
Subject: Re: [EXTERNAL] [Ace] Francesca Palombini's Discuss on 
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)


Hi Ludwig, authors,

Thank you for all the work on the document.

I have checked all my comments (including those that you have addressed in v-39 
and not reported below), and I am good with almost all of them.

Considering the clarifications added as a response to my comments regarding 
CoAP using CBOR encoding, and HTTP using the encoding from OAuth 2.0, I believe 
the document is now in good shape and not confusing anymore. I understand that 
when CoAP is used, CBOR MUST be used; when HTTP is used, semantics and 
encodings of OAuth 2.0 MUST be used. Any other encodings/transport protocol 
would have to be defined by a different specification.

Regarding my request for clarification on mixing different protocols 
(HTTP/CoAP) on different legs of the exchange, I understand that it is not in 
scope of this document, and it would rather be up to the profile defining such 
a mix to motivate and explain the use case, so I am fine with it.

Your clarifications on the use of HTTP also addresses my last DISCUSS point - a 
new media type is not required, as the framework now effectively reuses OAuth 
2.0 encodings. Any other specification (such as MQTT) which aims to use the 
JSON equivalent of what defined here for CBOR instead of the OAuth encoding 
will define and register their own media type.

I hope we can discuss the leftover comments (especially the last point about 
using several profiles together) at the interim tomorrow. However, these are 
non-blocking points, so I will go ahead and remove my DISCUSS now.

Thanks again,
Francesca

>Hello Francesca,
>
>Thank you for your review, sorry for the long response time.
>
>Version -39 addresses some of your comments
>https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-39
>
>I have replies on the remaining comment as follows below (prefixed with 
>'LS:')
>
>Regards,
>
>Ludwig
>
>1. -
>
>   sufficiently compact.  CBOR is a binary encoding designed for small
>   code and message size, which may be used for encoding of self
>   contained tokens, and also for encoding payloads transferred in
>   protocol messages.
>
>FP: "may be used" make it seem as if CBOR is always optional (even when 
>CoAP is used). See points 11. and 13. for examples of text that seem to 
>imply that CBOR is mandatory in some cases.
>
>LS: This is a lower-case "may", so it does not have a normative meaning.
>There are indeed cases where CBOR is mandatory (e.g. when CoAP is used).
>

FP: Lower case "may" only makes it so that the corresponding text is not 
"required for interoperation or to limit behavior which has potential for 
causing harm" (to quote BCP 14). Even without its BCP 14 normative meaning, the 
text hinted that CBOR is optional IMO, which is misleading. I would suggest the 
following:

OLD:
   sufficiently compact.  CBOR is a binary encoding designed for small
   code and message size, which may be used for encoding of self
   contained tokens, and also for encoding payloads transferred in
   protocol messages.

NEW:
   sufficiently compact.  CBOR is a binary encoding designed for small
   code and message size. CBOR is used when CoAP is used for encoding of self
   contained tokens, and also for encoding payloads transferred in
   protocol messages.

This should go with the direction you point out below for CoAP implies CBOR, 
HTTP implies whatever OAuth 2.0 defined.

[LS] I don't like the "is used ... is used" in your suggestion. I'll rephrase 
it to 
" ... size.  Self-contained tokens and protocol message payloads are encoded in 
CBOR when CoAP is used."


>9. -
>
>   parameters.  When profiles of this framework use CoAP instead, it is
>   REQUIRED to use of the following alternative instead of Uri-query
>   parameters: The sender (client or RS) encodes the parameters of its
>   request as a CBOR map and submits that map as the payload of the POST
>   request.
>
>FP: I think it should be better defined (or at least hinted in this 
>paragraph) the mapping between the CBOR encoded parameters and the Uri-query 
>parameters:
>are they all encoded as CBOR text strings?
>
>LS: The encoding depends on the type of the parameter and is described 
>for each parameter individually

FP: I think it makes sense here to state that this document describes the CBOR 
encoding for the existing parameters, and that if a document needs any other 
parameters (defined in OAuth by a future document) then the encoding for Ace 
needs to be specified by that document as well. This is just to clarify that 
you can't just use OAuth parameters with CoAP.

LS: Ok I'll add more text to 

Re: [Ace] [IANA #1158953] Requested review for IANA registration in draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

[Ludwig Seitz]

On 2020-02-26 00:58, Amanda Baber via RT wrote:

Ludwig, Hannes,

Can you confirm that you can make the CBOR Web Token Claim change
requested below?

We also have Chuck Mortimore listed as an expert for this registry,
but our message to his Salesforce address bounced.

Best regards,

Amanda Baber Lead IANA Services Specialist



I strongly disagree with the assessment that the scope claim should be
pushed into the two-byte range.

The reason we introduced the scope claim is that an ACE RS typically
does not have a direct connection to the AS, and is therefore unable to
retrieve the scope of an access token from other sources than the access
token itself.  I therefore assert that ACE access tokens would often
need to contain this claim in order to inform the RS.
Since one of the major drivers of the ACE work has been to reduce the
authorization overhead (otherwise we could just have used vanilla OAuth
2.0), I find it strange to needlessly add to the overhead by making the
encoding of a frequently used claim longer than necessary.

I am willing to listen to the arguments that have lead the expert
reviewer to denying a value in the one-byte range, and discuss the
reasoning further on list.

Regards,

Ludwig



On Tue Feb 18 22:42:22 2020, michael.jo...@microsoft.com wrote:

I'm mostly OK with these registrations, however, DO NOT assign the
value 9 to "scope".   Rather, please put it in the two-byte range
- for instance, with the value 41.

-- Mike

-Original Message- From: Cwt-reg-review
 On Behalf Of Sabrina Tanamal via
RT Sent: Tuesday, February 18, 2020 1:06 PM Cc:
cwt-reg-rev...@ietf.org Subject: [EXTERNAL] [Cwt-reg-review] [IANA
#1158953] Requested review for IANA registration in
draft-ietf-ace-oauth-authz (cwt - CBOR Web Token Claims)

Hi all,

Resending this request for draft-ietf-ace-oauth-authz.

Thanks,

Sabrina Tanamal Senior IANA Services Specialist


On Sat Dec 21 11:37:11 2019, ludwig_se...@gmx.de wrote:

Hello CWT registry reviewers,

the IESG-designated experts for the CWT claims registry have
asked me to send a review request to you about the claims
registered here:

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fto



ols.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-authz-29%23section-

8.13
mp;data=02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad74269c3



c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63717656

7656665548sdata=r01W5Bx0gJh9ZPH8eNS%2BY765CnGq11DkknsHYQ751Dk%3



Dreserved=0


Thank you in advance for you review comments.

Regards,

Ludwig



___ Cwt-reg-review
mailing list cwt-reg-rev...@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcwt-



reg-

reviewdata=02%7C01%7CMichael.Jones%40microsoft.com%7Ce23f64ac1ad74269c3c408d7b4b65d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176567656675543sdata=XxBhQmqxGkCRiBxh0PdhX2IJD8TnbwWl%2Feo8VUsHOsg%3Dreserved=0




___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-oauth-params-12.txt

[Ludwig Seitz]

Hello ACE,

this update (together with an upcoming update of
draft-ietf-ace-oauth-authz) fixes the issues raised by Brian Campbell.

Please review the new section 7. (Requirements when using asymmetric
keys) to see if you agree with the reasoning proposed therein.

Regards,

Ludwig


On 2020-02-01 12:01, internet-dra...@ietf.org 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 WG of the IETF.

 Title   : Additional OAuth Parameters for Authorization in 
Constrained Environments (ACE)
 Author  : Ludwig Seitz
Filename: draft-ietf-ace-oauth-params-12.txt
Pages   : 11
Date: 2020-02-01

Abstract:
This specification defines new parameters and encodings for the OAuth
2.0 token and introspection endpoints when used with the framework
for authentication and authorization for constrained environments
(ACE).  These are used to express the proof-of-possession key the
client wishes to use, the proof-of-possession key that the
Authorization Server has selected, and the key the Resource Server
uses to authenticate to the client.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oauth-params-12
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-12


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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [Jwt-reg-review] Requested review for IANA registration in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 2020-01-13 22:01, Brian Campbell wrote:

Thanks for the updates Lugwig,

Section 6.6. does propose one mitigation for the unbounded memory growth
problem. However, it relies on the AS to do pretty specific things with
the content of other claims for it to even be possible for an RS to
perform the mitigation approach. Do you think, for interoperability, it
needs to be more prescriptive? Like maybe requiring the cti/jti claim
with specific content and characteristics when exi is present or
embedding/encoding that sequence number in the value of the exi itself
alongside the lifetime of the token.




This sounds like a reasonable requirement. I'm even inclined to make
that a MUST and not just a SHALL. Next update coming soon.

/Ludwig


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

[Ludwig Seitz]

On 2019-12-22 19:27, elwynd wrote:

Hi, Ludwig.

Having had another look at section 3.1 of
draft-ietf-ace-cwt-proof-of-possession, technically the rules about
which keys have to be present are not part of the syntax of the cnf
claim.  The point can be covered by changing '"syntax of the 'cnf' claim"
to "syntax and semantics of the 'cnf' claim"
in each case.

However, the second look threw up another point:  Figure 2 in s3.2 gives
a Symetric key example  - I think this should use an Encrypted_COSE_Key
(or Encrypted_COSE_Key0) as described in section 3.3 of
draft-ietf-ace-cwt-proof-of-possession.

Otherwise I think we are done.

Eventually we will get to Christmas!

Cheers,
Elwyn




Hello Elwyn,

I hope you had a merry Christmas and a happy new year's eve.

I have updated the draft to -10, fixing the phrasing to your suggestion
from the first paragraph above in various places (and an issue that came
up during IANA review).

Given my argument for not having the encrypted COSE_Key in figure 2 I
left that part as it was. Please indicate whether this is acceptable
with the given explanation.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Ludwig Seitz]

On 2019-12-23 22:32, Brian Campbell wrote:

The OAuth Token Introspection Response registry

already has an entry for "cnf", which makes the first request in
https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4
rather problematic.



OAuth beats us on the finish line again :-(

I have updated the draft to remove the registration and refer to the
MTLS draft.

/Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Genart last call review of draft-ietf-ace-oauth-params-06

[Ludwig Seitz]

Hello Elwyn,

I have now submitted -09 to fix the minor issues and nits, which I
forgot in my -08.

Comments inline.


Regards,

Ludwig


On 2019-12-14 23:46, Elwyn Davies via Datatracker wrote:


Minor issues:
ss3.1, 3.2 and 4.1:  The COSE_Key type 'EC' used in several kty fields is not
defined.  I assume it should be 'EC2'.


Fixed


ss3.1, 3.2 and 4.1:  Does it matter that the definitions of the x and y
parameters in an EC2 key are given as 'h' encodings in RFC8152 but are given as
'b64' in this document?  I am very much not an expert here.


All changed to 'h' encoding


s6: This section starts with 'If CBOR is used...': The main ACE draft
draft-ietf-ace-oauth-authz is apparently intended to cover both JSON and CBOR
encodings of payloads, although CBOR is recommended.  This is not made explicit
in this addition to that specification and the use of CBOR diagnostic
representation and the prominence of COSE_Key items could make it appear up
until s6 that this specification is intended just for CBOR encoding.  A few
words at the beginning would clarify the dual alternatives.


Added a paragraph in the introduction to clarify this.



Nits/editorial comments:
General: s/e.g./e.g.,/ (3 places)


Fixed


Abstract, 2nd sentence: s/whishes/wishes/


Fixed

Abstract: Need to expand AS and RS.

s2:  RS, AS and (probably) various other terms are defined in RFC 6749 and need
to be expanded on  first use.  Adding something like the para from
draft-ietf-ace-oauth-authz would solve this (except for the abstract).


I added a sentence in the terminology section to clarify this. However
note that it already said (in -06):

   Readers are assumed to be familiar with the terminology from
   [I-D.ietf-ace-oauth-authz].

Which included the terms AS and RS.



s3:  This section needs a reference to RFC 8152 for the specification of the
CWT COSE_Key item that is used extensively.


Done



s3/s4: Some introductory text for each section is desirable.


Done


s3.1, para 2 (definition of req_cnf):: Possibly add a note that the
recommendation against symmetric keys implies currently kty being 'Symmetric'.
Will it ever be anything else?


Done


s3.1:  The text in s3.2 of draft-ietf-ace-cwt-proof-of-possession-03 contans
the following

The COSE_Key MUST contain the required key members for a COSE_Key of that
key type and MAY contain other COSE_Key members, including the "kid" (Key
ID) member.

The "COSE_Key" member MAY also be used for a COSE_Key representing a
symmetric key, provided that the CWT is encrypted so that the key is not
revealed to unintended parties. The means of encrypting a CWT is explained
in [RFC8392]. If the CWT is not encrypted, the symmetric key MUST be
encrypted as described in Section 3.3.

These riders probably apply to all the subsectons of s3 and to s4.1 and could
be included in the currently empty main section text.



Here I disagree. The text explicitly refers to
draft-ietf-ace-cwt-proof-of-possession, saying that the contents of the
'cnf', 'req_cnf' and 'rs_cnf' parameters use the syntax of the 'cnf'
claim from section 3.1 of draft-ietf-ace-cwt-proof-of-possession.
The requirements in section 3.2 draft-ietf-ace-cwt-proof-of-possession
follow from the use of the definitions in 3.1.

I don't see the value of reiterating such a long text from that document
here, when an explicit reference is already given.



s4.1, rs_cnf - DTLS-RPK: This term needs a reference (RFC 7250). Also all other
uses do not hyphenate and RPK needs to be expanded.
s/DTLS-RPK handshake/DTLS Raw Public Key (RPK) handshake [RFC7250]/

Done

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [Gen-art] Genart last call review of draft-ietf-ace-oauth-params-06

[Ludwig Seitz]

On 2019-12-19 21:23, elwynd wrote:

Hi, Ludwig.

Thanks for the prompt response.

Regarding he major issue, I understand what the intention of the split
was, but as far as early implementations are concerned, there is no such
thing as a 'minimal breakage'; unless there is some cunning mechanism in
the basic ace-oauth-authz protocol, changes to the structure of the
items defined here will break the protocol.  One possibility that I
could see is the addition of extra keys in the COSE_Key dictionary
structure: In this case you could add some extra words (in the
ace-oauth-authz document) to indicate that unrecognized keys should be
ignored.  This is associated with the editorial comments I made about
s3.1 that would allow any other keys to be present in the COSE_Key
object structure.  Similarly, the obects defined here are effectively
JSON/CBOR dictionaries.  The changes could be accomodated by adding
comments in ace-oauth that extra keys in the items defined would be
ignored.

In my opinion, it would be best to remove the comments about possible
changes and just state that they have been separated out because they
might be used in other contexts.  The possible 'changes to the
definitions' issue is just a matter of 'institutional memory'.  If there
is some mechanism, such as I mentioned above, to accommodate changes
without neeeding an update to the ace-oauth-authz (or other protocols
using these items), this should be explained.


I have submitted an updated draft (-08) that removes the comments about
possible changes. Does this address your major issue?



Regarding the h vs b64 representations, since they are only examples
(and the strings are essentially arbitrary as the actual keys aren't in
the document), I'd be inclined to put in h representations to avoid my
question arisng.


In my newly submitted draft all the b64 representations have been
replaced by equivalent h representations.

Note that none of these strings are arbitrary, since they do parse to
actual keys. The abbreviated b64 strings representing tokens obviously
do not parse as such, but come from the actual binary representation of
tokens.

Happy holidays,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Requested review for IANA registration in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello CWT registry reviewers,

the IESG-designated experts for the CWT claims registry have asked me to
send a review request to you about the claims registered here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.13

Thank you in advance for you review comments.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello JWT registry reviewers,

the IESG-designated experts for the JWT claims registry have asked me to
send a review request to you about the claims registered here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.12

Thank you in advance for you review comments.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Requested review for IANA registration in draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello OAuth registry reviewers,

the IESG-designated experts for the OAuth parameters registry have asked
me to send a review request to you about the OAuth parameters registered
here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.2

and here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.5

and here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.8

and here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-29#section-8.10


Thank you in advance for you review comments.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] FW: [IANA #1157486] Last Call: (Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)) to Proposed

[Ludwig Seitz]

From: Sabrina Tanamal via RT 
Subject: [IANA #1157486] Last Call:  
(Authentication and Authorization for Constrained Environments (ACE) using the OAuth 
2.0 Framework (ACE-OAuth)) to Proposed Standard

(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of 
draft-ietf-ace-oauth-authz-27. If any part of this review is inaccurate, please 
let us know.

The IANA Functions Operator has a question about one of the actions requested 
in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, 
there are fifteen actions which we must complete.

NOTE: We’re asking the ADs how to handle the registrations for which Hannes is 
the only reviewer.

IANA Question --> Several sections of the current draft propose to create new 
registries (Sections 8.1, 8.3, 8.4, 8.6, 8.7, 8.9, and 8.11). For each of these 
requests, IANA asks the authors where the new registries are to be located. Should 
they be added to an existing registry page? If not, do they belong in an existing 
category at http://www.iana.org/protocols? For each of the new registries, it is 
not clear from the context of the request where the new registries should be 
established.


Hello WG chairs (WG and ADs in cc),

I am in need of some guidance here due to my lack of experience in IANA
matters.

Do we want to establish a new protocol page for ACE in the IANA registries?

Alternatively we could add them to the OAuth pages under a specific ACE
section.

Regards,
Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Ludwig Seitz]

Hello OAuth registry reviewers,

the IESG-designated experts for the OAuth parameters registry have asked
me to send a review request to you about the OAuth parameters registered
here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.3

and the OAuth introspection response parameters registered here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.4

Thank you in advance for you review comments.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Ludwig Seitz]

Hello CWT registry reviewers,


the IESG-designated experts for the CWT claims registry have asked me to
send a review request to you about the "rs_cnf" claim registered here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.2

Thank you in advance for you review comments.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

[Ludwig Seitz]

Hello JWT registry reviewers,

the IESG-designated experts for the JWT claims registry have asked me to
send a review request to you about the "rs_cnf" claim registered here:

https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07#section-9.1

Thank you in advance for you review comments.

Regards,

Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-oauth-params-07.txt

[Ludwig Seitz]

Hello ACE,

this update is just to correct my affiliation and contact email. No
other changes should be made here.

/Ludwig


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 WG of the IETF.

 Title   : Additional OAuth Parameters for Authorization in 
Constrained Environments (ACE)
 Author  : Ludwig Seitz
Filename: draft-ietf-ace-oauth-params-07.txt
Pages   : 13
Date: 2019-12-17

Abstract:
This specification defines new parameters for the OAuth 2.0 token and
introspection endpoints when used with the framework for
authentication and authorization for constrained environments (ACE).
These are used to express the proof-of-possession key the client
whishes to use, the proof-of-possession key that the AS has selected,
and the key the RS should use to authenticate to the client.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oauth-params-07
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-params-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-params-07


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
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello Ace,

this update addresses the Genart review kindly provided by Stewart Bryant.

/Ludwig


On 2019-12-14 17:37, internet-dra...@ietf.org 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 WG of the IETF.

 Title   : Authentication and Authorization for Constrained 
Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 Authors : Ludwig Seitz
   Goeran Selander
   Erik Wahlstroem
   Samuel Erdtman
   Hannes Tschofenig
Filename: draft-ietf-ace-oauth-authz-29.txt
Pages   : 87
Date: 2019-12-14



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27

[Ludwig Seitz]

On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote:



Abstract

This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE-
OAuth.  The framework is based on a set of building blocks including
OAuth 2.0
SB> OAuth 2.0 needs a RFC or other reference


I'm now in the process of posting -29 including the updates you
suggested. The idnits tool complains that the abstract should not
contain references, so I'm rolling back those changes.
There is a reference to the RFCs of OAuth and CoAP at first mention in
the text body.

/Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Genart last call review of draft-ietf-ace-oauth-authz-27

[Ludwig Seitz]

On 2019-12-12 21:44, Stewart Bryant via Datatracker wrote:

Reviewer: Stewart Bryant
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.



Thank you Stewart for this review, comments inline.

Note that the posting of an update draft might be a bit delayed due to
issues with my affiliation change. You can inspect my edits here
meanwhile: https://github.com/ace-wg/ace-oauth

/Ludwig




Nits/editorial comments:

Abstract

This specification defines a framework for authentication and
authorization in Internet of Things (IoT) environments called ACE-
OAuth.  The framework is based on a set of building blocks including
OAuth 2.0
SB> OAuth 2.0 needs a RFC or other reference
=
and CoAP,


Both fixed



SB> CoAP is not in the list of well-known abreviations and needs expanding


Fixed



thus transforming a well-known and widely used
authorization solution into a form suitable for IoT devices.
Existing specifications are used where possible, but extensions are
added and profiles are defined to better serve the IoT use cases.

While prior work on authorization solutions for the Web and for the
mobile environment also applies to the Internet of Things (IoT)
environment, many IoT devices are constrained, for example, in terms
of processing capabilities, available memory, etc.  For web
applications on constrained nodes, this specification RECOMMENDS the
use of CoAP [RFC7252] as replacement for HTTP.

SB> Please expand CoAP


Fixed

===
A detailed treatment of constraints can be found in [RFC7228], and

SB> I think you should provide a short context on "constraints"


I added a reference to Appendix A which does just that.



the different IoT deployments present a continuous range of device
and network capabilities.  Taking energy consumption as an example:
At one end there are energy-harvesting or battery powered devices
which have a tight power budget, on the other end there are mains-
powered devices, and all levels in between.
===

More detailed, interoperable specifications can be found in profiles.
SB> What do you mean by "profiles" as a word on its own?


I added some clarification



A third building block is CBOR [RFC7049],
SB> CBOR needs to be expanded on first use.


Fixed



   HTTP, HTTP/2, QUIC, MQTT, Bluetooth Low Energy, etc., are also
   viable candidates.

SB> These really need references
SB> Except for HTTP the abreviations need expanding on first use.


Done, note that there does not seem to be an expansion for QUIC.


=

In this example, the attribute AS points the receiver of this message
to the URI "coaps://as.example.com/token" to request access
permissions.  The originator of the AS Request Creation Hints payload
(i.e., RS) uses a local clock that is loosely synchronized with a
time scale common between RS and AS (e.g., wall clock time).
Therefore, it has included a parameter "nonce" (see Section 5.1.2.1).

SB> I think the above text could usefully be re-worded for clarity.
SB> The "therefore" does not seem to follow the preceeding text.


I rephrased this to hopefully improve readability and clarify the
"therefore" (and s/nonce/cnonce).



o  A RS sending a "cnonce" parameter in an an AS Request Creation
SB> An RS...


This doesn't feel right, since there is no consonant in RS and the R in
"Resource Server" (the expansion of RS) is not silent either. Is there a
grammar rule that I'm unaware of?

You did however make me aware of a typo later in that sentence where
there it says: "an an".

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

this update addresses the Secdir review kindly provided by Stephen Kent.

/Ludwig

PS: Please note my changed affiliation and email address in case you
want to email me off-list.

On 2019-12-14 17:04, internet-dra...@ietf.org 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 WG of the IETF.

 Title   : Authentication and Authorization for Constrained 
Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 Authors : Ludwig Seitz
   Goeran Selander
   Erik Wahlstroem
   Samuel Erdtman
   Hannes Tschofenig
Filename: draft-ietf-ace-oauth-authz-28.txt
Pages   : 87
Date: 2019-12-14



___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Secdir last call review of draft-ietf-ace-oauth-authz-27

[Ludwig Seitz]

On 2019-12-08 19:18, Stephen Kent via Datatracker wrote:

Reviewer: Stephen Kent
Review result: Has Issues

SECDIR review of draft-ietf-ace-oauth-authz-27

The summary of the review is almost ready, but needs some revisions.

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.



Thank you for your helpful review Stephen. I have some follow-up
questions inline.

I will submit a draft update as soon as possible, note that this may be
delayed by my affiliation change.

Regards,

Ludwig



This is a long document- 86 pages! It is a proposal for how to use OAuth 2.0
and CoAP to provide authorization security for Internet of Things (IoT)
devices. IoT devices are often criticized as not being very secure, so this
seems like a useful initiative. RFC 7228 (Technology for Constrained-Node
Networks, and Informational document) is cited as inspiration and reference for
this work. CoAP (RFC 7252) is expressly designed for the sort of environment
that characterizes many IoT devices, hence is seems a natural choice for this
authorization-focused framework. OAuth is not as obvious a candidate building
block in this context, e.g., it is expressly designed for the HTTP context, yet
CoAP is cited as the replacement for HTTP. This document adapts OAuth for the
CoAp context.


As Ben stated the ACE WG has had extensive discussions on which solution
to choose, and the OAuth model has the advantage of being able to
temporally decouple the authorization decision from the actual resource
access, which enables several use cases involving devices with
intermittent connectivity (note that several other proposals had the
same design property). Furthermore the possible re-use of OAuth
specifications was seen as favorable when the final decision was made to
go forward with this solution.



This document has an extensive, 6-page Security Considerations section,
appropriate for a document specifying an authorization framework. It begins by
citing the OAuth 2.0 specification, the OAuth 2.0 threat model (RFC 6819), and
OAuth 2.0 Token Introspection (RFC 7662).  All three of these documents are
relevant, and they contain substantial Security Consideration sections.

Section 6.1 deals with security for the tokens that are transmitted to convey
authorization information. In general the requirements and advice provided here
are good; I would prefer to see the admonition against use of a shared secret
key for a group of serves to be a MUST NOT, as opposed to just NOT RECOMMENDED.


Ok, will fix.


I am not convinced that the suggestion for short lifetime tokens is necessary;
we have seen how short duration certificate lifetimes and frequent CRL issuance
in PKI contexts often is neither required nor advisable.


In constrained environments with intermittent connectivity, short token
lifetime is seen as an advantage, as it might be hard to convey
revocation decisions or other changes of access rights to offline
devices. The short token lifetime limits the window of exposure, if a
token and the corresponding proof-of-possession credentials get stolen.
I would therefore prefer to keep that paragraph as it is.


This section ends by
noting that only client-initiated revocation of tokens is addressed by RFC
7009. The authors note that revocation of long lifetime token remains an open
issue. If this is likely to be a common case for IoT devices, leaving this as a
TBD is not great.


The situation is the same as for OAuth 2.0. The short token lifetime is
often given as an explanation why a revocation mechanism is not really
needed.
We have however submitted a proposal for a revocation mechanism in
https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notification



Section 6.2 addresses communication security issues. The section opens by
requiring an authorization server to offer confidentiality for client
interactions, but the wording implies that a client need not make use of such
protection. The reader is reminded that security requirements expressed in
Section 5 of this document (a 25-page long section) MUST be addressed by a
profile. I’d prefer to see references to specific parts of Section 5 that
expressly addresses confidentiality, so that a reader can better understand
when it is safe to reject the offer of confidentiality by a server.


The implication you read from the text was not intended, section 5
clearly specifies that confidentiality is mandatory.  This is addressed
in the body part of that section (4th paragraph). I'm a bit at a loss on
how to make that more apparent, so that the reader does not go an a
fruitless hunt in the 

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

[Ludwig Seitz]

Hi Ben,

replies inline.

/Ludwig

From: Benjamin Kaduk 
Sent: Tuesday, November 26, 2019 12:04 AM
To: Ludwig Seitz
Cc: ace@ietf.org
Subject: Re: [Ace] I-D Action: draft-ietf-ace-oauth-authz-27.txt

Hi Ludwig,

On Thu, Nov 21, 2019 at 03:16:03AM +0100, Ludwig Seitz wrote:
> Hello ACE,
>
> turns out -26 didn't cover one of the items in Ben's review, namely the
> question of using Client introspection to determine token expiration as
> a lower bound for key expiration. Since the whole issue of Client
> introspection was contentious between OAuth experts, we decided to
> remove the text describing that option.  This still leaves us with the
> two other options, so the problem is still covered.

Thanks for all the updates!  I'm just about ready to push the "request Last
Call" button, but wanted to check one thing first:

Section 5.6.3 seems to limit the error responses to 4.00 and 4.01, but
Section 5.8.2 also talks about 4.03 and 4.05.  I noticed because I was
checking Section 5.1.1's note about "unauthorized_client" error response 
against the
various options in 5.8.2, to see if we're internally consistent about when
we say to send errors vs. AS request creation hints.  My recollection is
that we can have all three of a response code, error response (e.g.,
"unauthorized_client"), and (our custom format of) response payload present
in the same response, so any potential conflict would be limited to just
the response code, but please correct me if I'm wrong about that.

[LS] Section 5.6.3 describes the interaction with the token endpoint at the AS. 
There we mirrored the behaviour of OAuth error responses.
Section 5.8.2 describes the interaction with the newly defined authz-info 
endpoint at the RS. We decided that this warranted more detailed error 
responses, so that a client gets some hint on what went wrong when an access 
token is rejected by the RS.
This is why we have added the  4.03 and 4.05 messages.
Section 5.1.1 describes an access request to a resource at the RS (other than 
the authz-info endpoint) and has yet another different error behaviour.
For the token endpoint (5.6.3), the response code is part of the HTTP/CoAP 
header, while the "error" parameter (with values such as e.g. 
"unauthorized_client") is part of the payload in certain error responses (which 
may also contain "error_description" and "error_uri"), this is just mirroring 
behaviour of OAuth.
For the authz-info endpoint (5.8.2) no such parameters are specified in the 
document (i.e. it just uses the response codes).
Does this clarify the issue?

Also, a few nits that could be treated as LC comments:

There's a stray 'W' in Figure 7

In Section 6.8: s/obsole/obsolete/, and s/profile/ace_profile/

In Section 8.16 we removed the entire "Specifications are required for the
standards track range of point assignment[...]" bullet point.  I think that
only the first two sentences of that bullet point were redundant with RFC
8126, and the last two ("Specifications are needed for the first-come,
first-serve range if they are expected [...]") reflected new requirements.

[LS] Does the " LC comments" part mean I should wait with updating the draft?

/Ludwig

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

[Ludwig Seitz]

If you are using JSON-based interactions, I believe that the most 
straightforward way is to refer to RFC6749 for the error messages as you 
currently do. I don't find this confusing or problematic, but YMMV.

/Ludwig


From: Cigdem Sengul 
Sent: Thursday, November 21, 2019 10:27 AM
To: Daniel Migault
Cc: Ludwig Seitz; ace@ietf.org
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

Hello,

Ludwig, I agree that the current draft describes specifically for when CBOR is 
used.
When CBOR is not used, I have read it as it will act similar to Section 5.2 of 
[RFC6749]<https://tools.ietf.org/html/rfc6749#section-5.2> as you have 
indicated also in the ace-oauth-authz document.

Therefore, instead of an indirect reference to RFC6749 by referencing 
ace-oauth-authz, we used a direct reference to explain what the error response 
should be.

Is this problematic? or confusing?

I can reword in mqtt_tls draft something like:
"As described in [ace-oauth-authz] the error responses for JSON-based 
interactions with AS follow RFC6749. When CBOR is used, the interactions MUST 
implement [ace-oauth-authz]"

Would that help?

Thanks,
--Cigdem



On Thu, Nov 21, 2019 at 3:06 AM Daniel Migault 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi Ludwig,

Thanks for the feed back. I was raising the issue before it got forgotten. , 
and I must say I did not checked whether it had been addressed or not, as I did 
not remember this had been raised for the ace-oauth-authz document.

What you are saying is that the draft has been updated already. I will have a 
closer look at it, and ask mqtt-profile to confirm the current text is fine.

Thanks!
Daniel

-Original Message-
From: Ace mailto:ace-boun...@ietf.org>> On Behalf Of 
Ludwig Seitz
Sent: Thursday, November 21, 2019 10:51 AM
To: ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26

On 21/11/2019 03:29, Daniel Migault wrote:
> Hi,
>
> This only concerns potential clarification of the text.
>
> While reviewing mqtt-profile draft I raised an issue regarding the
> reference for Oauth [RFC6749] while the remaining of the document
> references draft-ietf-ace-oauth-authz [1]. My reading of
> draft-ietf-ace-oauth-authz section 5.6.3
> <https://tools..ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3<http://ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>>.
> was the same of the one of mqtt-profile coauthors, that is error
> mandates the use of CBOR. Discussing this with others it seems a mis
> interpretation of  draft-ietf-ace-oauth-authz section 5.6.3
> <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3> [2].
>
> I believe that is nice this is a mis-interpretation, but I would
> recommend that the text makes it more explicit the use of JSON is
> permitted. This seems to me a request to clarify the text.
>
> Yours,
> Daniel
>

I would be happy to add more clarification, but I'm currently at a loss of what 
that would be. Most of the bullets you cited already modify the MUSTs with 
"...when CBOR is used" or something similar to the same effect. The idea was to 
express: You can use the vanilla OAuth interactions based on JSON, but if you 
use CBOR then do it as specified here.

I am happy to take suggestions.

/Ludwig

> [1]
> """
>
> In the case of an error, the AS returns error responses for HTTP-
> based interactions as ASCII codes in JSON content, as defined in
> Section 5.2 of RFC 6749  
> <https://tools.ietf.org/html/rfc6749#section-5.2>  [RFC6749  
> <https://tools.ietf.org/html/rfc6749>].
>
> """
>
> [2]
> """
>
>
> 5.6.3
> 
> <https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>.
> Error Response
>
>
>
> The error responses for CoAP-based interactions with the AS are
> generally equivalent to the ones for HTTP-based interactions as
> defined inSection 5.2 of [RFC6749]  
> <https://tools.ietf.org/html/rfc6749#section-5.2>, with the following 
> exceptions:
>
> o  When using CBOR the raw payload before being processed by the
>communication security protocol MUST be encoded as a CBOR map.
>
> o  A response code equivalent to the CoAP code 4.00 (Bad Request)
>MUST be used for all error responses, except for invalid_client
>where a response code equivalent to the CoAP code 4.01
>(Unauthorized) MAY be used under the same conditions as specified
>inSection 5.2 of [RFC6749]  
> <https://tools.ietf.org/html/rfc6749#section-5.2>.
>
> o  The Content-Format (for CoAP-based interactions) or media type
>(for HTTP-

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

[Ludwig Seitz]

Hello ACE,

turns out -26 didn't cover one of the items in Ben's review, namely the 
question of using Client introspection to determine token expiration as 
a lower bound for key expiration. Since the whole issue of Client 
introspection was contentious between OAuth experts, we decided to 
remove the text describing that option.  This still leaves us with the 
two other options, so the problem is still covered.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

Hello ACE,

I've had a side-meeting with Ben at IETF 106 and we clarified the 
outstanding issues as follows. I have submitted -26 implementing the 
resolutions resulting from these clarifications. See below for detailed 
comments.


/Ludwig

On 17/11/2019 07:25, Benjamin Kaduk wrote:

On Wed, Nov 13, 2019 at 01:55:44PM +0100, Ludwig Seitz wrote:

On 10/11/2019 04:28, Benjamin Kaduk wrote:



16.)
Section 3.2

 One application of COSE is OSCORE [I-D.ietf-core-object-security],
 which provides end-to-end confidentiality, integrity and replay
 protection, and a secure binding between CoAP request and response
 messages.  In OSCORE, the CoAP messages are wrapped in COSE objects
 and sent using CoAP.

 This framework RECOMMENDS the use of CoAP as replacement for HTTP for
 use in constrained environments.

Do we have a reason to mention OSCORE if we're not going to make a
recommendation about its use?


[LS] We also mention DTLS and TLS without making any recommendation about
which to use. I would suggest to either remove all of it or to add a
sentence
noting that this is an enumeration of some security options, and the choice
depends on the specific application scenario.


Adding a sentence feels like a slightly better option to me, though it
could easily go either way.


Fixed


Note: I thought I had fixed this in -25, but it turned out to only be in 
my head. It's now also fixed in the document (i.e. -26).




39.)
 Refresh tokens are typically not stored as securely as proof-of-
 possession keys in requesting clients.  Proof-of-possession based
 refresh token requests MUST NOT request different proof-of-possession
 keys or different audiences in token requests.  Refresh token
 requests can only use to request access tokens bound to the same
 proof-of-possession key and the same audience as access tokens issued
 in the initial token request.

This is perhaps something of a philosophical question, but if a refresh
token is only usable at the token endpoint, in some sense its audience
is definitionally the AS.  So there's a little bit of a mismatch in
treating it as having the audience value that the access tokens issued
from it will have.  I don't know the background for audience-restriced
refresh tokens in regular OAuth 2.0, though, so hopefully someone can
educate me.


[LS] I'm equally confused. I suggest that Hannes or one of the other OAuth
experts give us a hint on that one.


[We had some stab at this in the other thread, but additional input might
still be in order]



Let's hear with OAuth people in Singapore.



We discussed that now, the text refers to the audience of the access 
token, not the refresh token which is just an opaque reference. -> No 
textual change.





58.)
 Profiles MUST specify whether the authz-info endpoint is protected,
 including whether error responses from this endpoint are protected.
 Note that since the token contains information that allow the client
 and the RS to establish a security context in the first place, mutual
 authentication may not be possible at this point.

We'll need some careful reasoning about this for the security
considerations, since the authz-info transaction can impact what profile
the RS thinks is in use.  E.g., whether a network attacker could
cause the client to think that a different (vulnerable) profile is in
use than the one the RS expects to use.


[LS] Noted. Do you think the reasoning in section 6.5 needs to be extended?


I think we should add some more text, yes.
Specifically, we should mention that the authz-info interaction can affect
what profile RS will use (e.g., via "ace_profile"), and that profile
developers should be conscious of the risk of downgrade attacks that
involve other profile types.  (Am I reading this right that the client will
know what profile to use by the time it is ready to post to the authz-info
endpoint and that the response will not change what profile the client
uses?  Specifically, even if a client supports multiple profiles that use
different methods for token transport, a client is not going to try one
method/profile and then fall back to a different one if the first one
(transiently) fails?)




I'm not sure how you would mount such a downgrade attack. The client
receives the profile to use either by implicit configuration or
explicitly through the "profile" parameter from the AS.
If the client does not receive a "profile" parameter and has no implicit
profile configured this is an error.

The RS either has the profile pre-configured or receives it via an
authenticated "profile" claim in the access token (again if the claim is
missing and no pre-configured profile exists this is an error). Even
though the token is sent to authz-info over an insecure channel and the
client is not yet authenticated, the access token itself is, and
therefore I find it hard to see how an attacker wo

Re: [Ace] Mail regarding draft-tiloca-ace-revoked-token-notification-00

[Ludwig Seitz]

On 17/11/2019 06:24, Jim Schaad wrote:

If you use JSON to transport a token
then it will be the raw bytes for a JWT, but it would be a base64url encoded
value for a CWT.  This means that the hash might not get the correct answer.


The problem here is that the client wouldn't know the format of the 
token and therefore not be able to retrieve the correct binary 
representation (I'm assuming both the RS and the AS would know).


I think the best solution is to define that the data getting hashed is 
to be the binary representation of what is in the 'access_token' 
parameter of the access token response, since that is what everyone (AS, 
Client, RS) sees.


For a CBOR transport that would just be the byte-string value of 
'access_token' as is, while for JSON transport this be the binary 
representation of the String value of 'access_token', which would of 
course depend on the charset.



Side-note: Do we want/need to cater for such a weird corner-case? Who in 
their right mind would use JSON in a CoAP message?


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-oauth-params-05

[Ludwig Seitz]

 RS identiyt is not established through other means".

Done.



o  "rs_cnf" in the introspection response AS -> RS, OPTIONAL,
   contains the public key that the RS should use for authenticating
   to the client (e.g. if the RS has several different public keys).

nit(?): I'd consider adding a phrase about "and there may be ambiguity
as to which key to use" or similar, though I'm failing to come up with a
non-awkward phrasing.


Done. I'll go with slightly awkward, but more correct.



Note that the COSE_Key structure in a confirmation claim or parameter
may contain an "alg" or "key_ops" parameter.  If such parameters are
present, a client MUST NOT use a key that is not compatible with the
profile or proof-of-possession algorithm according to those

nit(?): s/not compatible/incompatible/ would avoid a "double 'not'", if
that's seen as desirable.

Fixed.



Section 6

I thought we had set up separate map key namespaces for (e.g.) token
requests, token responses, and introspection responses, so that
attempting to use the same key value for all the uses of these
parameters defined by this document is something of a type error.
E.g., they end up in different registries, as we do in Section 9.2, 9.5,
and 9.6.


That is correct. I have added separate entries and a column
specifying the different uses. I will leave the values to be the same 
though.



Section 9.1, 9.2, 9.4

I note that the distance between "authenticate to the client" and
"authenticate the client" is small enough that I expect it to be a
common misreading, and also that the other descriptions at
https://www.iana.org/assignments/jwt/jwt.xhtml#claims are a bit more
pithy than what we use here.  Perhaps, "public key used by RS to
authenticate itself to client"?


Done.


Section 9.5

This section registers the following parameter mappings in the "Token
Endpoint CBOR Mappings" registry established in section 8.9. of
[I-D.ietf-ace-oauth-authz].

It looks like this has been renamed to the "OAuth Parameters CBOR
Mappings" registry?

Correct. Fixed.



Section 9.6

This section registers the following parameter mappings in the
"Introspection Endpoint CBOR Mappings" registry established in
section 8.11. of [I-D.ietf-ace-oauth-authz].

Similarly, this has been renamed to "OAuth Token Introspection Response
CBOR Mappings".


Fixed.


Section 11.1

It's not entirely clear that RFC 7252 needs to be a normative reference;
we don't do much with CoAP directly in this document.


Agree. I moved it.


Appendix A

We might want to wordsmith this some if it's to be kept for the final
RFC (depending on what the OAuth work looks like at that point).  I'm
not sure that there are any useful changes to make to it right now,
though.


It seems the OAuth draft I'm talking about here is not going anywhere 
fast. We might consider removing this in the final edition.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

We may get some debate about whether IANA registries are properly
Normative of Informative references, but we can wait for that to happen
-- no need to do anything now.


[LS] Noted. Does the AD have a position on this?


I think there's a reasonable argument for keeping them as normative.  We
probably see them as informative more often (in general), though, probably
because people are concerned about having downrefs to something that's not
a standards-track RFC (which would happen due to a misunderstanding of the
rules surrounding downrefs, IMO).


Ok no action taken at this point.




98.)
Section 10.2

If we're using RFC 4949 for terminology definitions, I think that makes
it a normative reference.

If we REQUIRE CBOR when used with CoAP, that also feels like a normative
reference.

I also think 7519 needs to be normative, since we mandate some of its
processing rules.


[LS] RFC 4949 is informational, so it cannot be normative. I would argue
that we are just using it to clarify the meaning of our terminology.


It's okay to have a normative reference to an informational document; we
just need to call it out in the IETF LC announcement (which the
tooling/secretariat should take care of "automagically").
Furthermore, RFC 4949 is already listed at
https://datatracker.ietf.org/doc/downref/ as an "acceptable downref", so we
don't even have to do that, in this case.



Ok I made RFC 4949 normative, I didn't know about the "acceptable 
downref" arrangement with the secretariat.






If you want to get a new revision up to make these last few changes during
the blackout period, I'm happy to approve a manual posting by the
secretariat.  (OTOH, since IETF LCs that overlap with the meeting week get
extended automatically, it wouldn't necessarily get the document on an IESG
telechat any sooner.)


I have made a few changes, but there are still some points to discuss. 
If you think the updates still warrant a new submission, I can do a 
submission with manual approval.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] ACE@IETF106 - agenda items and presentations

[Ludwig Seitz]

On 31/10/2019 19:26, Daniel Migault wrote:

Hi,

The ACE WG is meeting at the IETF 106 Tuesday November 19 15:20-16:50 . 
Please let us know if there are topic you would like to present by 
Wednesday November 6. Slides are expected to be uploaded by  Sunday 
November 17.


Please remember the draft deadline is Monday November 4

https://datatracker.ietf.org/meeting/106/important-dates/

Yours,

Jim and Daniel




Hello Jim, Daniel,

I would like a 10 minute slot to present

https://tools.ietf.org/html/draft-tiloca-ace-revoked-token-notification

I will be presenting on site (i.e. not remote).

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

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

[Ludwig Seitz]

Hello ACE,

this update of draft-ietf-ace-oauth-authz addresses the review comments 
made by Ben Kaduk.


Regards,

Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-25.txt
Date: Wed, 30 Oct 2019 06:15:10 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



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

Name:   draft-ietf-ace-oauth-authz
Revision:   25
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-10-30
Group:  ace
Pages:  86
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-25.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  The framework is based on a set of building blocks including
   OAuth 2.0 and CoAP, thus transforming a well-known and widely used
   authorization solution into a form suitable for IoT devices.
   Existing specifications are used where possible, but extensions are
   added and profiles are defined to better serve the IoT use cases.




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

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

On 28/10/2019 22:06, Benjamin Kaduk wrote:


32.)
Section 5.6.1

The client sends a POST request to the token endpoint at the AS.  The
profile MUST specify how the communication is protected.  The content

In the previous section we said that maybe even other transports than
coaps or https would be possible; are we limited to those that have POST
verbs?
Also, a similar comment as above about what attributes the protection
entails seems to apply.


[LS] This will need a major rephrasing of the text.
I see two options here:

1.) We rewrite all parts to use a neutral language in general and specify
POST/GET etc. for transports that have these verbs.

2.) We state in the beginning that transports that do not use RESTful verbs
should use the best equivalent.

Option 1. would get a bit cluncky, while option 2. might be a bit confusing
Do you have a specific preference?

[JLS] I would suggest that this could fall under the punt to the new transport 
that does not have the same as these verbs in it to explain how they would map.


I agree that (1) is more effort than it's likely to be worth.  If we can
finagle a single-sentence disclaimer like "transports that do not use these
verbs will need to specify the requisite behavior" that would be great; if
not, then we can consider whether to just ignore it or do something more
complicated.


I'll go for this:

" Note that this document specifies
  protocol exchanges in terms of RESTful commands such as GET and POST.
  Future profiles using protocols that do not support these verbs MUST
  specify how the corresponding protocol messages are transmitted instead.
"

In the Overview section where we mention alternate transport protocols.

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

Hello Ben,

thank you for your thorough review.

I have taken the liberty to add numbers to your comments in order to 
refer to them in a easier way.


I have fixed 93 your 113 and there are 20 left where I am asking for 
clarifications. These are:


 6.), 12.), 16.), 19.), 34.), 39.), 41.), 45.), 52.), 57.), 58.), 65.), 
66.), 68.), 76.), 78.), 79.), 88.), 99.), 111.)


Note that 39.) Requires input from OAuth experts. Hannes?

If you whish to inspect the changes made on other review issues, please 
consult the commits here:

https://github.com/ace-wg/ace-oauth/commits/master


Detailed comments below.

/Ludwig



Hi all,

The length of this review notwithstanding, this document is generally in
good shape -- there's a bunch of localized items to tighten up, and we
can flesh out the security considerations some more, but nothing too
drastic should be needed.

1.)
Perhaps the most far-reaching changes needed
will be to rename the "profile" claim, since that has already been
allocated to OIDC Core for a very different usage.


[LS] FIXED. I renamed the "profile" claim and parameters to "ace_profile"
Note that this will require changes in all of the profile drafts as well.


2.)
I also made a pull
request with a bunch of trivial editorial stuff that's easier to fix
than describe how to fix, up at
https://github.com/ace-wg/ace-oauth/pull/175 .


[LS] Merged.


3.)
One general note before getting into the section-by-section comments:

There's a bunch of places where we talk about parameters that "MUST be
mapped to CBOR types as specified in Figure N"; we may want to point to
the IANA registry as authoritative and just give the figure reference
for description.


[LS] FIXED.



4.)
Abstract

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

nit: It's easy to (mis)read this text as saying that just amalgamating
OAuth 2.0 and CoAP magically makes for a solution that is well-known and
widely used.  I'd suggest rewording slightly, perhaps "thus transforming
a well-known and widely used authorization solution into a form suitable
for IoT devices".


[LS] FIXED.


5.)
   specifications are used where possible, but where the constraints of
   IoT devices require it, extensions are added and profiles are
   defined.

nit: from a rhetorical point of view, it's probably better to reiterate
why the extensions are added and profiles defined ("to better serve the
IoT case") than to just stop with a flat declaration of what is done.


[LS] FIXED.


6.)
Section 1

   Authorization is the process for granting approval to an entity to
   access a resource [RFC4949].  The authorization task itself can best
   be described as granting access to a requesting client, for a
   resource hosted on a device, the resource server (RS).  This exchange

I had to pause for a while after reading this and ponder whether I
agreed with it.  I think that my reticence stems from some friction
between the most generic abstract definition of "resource" and a more
specific one used in the web/HTTP world and, to a lesser extent, the
world of URIs and URNs in general.  The resources we are discussing here
are not always specific named resources, but can also refer to
attributes or capabilities mediated by a RS; similarly, we may be
creating/modifying named resources as part of the resource access
performed by a client in the OAuth model.  I don't think it's wise to
diverge from the RFC 4949 definition just yet, but am still considering
whether adding some additional clarifying text here is worthwhile.


[LS] I would argue that this specification is applicable even to the wider
definition of "resource" that you are thinking of. Since OAuth 2.0 leaves
the definition of "scope" up to the specific applications, and the ACE
framework does not change this, we can deal with both web/HTTP/CoAP 
resources
(named by URIs or URNs) and any other type of resources where the 
application

can map the resource in question to a set of scopes.
I am therefore inclined to say that this section is fine, but I'd be glad to
hear the result of your considerations on that matter.


7.)
Section 3

It's probably worth adding (informative) references for HTTP/2, MQTT,
BLE, and QUIC.


[LS] FIXED.



8.)
   A fourth building block is the compact CBOR-based secure message

"compact CBOR" has the "PIN number" nature and is probably redundant.


[LS] FIXED.


9.)
   format COSE [RFC8152], which enables application layer security as an
   alternative or complement to transport layer security (DTLS [RFC6347]

I'm undecided whether it's better to think of this as "application layer
security" or "object-level security".


[LS] FIXED. Now that you mention it, I find that "object security" describes
COSE better than "application layer security". I have made the 
appropriate change.




10.)
   or TLS [RFC8446]).  COSE is used to secure 

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

On 01/10/2019 05:13, Benjamin Kaduk wrote:

On Fri, Sep 27, 2019 at 03:22:45AM -0700, Jim Schaad wrote:



-Original Message- From: Ludwig Seitz  
Sent: Friday, September 27, 2019 12:03 AM To: Benjamin Kaduk

; draft-ietf-ace-oauth-authz@ietf.org Cc:
ace@ietf.org Subject: Re: AD review of
draft-ietf-ace-oauth-authz-24

On 27/09/2019 03:51, Benjamin Kaduk wrote:

Hi all,

The length of this review notwithstanding, this document is
generally in good shape -- there's a bunch of localized items to
tighten up, and we can flesh out the security considerations some
more, but nothing too drastic should be needed.  Perhaps the most
far-reaching changes needed will be to rename the "profile"
claim, since that has already been allocated to OIDC Core for a
very different usage.  I also made a pull request with a bunch of
trivial editorial stuff that's easier to fix than describe how to
fix, up at https://github.com/ace-wg/ace-oauth/pull/175 .



I have a non-trivial comment on your pull request: In appendix B
we summarize the steps taken by an RS to process a freshly received
access token. You changed the suggested sequence from:


First off, thank you for spotting it and bringing the discussion
here!  I'm sorry that you had to do so; I wasn't trying to sneak it
in :)



I didn't think so.


* Verify the token is from a recognized AS. * Verify that the token
applies to this RS. * Check that the token has not expired (if the
token provides expiration information). * Check the token's
integrity. * Store the token so that it can be retrieved in the
context of a matching request.

To

* Verify the token is from a recognized AS. * Check the token's
integrity. * Verify that the token applies to this RS. * Check that
the token has not expired (if the token provides expiration 
information). * Store the token so that it can be retrieved in the

context of a matching request.


I don't think this is a big deal, but I put the integrity check
later for a good reason (or so I believe): The integrity check is
a potentially expensive cryptographic operation. Checking that the
token applies to the RS is a matter of checking the audience claim,
and checking that the token is not expired is a matter of comparing
two timestamps, I consider both to be computationally much lighter
and therefore quicker to execute. A failure of any of those two may
make it unnecessary to verify the token integrity.

BUT! My suggested sequence only works if the token is signed or
MACed and not if it is encrypted. If the token is encrypted the
AEAD integrity check (and decryption) is necessarily the first
processing step.

Any ideas how to resolve this gracefully (i.e. without adding a
large amount of text) are most welcome.

[JLS] I normally get out of this type of problem by saying "The
order of the steps is not normative, any process which produces an
equivalent result can be used."  And then you can add a comment
about switching the two steps for signed items.


That seems like a reasonable approach.  FWIW, my thinking was that 
signature validation is a great way to toss out a bunch of malformed

input, and we tend to do it first in non-constrained environments,
but I can see the tradeoff running the other way in some cases.

-Ben



I'll formulate some text to capture this. It's an appendix that is not 
supposed to be normative anyways, rather it's intention was to serve a 
guideline to help implementers.


/Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-oauth-authz-24

[Ludwig Seitz]

On 27/09/2019 03:51, Benjamin Kaduk wrote:

Hi all,

The length of this review notwithstanding, this document is generally in
good shape -- there's a bunch of localized items to tighten up, and we
can flesh out the security considerations some more, but nothing too
drastic should be needed.  Perhaps the most far-reaching changes needed
will be to rename the "profile" claim, since that has already been
allocated to OIDC Core for a very different usage.  I also made a pull
request with a bunch of trivial editorial stuff that's easier to fix
than describe how to fix, up at
https://github.com/ace-wg/ace-oauth/pull/175 .



I have a non-trivial comment on your pull request: In appendix B we 
summarize the steps taken by an RS to process a freshly received access 
token. You changed the suggested sequence from:


* Verify the token is from a recognized AS.
* Verify that the token applies to this RS.
* Check that the token has not expired (if the token provides expiration 
information).

* Check the token's integrity.
* Store the token so that it can be retrieved in the context of a 
matching request.


To

* Verify the token is from a recognized AS.
* Check the token's integrity.
* Verify that the token applies to this RS.
* Check that the token has not expired (if the token provides expiration 
information).
* Store the token so that it can be retrieved in the context of a 
matching request.



I don't think this is a big deal, but I put the integrity check later 
for a good reason (or so I believe): The integrity check is a 
potentially expensive cryptographic operation. Checking that the token 
applies to the RS is a matter of checking the audience claim, and 
checking that the token is not expired is a matter of comparing two 
timestamps, I consider both to be computationally much lighter and 
therefore quicker to execute. A failure of any of those two may make it 
unnecessary to verify the token integrity.


BUT! My suggested sequence only works if the token is signed or MACed 
and not if it is encrypted. If the token is encrypted the AEAD integrity 
check (and decryption) is necessarily the first processing step.


Any ideas how to resolve this gracefully (i.e. without adding a large 
amount of text) are most welcome.



Regards,

Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

[Ludwig Seitz]

On 25/09/2019 10:13, Mike Jones wrote:
Does one of you have the time to create a PR today making the two 
changes?  I’ll then be able to review it and publish sometime in the 
next 24 hours.  Or if not, I’ll plan to do it myself while flying back 
from Korea to the US tomorrow.


    Thanks all,

    -- Mike

*From:* Samuel Erdtman 
*Sent:* Wednesday, September 25, 2019 12:18 AM
*To:* Ludwig Seitz 
*Cc:* Mike Jones ; Benjamin Kaduk 
; draft-ietf-ace-cwt-proof-of-possession@ietf.org; 
ace@ietf.org
*Subject:* Re: New Version Notification - 
draft-ietf-ace-cwt-proof-of-possession-07.txt


+1

On Wed, Sep 25, 2019 at 8:31 AM Ludwig Seitz <mailto:ludwig.se...@ri.se>> wrote:


On 25/09/2019 02:23, Mike Jones wrote:
 > I'm fine with us making both of the proposed changes.
 >
 >                               Thanks,
 >                               -- Mike
 >

    +1

-- 
Ludwig Seitz, PhD

Security Lab, RISE
Phone +46(0)70-349 92 51




I'm in the process of doing the PR, but I noticed that I can only 
address Ben's (1) and (3).


For (2) Ben was asking for our opinion.

I think we could take the note about different key IDs referring to the 
same key and reintroduce it in the text as it is a useful reminder.


(I mean that chunk:
" Note that the value of a Key ID is not always the same for different 
parties. When sending a COSE encrypted message with a shared key,

the Key ID may be different on both sides of the conversation,
with the appropriate one being included in the message based on the 
recipient of the message.")




/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] New Version Notification - draft-ietf-ace-cwt-proof-of-possession-07.txt

[Ludwig Seitz]

On 25/09/2019 02:23, Mike Jones wrote:

I'm fine with us making both of the proposed changes.

Thanks,
-- Mike



+1

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Ludwig Seitz]

On 26/08/2019 18:07, Jim Schaad wrote:


On 13/08/2019 01:15, Benjamin Kaduk wrote:


The "COSE_Key" member MAY also be used for a COSE_Key
representing a symmetric key, provided that the CWT is
encrypted so that the key is not revealed to unintended
parties.  The means of encrypting a CWT is explained in
[RFC8392].  If the CWT is not encrypted, the symmetric key MUST
be encrypted as described in Section 3.3.

It's hard for me to escape the conclusion that this paragraph
needs to be a dedicated section with a bit more discussion
about how exactly this usage is performed and encoded.



This mirrors the corresponding procedure in RFC 7800. Would it be
OK to just refer to that document 
(https://tools.ietf.org/html/rfc7800#section-3 or actually 3.3)?


(Section 3.2, it seems -- JWT and CWT cover aysmmetric and
symmetric in the opposite order.) Well, I still wouldn't like it.
But I don't think I have grounds to block the document from
advancing if you just refer back to JWT.



Göran and I have discussed this, and we agree that it is indeed 
underspecified (e.g. which key is used to encrypt this "inner" 
COSE_Encrypt0 contained in the cnf element?). Additionally I can 
personally confirm that this is a headache to implement (and I

haven't even touched a constrained implementation).

[JLS]  I am not sure that I understand why you believe that this is
underspecified. 


Because the AD said so ;-)

Seriously: I believe that this warrants more text, since it must be at 
least clarified that this construct assumes two pre-configured keys 
shared between AS and RS: one for encrypting the inner cnf element and 
one for integrity protecting the whole CWT.



Despite the fact that I have not implemented this, I
do not believe that it would be all that problematic to implement in
general, and would be even easier to implement in a constrained
system as only one format of CWT should ever be expected by a single
small device so that the structure can be hard coded.


Perhaps 'headache' was a hyperbole on my part, but there is definitely a 
code-complexity difference between "parsing CBOR" and "parsing CBOR, 
interrupt the parsing to decrypt stuff, continue parsing CBOR".



[JLS] There is a potential case for the first of those options,
having different authority servers that are passing things back and
forth and a desire to do validation that the correct permissions
exist.  That is the client AS sends a request to the Resource AS
which creates a token for the RS and the client AS wants to double
check the permissions granted to the client.  But I have not heard
that anybody is planning to do such an implementation yet.  So far
everybody is combining the two AS roles into a single system.  If you
are ever in the second case, I would argue that you are better off
using asymmetric keys all the way around.


I can see this use case. That rules out my option 1. of removing this 
construct.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Ludwig Seitz]

otection.

Do we want to reiterate the common mechanisms for providing
confidentiality protection here, or just leave the existing text earlier
in the document to cover it?


Doesn't it say a few sentences before: "it is
 necessary to apply data origin authentication and integrity
 protection (via a keyed message digest or a digital signature)." ?

I would consider this to be enough.


That doesn't cover the *confidentiality* protection, specifically.  (So it
seems the answer to my original question is still unclear, at least to me.)



Issue created here: https://github.com/cwt-cnf/i-d/issues/22
Will fix.




Section 6

 ensure correct processing.  The recipient needs to be able to use
 credentials to verify the authenticity, integrity, and potentially
 the confidentiality of the CWT and its content.  This requires the

Just from a rhetorical point of view, can you help me understand how
credentials would be used to verify the confidentiality of a CWT?  It
seems like this depends on either (or both of) how the CWT is
transmitted or how it is prepared, and I am not sure how the recipient's
credentials come into play.



This text is referring to the issuer's credentials (e.g. the
Authorization Server issuing the CWT), that the recipient needs to
verify the CWT. Do you want us to clarify this sentence?


Note that I was specifically asking about "potentially the
confidentiality"; I don't understand the intended workflow for verification
of confidentiality (and thus which credentials are involved).  I don't
really see how a credential held solely by the issuer could proide
confidentiality protection when it needs to be understood by some other
protocol participant.


Issue created here: https://github.com/cwt-cnf/i-d/issues/23
Will fix.



Section 7

 Criteria that should be applied by the Designated Experts include
 determining whether the proposed registration duplicates existing
 functionality, determining whether it is likely to be of general
 applicability or whether it is useful only for a single application,
 and evaluating the security properties of the item being registered
 and whether the registration makes sense.

I know we've been using (variations of) this text for a while, but it
seems to me that it could be more clear than it currently is -- is
duplication of functionality grounds for denial of registration?  What
about general vs. specific applicability?  The latter seems more clearly
applicable for determining which range from which to allocate, since
that has impact on the encoding size.  Can the experts insist on updates
to the security considerations text of a specification prior to granting
approval, or are they limited to denying registration of values with
poor security properties or insufficient documentation thereof?



I'm too unfamiliar with the designated expert system to provide a good
answer on this one. Can one of my co-authors chip in here?


Issue created here: https://github.com/cwt-cnf/i-d/issues/25
Will fix.


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Keeping the same key identifier for groups

[Ludwig Seitz]

On 20/08/2019 11:18, Peter van der Stok wrote:
Example: If you have a CWT authorizing A for audience Z and you now also 
need authorization B for audience Z, you should request a CWT for A+B 
for audience Z, that replaces your previous one.


Do I understand?
two possibilities:
A and B are members of audience Z; no new CWT needed
B is a new member of audience Z; then audience Z becomes audience 
Z-prime and a new CWT seems reasonable.


Peter


No Peter,

sorry for being unclear. In my example A and B were permissions. Let me 
clarify:


You have a CWT authorizing to "read" (that's my A) traffic in group Z, 
now you also want authorization to "write" messages to group Z (that's 
my B). What I'm saying is you should get a new CWT that says "read+write 
on Z" (and not a separate one that says "write on Z" to combine with the 
first one "read on Z").


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Keeping the same key identifier for groups

[Ludwig Seitz]

On 19/08/2019 22:40, Jim Schaad wrote:

As Ludwig pointed out during the F2F, it makes far more sense to try and
keep an entity using the same key identifier for as long as possible.  This
is in part to make sure that signing keys do not need to be retrieved if
they can be easily cached.  In looking at this deeper during my
implementation I ended up with the following question:

The way that I have set things up in my implementation it is simple to
ensure that the same kid value is going to be used with the same CWT,
however it might make more sense to use the signing key as the continuity
identifier instead.  The issue that arises in this case is that there might
be two different active CWT objects that are associated with the same
signing key.  That is there are two CWTs but the same signing key was used
while doing a join operation.   I already do some matching between different
CWTs by assuming that if the bearer key in the CWT is the same then they are
sufficiently equivalent to threat them as the same.  This lead to some
interesting discussions in Montreal about if this meant just the "secret" or
if it meant all of the elements provided by the AS which are used in the key
derivation process.  (I have gone back and forth on this and currently am
sitting on the "just the secret" side of the fence.)

Does anyone have any opinions?


Could you please expand the explanation of your use case a bit?

Are you thinking of a scenario where someone would be using the 
counter-signature key from group-OSCORE as a proof-of-possession (pop) 
key in serveral CWTs?


What would these CWT authorize?

Why would an entity hold several CWTs for the same audience?


Side-note:
My stance on multiple CWTs linked to the same pop-key and for the same 
audience is that the latter one should supersede the previous ones.
Example: If you have a CWT authorizing A for audience Z and you now also 
need authorization B for audience Z, you should request a CWT for A+B 
for audience Z, that replaces your previous one.


/Ludwig




--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Ludwig Seitz]

On 12/08/2019 23:59, Carsten Bormann wrote:

On Aug 12, 2019, at 14:08, Ludwig Seitz  wrote:


As far as I gather from the comments (especially from Carsten), we'd solve this 
by referencing section 6 of RFC 7049. I will consult with my co-authors, but I 
think this is the right solution.


That is not what I said.

Grüße, Carsten



Sorry,

hasty copy-paste of the wrong reference (the right one came later in 
your email: Appendix G of RFC 8610).


I blame Monday morning after the holidays ...

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

[Ludwig Seitz]

he different kinds of CWTs segregated so that an attacker cannot
cause the wrong PoP key to be used by using a valid Key ID for the
wrong kind of CWT.

Audience restrictions can come into play here, too, right?  In that a
restricted audience of all the CWTs in turn limits the scope of
administration in which this care/segregation needs to be enforced.



Correct, we should add a sentence here to suggest this as one strategy 
to limit this risk.



Section 7

Criteria that should be applied by the Designated Experts include
determining whether the proposed registration duplicates existing
functionality, determining whether it is likely to be of general
applicability or whether it is useful only for a single application,
and evaluating the security properties of the item being registered
and whether the registration makes sense.

I know we've been using (variations of) this text for a while, but it
seems to me that it could be more clear than it currently is -- is
duplication of functionality grounds for denial of registration?  What
about general vs. specific applicability?  The latter seems more clearly
applicable for determining which range from which to allocate, since
that has impact on the encoding size.  Can the experts insist on updates
to the security considerations text of a specification prior to granting
approval, or are they limited to denying registration of values with
poor security properties or insufficient documentation thereof?



I'm too unfamiliar with the designated expert system to provide a good 
answer on this one. Can one of my co-authors chip in here?



Section 7.2.1

Change Controller:
   For Standards Track RFCs, list the "IESG".  For others, give the
   name of the responsible party.  Other details (e.g., postal
   address, email address, home page URI) may also be included.

In light of the GDPR and similar regulations (and, as is done in RFC 8602), we
may not want to keep all of these, especially postal address, given the lack of
a clear need.



Ok I'll have a look at how it is done in RFC 8602 and adapt this text 
accordingly.




Specification Document(s):
   Reference to the document or documents that specify the parameter,
   preferably including URIs that can be used to retrieve copies of

Is the reference required to be publicly accessible?  If not, is it
required that a copy be made available to the experts and IANA?



I think that at least the experts and IANA should be able to inspect a 
copy, how are they going to do their job otherwise?
Do you want us to take any textual action here or was this just a 
general remark?



Section 7.2.2

o  Confirmation Method Name: "Encrypted_COSE_Key"
o  Confirmation Method Description: Encrypted COSE_Key
o  JWT Confirmation Method Name: "jwe"
o  Confirmation Key: 2
o  Confirmation Value Type(s): COSE_Encrypt or COSE_Encrypt0
   structure (with an optional corresponding COSE_Encrypt or
   COSE_Encrypt0 tag)

Do we want to say something about how, in the case when the tag is
omitted, the application protocol specification needs to indicate how to
determine which one is in use?

As a result of your subsequent discussion with Jim I am inclined to 
leave this as it is. Is that acceptable for you?



Section 8.2

I think [JWT] needs to be normative, as we have a SHOULD-level
requirement for the audience restriction procedures it specifies.

I agree with Jim's assessment that an indirect normative reference via 
the CWT RFC is sufficient.



I just want to check that it's intentional/desired to mix descriptive
reference tags (e.g., [JWS]) and RFC-number tags (e.g., [RFC7800]) for
the referenced RFCs.

I'm more inclined to have RFC number tags (makes it easier to look them 
up without going via the bibliography), but it's mostly a matter of 
taste. Do you think we should use one or the other consistently?



Acknowledgements, Authors

The datatracker is currently accepting XML v3 format drafts, and the RFC
Editor's target cutover date for the end of August is quite soon, so
feel free to consider using an XML v3 submission with UTF-8
representations of names not well represented by the ASCII subset.

It broke some older version of xml2rfc at some earlier point (the 
default one coming with Ubuntu distros), but since I got that fixed now, 
I'm inclined to give Göran his umlaut.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile

[Ludwig Seitz]

On 22/05/2019 23:58, Jim Schaad wrote:



5.  Is there an intention to provide a "standard" format for the scope field
or just to leave it as ad hoc?


I would be very much in favor of this, or at least provide guidelines to 
avoid adding to this: https://www.brandur.org/oauth-scope


/Ludwig






--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] draft-ietf-ace-mqtt-tls-profile connections

[Ludwig Seitz]

On 21/05/2019 22:35, Cigdem Sengul wrote:
Thank you for your comments.  I see that we tried to cover too many 
options in the draft, and things got mixed up.I tried to clarify inline.


* So as a client I get a token from the AS.  For the first run,
assume that
it has a RPK in it.
* I now connect to the server using TLS.
         Question #1 - Am I doing client authentication at this
point in TLS?
This is what is happening for all of the current profiles, but it is not
clear that this is happening for this profile.  The answer appears to be
both yes and no.

The basic method we were thinking:


 1. We have not assumed client-side certificates for authenticating
clients during TLS handshake. RS uses a server-side certificate.




One quick question: If I understand it correctly there is a variant of 
MQTT using UDP (MQTT-SN). Since TLS and TCP are not exactly 
"constrained-friendly", would it make sense to look at that as well to 
define a "MQTT-SN-over-DTLS-based" profile?


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Adoption call for draft-sengul-ace-mqtt-tls-profile

[Ludwig Seitz]

On 22/04/2019 19:32, Jim Schaad wrote:

At the meeting in Prague there was some discussion about adopting
https://datatracker.ietf.org/doc/draft-sengul-ace-mqtt-tls-profile/ as a
working group document.  The overall sense of the room was that this should
be done.  This message starts a 2 week adoption call for the document.  If
you have strong feelings one way or the other about adopting this document
please let us know.  Reasons for your position are appreciated.

ACE Chairs

Jim & Daniel



I support adoption of this draft.

The reason is that MQTT is a very popular protocol in sensor networks, 
and thus ACE would be very much less relevant if we didn't work on a 
solution for MQTT as well.


Regards,

Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

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

[Ludwig Seitz]

Hello ACE,

related to my previous message on draft-ietf-ace-oauth-authz, the 
necessary alignment of mappings required a similar alignment necessary 
in this document.


This update addresses this.

/Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-params-05.txt
Date: Mon, 25 Mar 2019 08:54:18 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz 


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

Name:   draft-ietf-ace-oauth-params
Revision:   05
Title:		Additional OAuth Parameters for Authorization in Constrained 
Environments (ACE)

Document date:  2019-03-25
Group:  ace
Pages:  13
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-params-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/

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


Abstract:
   This specification defines new parameters for the OAuth 2.0 token and
   introspection endpoints when used with the framework for
   authentication and authorization for constrained environments (ACE).
   These are used to express the proof-of-possession key the client
   whishes to use, the proof-of-possession key that the AS has selected,
   and the key the RS should use to authenticate to the client.




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

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

[Ludwig Seitz]

Hello ACE,

sadly I got another review shortly after Jim pushed the "publication 
requested" button on this, which showed a number of necessary 
clarifications and alignments of mappings. Furthermore the review 
highlighted the fact that the processing of the "cnonce" parameter was 
under-specified (this used to be called "nonce" colliding with an OpenId 
parameter of the same name).


This update addresses these issues.

/Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-23.txt
Date: Mon, 25 Mar 2019 08:53:03 -0700
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



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

Name:   draft-ietf-ace-oauth-authz
Revision:   23
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-03-25
Group:  ace
Pages:  82
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-23.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  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

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

[Ludwig Seitz]

Hello ACE,

this update fixes the review comment from Jim about IANA registration 
procedures for the mapping registries and Francesca's comment on the 
section numbers with the references to the OAuth spec.


I believe I have addressed all outstanding issues.

/Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-22.txt
Date: Tue, 5 Mar 2019 01:52:31 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



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

Name:   draft-ietf-ace-oauth-authz
Revision:   22
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-03-05
Group:  ace
Pages:  81
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-22.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  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

Re: [Ace] draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 26/02/2019 17:54, Jim Schaad wrote:




3. In section 8.3 - Is/Should there be a requirement that the
error also be registered in an OAuth registry?  If so then this
needs to be part of the expert reviewer instructions on this
registry.


The expert reviewer instructions already state this:

"Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries,
experts should require new registrations to maintain a reasonable
level of alignment with parameters from OAuth that have comparable
functionality."

This includes the error registry, do you think this is
sufficiently clear or should I elaborate?


The question I had was the difference between SHOULD and MUST be
registered.  The text there says - try and keep them in sync, but if
they are not it is not a problem.   If that is what you want then
this is not a problem, I was just validating this.


The intention of the "should require ... a reasonable level of
alignment" was "try and keep them in sync, but if they are not you need
a good reason for this".

Your alternate interpretation makes me think the text is not worded
strongly enough.


I think that this is basically the same thing.   The only thing that you might 
want to add is some guidance on what constitutes a good reason.


Ok how about this:

"... experts should require new registrations to maintain alignment with 
parameters from OAuth that have comparable functionality.  Deviation 
from this alignment should only be allowed if there are functional 
differences, that are motivated by the use case and that cannot be 
easily or efficiently addressed by comparable OAuth parameters."







4. In section 8.4 - Is there a reason to require a specification
for this registry?  Should it be sufficient to have somebody
request that a mapping be registered and the DE approves it?  The
previous comment would apply

to

all of the mapping registries that are just mappings.


The idea is to prevent the squatting of low byte count
abbreviations by parameters that are not frequently used, thus
there is a range of different policies for different integer
abbreviation number ranges. (note: I'm following the example of the
CWT specification here)


Not requiring a document to exists could still allow this.  IANA
would still have the DE approve the assignment.



Ok so you mean not having "specification required" for -65536 to -257
and 256 to 65535 and not having "standards action" for -256 to 255 would
be ok?

Note that this would be different from the policy in RFC 8392 (CWT).


Yes I understand that this is different from CWT.  When looking at the 
registries you basically would write a specification which contains the 
following text:

If, for example , in section 8.4 it was already registered in the OAuth 
registry, then the document would boil down to:

Please assign a number in the "OAuth Grant Type CBOR Mappings" registry with 
the following properties:
Name:  grant_type_name
CBOR Value: TBD
Reference: [This document]
Original Specification: [The document for grant_type_name] in the "OAuth Grant 
Type" registry.

This seems like it is really overkill to have to produce a full specification with of one 
page when an email to IANA would seem to have the same info.   If you were defining a new 
grant type, then a full spec would be useful but it would also be expected to do the 
registration in the "OAuth Grant Type" registry as well as in this registry.



Ok now I get what you were going for. Sorry for the slow uptake, and you 
are indeed right. I will go through the mapping IANA sections and redue 
the applicable policies to "expert review required" and "private use" 
based on the number ranges.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Call for IETF 104 agenda items

[Ludwig Seitz]

On 26/02/2019 17:28, Roman Danyliw wrote:

Hello!

The ACE WG has been tentatively scheduled for Friday, March 29, 2019 from 
1050-1250 per the draft agenda [1].  If you would like time on the agenda 
please let the chairs know.

Regards,
Roman and Jim

[1] https://datatracker.ietf.org/meeting/agenda/

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace



Hello,

I would like 15 minutes to present and discuss the changes in 
draft-ietf-oauth-authz and draft-ietf-oauth-params


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 25/02/2019 18:08, Jim Schaad wrote:


3. In section 8.3 - Is/Should there be a requirement that the
error also be registered in an OAuth registry?  If so then this
needs to be part of the expert reviewer instructions on this
registry.


The expert reviewer instructions already state this:

"Since a high degree of overlap is expected between these
registries and the contents of the OAuth parameters registries,
experts should require new registrations to maintain a reasonable
level of alignment with parameters from OAuth that have comparable
functionality."

This includes the error registry, do you think this is
sufficiently clear or should I elaborate?


The question I had was the difference between SHOULD and MUST be
registered.  The text there says - try and keep them in sync, but if
they are not it is not a problem.   If that is what you want then
this is not a problem, I was just validating this.


The intention of the "should require ... a reasonable level of
alignment" was "try and keep them in sync, but if they are not you need
a good reason for this".

Your alternate interpretation makes me think the text is not worded
strongly enough.







4. In section 8.4 - Is there a reason to require a specification
for this registry?  Should it be sufficient to have somebody
request that a mapping be registered and the DE approves it?  The
previous comment would apply

to

all of the mapping registries that are just mappings.


The idea is to prevent the squatting of low byte count
abbreviations by parameters that are not frequently used, thus
there is a range of different policies for different integer
abbreviation number ranges. (note: I'm following the example of the
CWT specification here)


Not requiring a document to exists could still allow this.  IANA
would still have the DE approve the assignment.



Ok so you mean not having "specification required" for -65536 to -257 
and 256 to 65535 and not having "standards action" for -256 to 255 would 
be ok?


Note that this would be different from the policy in RFC 8392 (CWT).

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

[Ludwig Seitz]

On 18/02/2019 15:59, Sebastian Echeverria wrote:

Hello,

I have a short comment about error responses from an RS in 
draft-ietf-ace-oauth-authz-21. More specifically, my question is about 
section 5.8.2. In the second paragraph, it states “The response code 
MUST be 4.01 (Unauthorized) in case the client has not performed the 
proof-of-possession, or if RS has no valid access token for the client.” 
I am assuming this means that if the client is trying to access a 
resource and sending a pop key id that is not known by the RS, either 
because the RS has never seen it or because it is associated to a token 
that has already been removed from the RS, then this is how the RS 
should reply.


If this is the case, I am a bit confused on how to implement this when 
using the DTLS profile. When using this profile, a client will first try 
to establish a DTLS session with the RS when accessing a resource. Once 
the session is established, it will actually try to access the resource 
over that DTLS connection. The pop key id to be used is sent when 
establishing the DTLS connection in the DTLS handshake messages, but if 
the RS does not have a key+token associated to that id for whatever 
reason, then it will cancel the DTLS handshake. If the DTLS handshake is 
never completed, then the RS can’t really send a reply at all, much less 
a 4.01 reply.


Thanks,

Sebastian Echeverria



Sebastian is right. I will change the text in the framework to allow for 
cases where no answer at all can be provided. The intent was that these 
error messages should only be sent when the access token is POSTed to 
the authz-info endpoint.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] draft-ietf-ace-oauth-authz

[Ludwig Seitz]

On 24/02/2019 01:13, Jim Schaad wrote:

1.  Figure 4 needs to be updated as it no longer matches Figure 3.


Fixed


2. In section 8.2 - Should he error usage location match any of the current
values in the table.   Possibly "authorization server response"

Fixed, I made that "token error response" as one of the specified 
locations in RFC 6749 11.4.1.


(side note: The OpenID and Kantara IANA registrations apparently missed 
the limited range of values specified for this field and used custom 
location descriptions).



3. In section 8.3 - Is/Should there be a requirement that the error also be
registered in an OAuth registry?  If so then this needs to be part of the
expert reviewer instructions on this registry.


The expert reviewer instructions already state this:

"Since a high degree of overlap is expected between these registries 
 and the contents of the OAuth parameters registries, experts should 
require new registrations to maintain a reasonable level of alignment 
with parameters from OAuth that have comparable functionality."


This includes the error registry, do you think this is sufficiently 
clear or should I elaborate?




4. In section 8.4 - Is there a reason to require a specification for this
registry?  Should it be sufficient to have somebody request that a mapping
be registered and the DE approves it?  The previous comment would apply to
all of the mapping registries that are just mappings.

The idea is to prevent the squatting of low byte count abbreviations by 
parameters that are not frequently used, thus there is a range of 
different policies for different integer abbreviation number ranges.

(note: I'm following the example of the CWT specification here)


5. In section 8.5 - You are missing two fields of the registration template.
Specifically should the expiration time field be noted in the "Additional
Token Endpoint Response Parameters" column.

Fixed



6. In section 8.9 - see comments of section 8.3 and 8.4

7.  In section 8.11 - see comments of section 8.3 and 8.4


See above



8.  This document has an IPR disclosure on it.   If anybody has any problems
with the current disclosure then they need to speak up now.


Processing ...

The changes are currently only in the github version, I will upload a 
new version of the draft soon.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

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

[Ludwig Seitz]

Hello ACE,

this update addresses the key expiration issue from Steffi's review.

With this update I believe we have addressed all reviewer's comments and 
the comments of the shepherds review.


/Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-21.txt
Date: Thu, 14 Feb 2019 01:27:00 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



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

Name:   draft-ietf-ace-oauth-authz
Revision:   21
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-02-14
Group:  ace
Pages:  80
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-21.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  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

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

[Ludwig Seitz]

Hello ACE,

I've updated both draft-ietf-ace-oauth-authz and 
draft-ietf-ace-oauth-params to replace the "req_aud" parameter with the 
equivalent "audience" parameter (not to be confused with "aud") from 
draft-ietf-oauth-token-exchange.



/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Resource, Audience, and req_aud

[Ludwig Seitz]

On 11/02/2019 13:55, Hannes Tschofenig wrote:

Hi Jim, Hi Ludwig,

Do the chairs think that this would unduly delay the progress of 
draft-ietf- ace-oauth-params?


[Hannes] Do you think it was inappropriate to point out this
inconsistency?



No of course not, sorry if any of my comments came across like that. I'm 
just trying to balance the alignment with OAuth vs avoiding further delays.




It looks like the are about the same point as we are.  So no I
don't think it would slow things down to make this change.


[Hannes] Jim what are you suggesting?



My interpretation of Jim's comment was a go-ahead with chair hat on.

I'm in the process of making the necessary updates to both 
draft-ietf-ace-oauth-params and draft-ietf-ace-oauth-authz.


Expect an update in the next 10 minutes.

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Resource, Audience, and req_aud

[Ludwig Seitz]

On 07/02/2019 17:12, Hannes Tschofenig wrote:

Hi Ludwig,


What I understood from the feed-back is that using a parameter
called "aud" in a request to the token endpoint would be
interpreted as a restriction on the audience of authorization
servers that are addressed by this request.


I am not talking about a parameter called 'aud'. Take a look at the
token exchange spec -- the parameter is called 'audience'. 'aud' is
the name of the claim.

Ciao Hannes




Ok I see, I had that mixed up.

Let me just note that having an "audience" parameter and an "aud" 
parameter (which is also referred to as 'audience') is not ideal when 
one wants to avoid confusion.


It seems the token-exchange draft is quite advanced, so referring to its 
"audience" parameter instead of defining "req_aud" (with more or less 
the same semantics) seems reasonable to me.


Do the chairs think that this would unduly delay the progress of 
draft-ietf-ace-oauth-params?


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] Resource, Audience, and req_aud

[Ludwig Seitz]

On 07/02/2019 16:24, Hannes Tschofenig wrote:

Hi all,

after re-reading token exchange, the resource indicator, and the 
ace-oauth-params drafts I am wondering whether it is really necessary to 
have different functionality in ACE vs. in OAuth for basic parameters.


Imagine I use an Authorization Server and I support devices that use 
CoAP and HTTP.


 1. If a device uses CoAP then it has to use the req_aud parameter to
indicate to the authorization server that it wants to talk to a
specific resource server. It would either put a URI or a logical
name there.




 2. If a device uses HTTP then it has to use either the resource
parameter to indicate to the authorization server that it wants to
talk to a resource server, which is identified using a URI, or the
audience parameter, if it uses a logical name. 

We were told by OAuth that this is not how the audience parameter is 
used. What I understood from the feed-back is that using a parameter 
called "aud" in a request to the token endpoint would be interpreted as 
a restriction on the audience of authorization servers that are 
addressed by this request.


That said, I'm all for alignment, but I'd like the parameter to be 
aligned with the JWT "aud" claim as well and currently "resource" is URI 
while "aud" is StringOrURI.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[Ludwig Seitz]

On 07/02/2019 16:15, Hannes Tschofenig wrote:

Hi Ludwig,


My interpretation of this is that "resource" refers to a single resource


No. Here is the text from token exchange (see last sentence):

resource

[...]

Multiple "resource" parameters may be used to indicate
   that the issued token is intended to be used at the multiple
   resources listed.



Enumerating the audience is not the same as addressing it by a group name.

I agree that without too much stretching of the definition of the 
resource parameter I could use URIs as group identifiers, however the 
audience claim is defined to be "StringOrURI" so if someone defines an 
audience identified by a String that is not an URI how does a client ask 
for that with the resource parameter?


Or in short: Why don't you make your resource parameter mirror the "aud" 
claim?


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51



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

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

[Ludwig Seitz]

Hello ACE,

this update takes care of the comments from the shepherd review (thanks 
Jim) and some further issues. See the changelog for details.


The only remaining issue is the one from here:

https://mailarchive.ietf.org/arch/msg/ace/GeB6NQbiJpscitlImg_UcJ7Vxj8

/Ludwig

 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-19.txt
Date: Thu, 31 Jan 2019 04:45:55 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



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

Name:   draft-ietf-ace-oauth-authz
Revision:   19
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-01-31
Group:  ace
Pages:  77
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-19.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Hello,

we have an unresolved review comment by Steffi that got lost in the 
holiday season:


https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U
https://mailarchive.ietf.org/arch/msg/ace/NrQWetugoy0TWp9eg3lwtSictc8


The issue is the following (my words):

The AS provides the client with key material used by the RS. This can 
either be a common symmetric pop-key, or an asymmetric key used by the 
RS to authenticate towards the client.


Since there is (currently) no metadata associated to those keys, the 
client has no way of knowing if these keys are still valid. This may 
lead to situations where the client sends requests containing sensitive 
information to the RS using a key that is expired and possibly in the 
hands of an attacker, or accepts responses from the RS that are no 
properly protected and could possibly have been forged by an attacker.



The options to resolve this that I currently see are this:


1. If the client has no additional data it MUST assume that the key is 
valid as long as the access token together with which it received that 
key. Since the access token is opaque to the client, the client MUST now 
determine how long the token is valid:


Option 1.1 The client is provisioned in advance with a default validity 
time for tokens issued by the AS. This could be done when the client is 
registered at the AS.


Option 1.2 The AS informs the client using the "expires_in" parameter in 
the Access Information.


This means that we need to implement a check whether the client knows a 
default validity, and if that is not the case reject an access token 
that does not come together with an "expires_in" parameter.


2. We can define a new parameter that informs the client specifically 
about the validity of the keys the RS uses, if that differs from the 
validity of the token. Note that this is a realistic use case, since the 
RS might use an asymmetric key for authentication that is valid for a 
significantly longer period than some access token.



I would need some feed-back from the group to proceed here.

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz

[Ludwig Seitz]

Thank you Jim,

I'll upload a new version as soon as we have resolved my questions below.

/Ludwig

On 30/01/2019 07:01, Jim Schaad wrote:

1. Update the reference from RFC 5246 to RFC 8446 in all locations



Items that don't appear to be resolved:

* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.
 Unless you are going to say that this is not OAuth 2.0, then a
refresh token is still a text string.

*  I don't see any text that is addressing this.


That text just describes how it is in OAuth 2.0 (where refresh tokens 
are strings), since we didn't see the need to specify the use of refresh 
tokens in ACE, we didn't mention them further. If we had we would 
certainly have defined them to be binary.





On 22/10/2018 21:09, Jim Schaad wrote:

* Section 5.8.2 - If the RS is going to do introspection, can it send

some

type of "Server Busy - try again in xxx" while it does the introspection
rather than just doing an ack of the request and possibly waiting a long
time?


This is probably transport protocol specific, and we were asked not to
link the framework to a specific protocol, thus I don't know if we can
provide guidance here.


I think it would be okay to say something like "some transport protocols
may provide a way to indicate that the server is busy and the client should
retry after an interval; this type of status update would be appropriate
while the server is waiting for an introspection response".  Which does
provide guidance, but in a non-normative fashion that does not require or
prohibit any given transport protocol.

*  I don't see anything that I think addresses this issue.  I would expect
it to be a security consideration


There is text in the draft according to the suggestion above in section 
5.8.1 "The Authorization Information Endpoint". Should that text be 
moved to security considerations?




Comments on protection of CWT/Token:  I am wondering if there needs to be
any comments on how a CWT is going to be protected.  While it is ok to use
either a symmetric key or a direct key agreement operation for a single
recipient without forcing a signature operation to occur.  If the token is
going to be targeted a single audience hosted on multiple RSs then a
signature operation would be required for the purposes of authentication.



Right. I'll add some security considerations on that.



** IANA Section Issues

1.  None of the new registries appear to have any guidance for the DEs to
use when approving items.


Is it acceptable to add a single guidance section for all of the new 
registries, or does it need to be separate for each of them?




2.  The title of the registry "ACE Authorization Server Information" is not
really descriptive of what is in the registry.   It makes sense in the text
but not as a stand along title.  Something along the lines of "ACE
Authorization Server Request Creation Hints" seems to be closer to a solid
identification.


Would "ACE Authorization Server Discovery Hints" be better?


3.  The mapping registries should use the OAuth registry name as a prefix.
Thus "OAuth Access Token Types" and "OAuth Access Token Type CBOR Mappings".

Done. Actually quite some changes were required to align all of the 
mappings sections with the OAuth registry names.



4.  What is the initial registrations that need to occur for the "ACE
Profile" registry.  If there are none then this needs to be stated.

It's initially empty, since draft-ieft-ace-oauth-authz doesn't define a 
profile. However the DTLS and OSCORE profile will provide the two 
initial entries. I added a sentence to that effect in the IANA section.



5. For the CBOR Web Token Claims - how many of these should have the JWT
Claim name filled in?  It would seem that all of them should.  If not a
comment about this is needed.

Fixed.

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Shepard review comments on draft-ietf-ace-oauth-params

[Ludwig Seitz]

On 29/01/2019 23:09, Jim Schaad wrote:

1.  In section 9.2 - While reviewing the IANA considerations, I was not sure
if the JWT Claim Name be set to "rs_cnf".  If it is then please update the
draft.  If not then please explain why.

Jim



That was an oversight. Fixed now in -03.

/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

I have uploaded a new version of draft-ietf-ace-oauth-params, addressing 
the remaining review comments and fixing some typos.


I believe I have addressed all reviews on this document, please 
double-check if that is indeed the case.


Regards,

Ludwig


 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-params-02.txt
Date: Tue, 29 Jan 2019 00:59:05 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz 


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

Name:   draft-ietf-ace-oauth-params
Revision:   02
Title:		Additional OAuth Parameters for Authorization in Constrained 
Environments (ACE)

Document date:  2019-01-29
Group:  ace
Pages:  14
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-params-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/

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


Abstract:
   This specification defines new parameters for the OAuth 2.0 token and
   introspection endpoints when used with the framework for
   authentication and authorization for constrained environments (ACE).
   These are used to express the desired audience of a requested access
   token, the desired proof-of-possession key, the proof-of-possession
   key that the AS has selected, and the key the RS should use to
   authenticate to the client.




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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

[Ludwig Seitz]

On 28/01/2019 23:12, George Fletcher wrote:
I also don't know that this raises to the level of "concern" but I find 
the parameter name of "req_aud" odd. Given that the parameter in the 
resource-indicators spec is 'resource' why not use a parameter name of 
'audience'. That said, I have not read the thread on the ACE working 
group list so there could be very good reasons for the chosen name:)


I do think that there is a lot of overlap (in most cases) between 
'resource' and 'audience' and having two parameters that cover a lot of 
the same semantics is going to be confusing for developers. When calling 
an API at a resource server, the 'audience' and the 'resource' are 
pretty equivalent. Maybe in other use cases they are distinctly separate?




To give you all the background of "req_aud" from ACE (sorry for the long 
text):


Originally in ACE we had defined the "aud" parameter for requests to the 
token endpoint with the semantics that the client was requesting a token 
for a certain audience (i.e. requesting that the AS copy the "aud" 
parameter value into the "aud" claim value of the token).
We were then told that this collided with a use of "aud" in OAuth, that 
specifies the intended audience of Authorization Servers (if I remember 
correctly), so we decided to rename our parameter to "req_aud" for 
"requested audience".
Mike Jones then made us aware of the work on resource indicators, but 
upon closer examination I found the "resource" parameter to be more 
limited than the "req_aud", since resource specifically states:


"Its value MUST be an absolute URI ... the "resource" parameter URI 
value is an identifier representing the identity of the resource"


My interpretation of this is that "resource" refers to a single 
resource, which is more constrained than the definition of the "aud" 
claim from 7519, which uses a StringOrURI value.  For example my intent 
was to use "aud" and "req_aud" for group identifiers 
("temperatureSensorGroup4711") and other non-uri strings 
(hash-of-public-key), which I cannot do with "resource".  We therefore 
decided to keep the "req_aud" parameter in draft-ietf-ace-oauth-params, 
even though is clearly overlaps with "resource".


Any comments and suggestions about that line of reasoning (especially 
from the OAuth point of view) are very welcome.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

Hello ACE,

I have uploaded a new version of draft-ietf-ace-oauth-authz based on the 
review by and discussion with Stefanie Gerdes (thank you!).


Please check whether there are any issues remaining.


/Ludwig

 Forwarded Message 
Subject: New Version Notification for draft-ietf-ace-oauth-authz-18.txt
Date: Thu, 17 Jan 2019 06:45:56 -0800
From: internet-dra...@ietf.org
To: Ludwig Seitz , Hannes Tschofenig 
, Goeran Selander 
, Samuel Erdtman , 
Erik Wahlstroem 



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

Name:   draft-ietf-ace-oauth-authz
Revision:   18
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2019-01-17
Group:  ace
Pages:  75
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-18.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Token (In)Security

[Ludwig Seitz]

On 18/12/2018 15:48, Stefanie Gerdes wrote:

Hi Hannes,

I think the text is much better now. Protecting the integrity of
self-contained tokens is not sufficient, however. The RS must not only
ascertain that the token is integrity-protected but also validate its
authenticity, i.e., that it stems from an authorized AS.

Viele Grüße
Steffi



Hi,

I've merged Hannes' PR, fixed a typo and added a sentence as follows:
=
For self-contained tokens the RS MUST process the security protection of 
the token first, as specified by the respective token format. ~snip~ 
This MUST include a verification that security protection (and thus the 
token) was generated by an AS that has the right to issue access tokens 
for this RS.

=

I have not extended this requirement to tokens passed as a reference, 
since in that case the RS needs to do introspection at an authorized AS 
anyways. It would thus not get the claims of a token issued by an 
unauthorized AS, which would in turn lead to the token being discarded.


Does that sound correct to you all?

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz]

On 19/12/2018 21:22, Jim Schaad wrote:





In step (4) you tie the expiry of the token to the attacker
getting hold of the key. What happens if the attacker gets hold
of the pop key before the token expires?


If it is detected the AS would revoke the token. Then the client
_could_ use client introspection to get that information. Note that
this is what the CMU people are looking at.


I am having a real problem with the idea that we are going to start
adding the idea of revocation to the entire system.   I would much
rather make sure that both sides are given an idea of when things are
going to expire and just make things expire relatively quickly.



It's quite unlike the revocation in PKI, it's just that an AS can mark a 
token as invalid, and this information would then be available to those 
who can do introspection.




Additionally, if you use DTLS/TLS just having the PoP key still 
requires the attacker to run a new DTLS/TLS handshake with the

RS.


If the pop-key was used as a basis for doing a DTLS-PSK handshake,
the attacker should be able to hijack the connection and
impersonate either party.


This depends on the version of PSK that you are doing.  If you use
PSK+ECDH then the attacker cannot hijack the connection.



Right of course. I suspect however that not all constrained devices 
would implement the PSK+ECDH handshake, or are the other PSK handshakes 
deprecated?






It would also be useful to know where the attacker got the PoP
key from and how you can even detect the compromise.


That is a different story entirely. You could imagine the case of
an RS improperly deleting an expired token and the associated
pop-key, and then being subject to a physical attack that recovers
that information.


It would be more reasonable to say that if you are doing a physical
attack, then it would be easy to get an RPK and then you are the RS
until such a time as the AS is told that the key is no longer
trusted.  In this case you will just continue getting tokens as a
client which are still valid and none of this is helpful in any
event.


Ok my example was perhaps not ideal, since it has an even bigger breach 
as precondition. So under what conditions would an attacker get access 
to a pop-key of an expired token? Steffi any ideas?


/Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz]

On 19/12/2018 14:04, Hannes Tschofenig wrote:

Thanks, Ludwig. The list of steps below help me to understand the concern.




1.) C obtains token and pop-key from AS
2.) C transmits token to RS and sets up secure communication (e.g.
DTLS-PSK) using the pop-key
3.) C sends secure requests to the RS
4.) token expires, an attacker manages to get hold of the pop-key
5.) C continues to send requests containing sensitive information to the RS , 
attacker can now read the messages and spoof positive responses from the RS. C 
never notices that the token is invalid and that it is actually talking to the 
attacker.






In step (4) you tie the expiry of the token to the attacker getting
hold of the key. What happens if the attacker gets hold of the pop
key before the token expires?


If it is detected the AS would revoke the token. Then the client _could_ 
use client introspection to get that information. Note that this is what 
the CMU people are looking at.



Additionally, if you use DTLS/TLS just
having the PoP key still requires the attacker to run a new DTLS/TLS
handshake with the RS.


If the pop-key was used as a basis for doing a DTLS-PSK handshake, the 
attacker should be able to hijack the connection and impersonate either 
party.




It would also be useful to know where the
attacker got the PoP key from and how you can even detect the
compromise.


That is a different story entirely. You could imagine the case of an RS 
improperly deleting an expired token and the associated pop-key, and 
then being subject to a physical attack that recovers that information.




Additionally, there is the question why the RS wouldn't stop
communicating if the token expired since it has that information.


The RS would indeed stop, but since the token is opaque to the client, 
it has no way of knowing that the token has expired, and our clever 
attacker is using the pop-key to impersonate the RS and maintain the 
illusion that the connection is still alive an running.



Normally, the idea is that the RS has a protected resource and the
client wants to access it. That's why the RS is asking the client to
send a token that gives it access.



Yes but say e.g. that the RS is a message broker and the client is a 
publisher, writing sensitive data to the RS.



I think Steffi's point definitely warrants text in the security 
considerations, outlining how a client could detect that a token has 
expired.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz]

On 19/12/2018 12:46, Stefanie Gerdes wrote:

Hi Hannes,

On 12/19/2018 12:36 PM, Hannes Tschofenig wrote:

Hi Steffi,

Are you focused on token expiry or the case where a token + symmetric key has 
been leaked?


I am talking about the expiry of the keying material for RS that AS
provides to C.



Is the threat you are describing the case where the client uses DTLS/TLS with 
the RS (potentially long after a token has been presented), or the case where 
the client contacts the RS and presents a token?


I am worried about cases where the client communicates securely with RS,
e.g., using DTLS/TLS or object security, not about presenting the token
to RS.

Viele Grüße
Steffi




The scenario Steffi is thinking of is this (if I understood correctly):


1.) C obtains token and pop-key from AS
2.) C transmits token to RS and sets up secure communication (e.g. 
DTLS-PSK) using the pop-key

3.) C sends secure requests to the RS
4.) token expires, an attacker manages to get hold of the pop-key
5.) C continues to send requests containing sensitive information to the 
RS , attacker can now read the messages and spoof positive responses 
from the RS. C never notices that the token is invalid and that it is 
actually talking to the attacker.



A reasonable way to prevent this is to give the client a way to 
determine whether a token has been revoked or is expired.
This former can be done through some form of client introspection, the 
latter can be achieved with the expires_in parameter.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz]

On 18/12/2018 14:51, Hannes Tschofenig wrote:

Hi Steffi, Hi Ludwig,

~snip~


The access information optionally can contain an expires_in
field. It would help to prevent security breaches under the
following conditions:
1. the keying material is valid as long as the ticket, 2. the 
expires_in field is present in the access information that AS sends

to C, 3. the client checks the expires_in field when it gets the
access information from the AS, and 4. the client checks if the
keying material is still valid each time before it sends a request
to RS.

These checks make sense to me.


Are you proposing we make the expires_in field mandatory? If so, why
isn't it mandatory already in OAuth (currently only RECOMMENDED)?

[Hannes] I would do the check when the field is actually there.
However, it is a good question why it is not mandatory in OAuth. Let
me drop a mail to the list.


Now that I got a response from the OAuth working group (in the sense
that I was thinking about the claims in the access token rather than
the parameters in the response from the AS) I think checking the
expires_in field has to be optional since * the expires_in parameter
is optional, and * it only has an advisory nature.

It is useful to send the parameter so that the client can determine
when to request a new access token (for example, via the refresh
token) but it is not absolutely necessary for the protocol
operation.

Ciao Hannes


Hannes,

Steffi's point was (and remains) that if we don't give the client a way 
to determine whether the token is not expired (except for client 
introspection), it might use an expired token and old keys to 
communicate with the RS.
The argument if I understood Steffi correctly is that the client's 
request may contain sensitive data (think a POST/PUT with some 
significant payload) and that sending it to an RS with outdated keys 
might be a risk.


My take would be that in cases where this is relevant, one would specify 
a profile where the expires_in parameter is mandatory. Furthermore we 
should add text to the security considerations describing the issue.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Security of the Communication Between C and RS

[Ludwig Seitz]

On 15/12/2018 16:04, Hannes Tschofenig wrote:

Hi Steffi,

~snip~


I really think you should point out that symmetric keying material
that the AS provides to the client is valid as long as the token.


I think that's a useful recommendation. I do, however, believe that
we are not making the same assumption for an asymmetric key bound to
the token.



Ok, I'll add text to the draft that says this.

Note that this can be trouble if a client asks the AS to bind an 
existing symmetric pop-key to another (new) token it is requesting.
Which one of the two tokens bound to that key is now steering the 
expiration of the key?




I also think that the client must be able to assume that RS' RPK
that C receives from AS is also valid as long as the token, unless
C has additional information.


I would think that it is rather unlikely that the RS will change its
public/private key pair so quickly. Right?



Agree with Hannes here. RPKs wouldn't typically be changed that fast.



The access information optionally can contain an expires_in field.
It would help to prevent security breaches under the following
conditions:

1. the keying material is valid as long as the ticket, 2. the
expires_in field is present in the access information that AS sends
to C, 3. the client checks the expires_in field when it gets the
access information from the AS, and 4. the client checks if the
keying material is still valid each time before it sends a request to
RS.

These checks make sense to me.

Are you proposing we make the expires_in field mandatory? If so, why 
isn't it mandatory already in OAuth (currently only RECOMMENDED)?


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Token (In)Security

[Ludwig Seitz]

On 15/12/2018 15:58, Hannes Tschofenig wrote:

Hi Steffi

I checked the text and the text is indeed confusing.

I have made an attempt to update it to address your comment. Here is the pull 
request:
https://github.com/ace-wg/ace-oauth/pull/168

Let me know if you think I captured everything properly.

Ciao
Hannes



I agree that your text improves the "verification" section.

I'm holding off with merging in order to wait for Steffi's confirmation 
that it addresses her comments.


/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
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-17.txt and draft-ietf-ace-oauth-params-01.txt

[Ludwig Seitz]

On 13/12/2018 15:42, Stefanie Gerdes wrote:

Hi Ludwig,

On 12/12/2018 10:47 AM, Ludwig Seitz wrote:


The value of checking the iss field is indeed limited, but if present I
feel it MUST be checked.

The text does say that the RS must check the integrity of the token (see
5.8.1.1.)

"Since the cryptographic wrapper of the token (e.g. a COSE message)
could include encryption, it needs to be verified first, based on shared
cryptographic material with recognized AS."

This implies that the RS must check that the AS is recognized, I will
rephrase this to clarify that "recognized" means that the AS is
authorized to issue tokens for the RS.


I cannot find the term "integrity" in section 5.8.1.1. Encryption is not
the same as integrity protection. 


"Cryptograpic wrapper" can include integrity protection.

The reason encryption is specifically mentioned here is that you have to 
process the crypto wrapper first, before doing any checks on the claims, 
since they could be encrypted. I have tried to rephrase this in the 
editor's version to clarify.


(Side note: Basically you would want to do it the other way around, 
since it is much less resource consuming to verify the claims compared 
to verifying the crypto wrapper. Thus if you could discard a token due 
to some issue with the claims without having to check the crypto you 
would save some energy and time. Sadly since the token could be 
encrypted you cannot do it in that order)



Also, providing a "cryptographic
wrapper" for the token seems to be optional, which means that RS does
not necessarily check the authenticity of the token. The RS must check
that the token stems from an authorized AS, otherwise anyone can issue a
token to RS.



In OAuth you have different types of tokens, CWTs and JWTs typically 
have a cryptographic wrapper (but see section 6 of RFC 7519), but a 
token could just as well only be a random identifier, that the RS has to 
perform introspection on to learn the associated claims. Such a 
"reference token" would not have a cryptographic wrapper.



BTW, "shared cryptographic material with recognized AS" implies that
only symmetric solutions can be used between RS and AS. Is that what you
intend here?


Not really, "shared cryptographic material" could be public keys that 
the AS and RS have shared with each other.



The current text to the iss field implies that this field somehow helps
RS to determine the origin of the token, but this is not the case.
Anyone can write an authorized issuer into an issuer field. Authenticity
can only be achieved with cryptographic measures.

I agree that the iss claim is not really useful to authenticate the 
issuer, however if it is present in the token the RS should process it. 
The text I wrote was not intended to imply that it helps with anything:


"The issuer claim must identify an AS that has the authority to issue 
access tokens for the receiving RS. If that is not the case the RS MUST 
respond with a response code equivalent to the CoAP code 4.01 
(Unauthorized)."


This text is just instructions on how to process the claim.

The authenticity of the issuer would either be verified by the the 
cryptographic wrapper or by introspection.


(Side note: If an RS gets a "reference token" it would implicitly verify 
the authenticity of the issuer by doing introspection at the AS that is 
authorized to issue tokens for it).





Instead of demanding that the exp field is checked the document should
demand that the RS somehow validates that the token is not expired.

Checking

the exp field may be one example.

The document demands that exp is checked _if present_.
I don't like to normatively require something that is not concrete such
as "somehow validate that the token is not expired". If we define other
ways than exp and exi, then normative requirements should be placed in
the documents that define those.


So you say that the exp field is optional. And the exi field is
optional. If they are missing, the RS does not check if the token is
still valid and may use outdated tokens.


No if both fields are missing, the token is valid indefinitely, until 
explicitly revoked.



For the security of the
solution it is required that the RS checks if the token is still valid.
You should point out this requirement to achieve a secure solution. 


Yes but the RS can only do this based on the claims associated to the 
token. Certain profiles may require certain sets of claims to be in the 
token (e.g. aud, scope, exp/exi), but putting such requirements in the 
framework would be quite a big divergence from OAuth.




Well you have several cases of keying material here:

a.) A symmetric pop-key bound to one or more tokens. That will only be
valid as long as there is a valid token.

b.) An asymmetric key belonging to either client of RS, which may be
bound to a token, or used to authenticate (e.g

Re: [Ace] Overwriting Tokens

[Ludwig Seitz]

On 12/12/2018 10:33, Stefanie Gerdes wrote:

Hi again,

I have one additional comment to ace-oauth-17:

Section 5.8.1 recommends that RS stores only one token per key and that
existing tokens are overwritten by new tokens. I wonder how the RS knows
which token is the most recent. I don't think the expiration time helps
in this case because it should be possible for the AS to
provide a token that expires earlier than the previous token.


Viele Grüße
Steffi



"Recent" here is meant as "most recently received". That is something 
the RS definitely can track.


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
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-17.txt and draft-ietf-ace-oauth-params-01.txt

[Ludwig Seitz]

On 12/12/2018 10:27, Stefanie Gerdes wrote:

Hi Jim,

thank you for your quick response.

On 12/11/2018 09:38 PM, Jim Schaad wrote:


C may receive keying material for the communication with RS from AS.
Unfortunately, the AS does not inform C how long the keying material is

valid. C

therefore may use outdated keying material for the communication. C cannot
rely on RS to reject messages that were sent with outdated keying material
because 1. the information in the request sent by C may be confidential

and is

then compromised and 2. C cannot be sure that it is actually communicating
with the intended RS if the keying material is no longer valid.


Would you feel that this would be eased by requiring the expires_in field to
be required as part of the response?  It is the expiration of the token, but
I have never understood the difference between the expiration of the token
and the expiration of keying material myself.  Keying material never
expires, you just cannot use it without a valid token.


As long as it is clear that the expires_in field describes the time
until the keying material expires, this is at least better than nothing,
although it leaves the problem that the client does not know when the
token was created and how much time has already passed since then.

The ACE framework should also point out that a client must check if its
keying material for RS is still valid before it makes a request.

BTW, I don't think keying material should be valid forever, especially
if there is no useful revocation mechanism.



Note that expires_in (exi) is currently defined as "expires in x seconds 
from the time at which the RS first saw the token".


I am aware that this is quite weak since malicious clients can hoard 
tokens that would be valid indefinitely. I do not currently see any 
other means of expiration when the RS has no connectivity to the AS and 
no synchronized clock. I would be open for suggestions if you have 
better ideas.





I did not find any indication how the client knows how to choose the

correct

req_aud for RS. The document must point out that C may communicate with
the wrong RS unless C and AS have a common understanding how RS is
identified.


Scope is also something that the client does not know how to build.


In the worst case, a wrong scope can only prevent a client from
accessing a certain resource. Even if the client does not specify any
scope, the AS can still grant it permissions. If they are broad enough,
they will likely cover the resource that C wants to access.
A wrong req_aud however may cause the client to communicate with the
wrong RS. Even worse, C will not be able to notice that it communicates
with the wrong RS. This is a serious security risk.  > Currently, the ACE
framework does not even acknowledge that such a risk exists.

We do acknowledge that, in the security considerations of 
draft-ietf-ace-oauth-params where req_aud is defined. I'll add 
additional clarification to that text though, since it currently only 
talks about the needing to RS know which audiences it recognizes.





--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
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-17.txt and draft-ietf-ace-oauth-params-01.txt

[Ludwig Seitz]

On 11/12/2018 21:38, Jim Schaad wrote:




-Original Message-
From: Ace  On Behalf Of Stefanie Gerdes
Sent: Tuesday, December 11, 2018 4:11 AM
To: Ludwig Seitz ; ace@ietf.org
Subject: Re: [Ace] Fwd: New Version Notification for

draft-ietf-ace-oauth-authz-

17.txt and draft-ietf-ace-oauth-params-01.txt

Hi,

I looked through the document again. Many issues have been fixed, but I

still

have some comments:

I still think that Section 5.8.1, in particular 5.8.1.1 should point out

that RS must

check the integrity of the token und validate that it stems from an

authorized

AS. Checking the iss field does not help in this case and I don't see much

value

in this check; cryptographic assurance such as AS' signature or MAC of the
token is required to ascertain the authenticity, and in this case the

issuer, of the

token.


I would agree with this.  I have never been sure why the 'iss' field is
going to be useful.  The only place that I can see this would be an AS which
is using one key but two identities.  I would argue that this is a situation
that is prone to configuration errors and incorrect security.



The value of checking the iss field is indeed limited, but if present I 
feel it MUST be checked.


The text does say that the RS must check the integrity of the token (see 
5.8.1.1.)


"Since the cryptographic wrapper of the token (e.g. a COSE message) 
could include encryption, it needs to be verified first, based on shared 
cryptographic material with recognized AS."


This implies that the RS must check that the AS is recognized, I will 
rephrase this to clarify that "recognized" means that the AS is 
authorized to issue tokens for the RS.




5.8.1. exiting -> existing


Fixed.



Section 5.8.1. states that RS must check that the expiration time given in

the

exp field is in the future. This is difficult if the RS is not time

synchronized.


Indeed, but in those cases one wouldn't use the exp claim in the first 
place. I will add some text to the assumptions on AS knowledge about C 
and RS to the effect that the AS should know if the RS can manage 
synchronized time.




Option 3 in section 5.8.3 seems to suggest that this field is not always

required.

Indeed no claim is specifically required in the framework.


Instead of demanding that the exp field is checked the document should
demand that the RS somehow validates that the token is not expired.

Checking

the exp field may be one example.

The document demands that exp is checked _if present_.
I don't like to normatively require something that is not concrete such 
as "somehow validate that the token is not expired". If we define other 
ways than exp and exi, then normative requirements should be placed in 
the documents that define those.




C may receive keying material for the communication with RS from AS.
Unfortunately, the AS does not inform C how long the keying material is

valid. C

therefore may use outdated keying material for the communication. C cannot
rely on RS to reject messages that were sent with outdated keying material
because 1. the information in the request sent by C may be confidential

and is

then compromised and 2. C cannot be sure that it is actually communicating
with the intended RS if the keying material is no longer valid.


Would you feel that this would be eased by requiring the expires_in field to
be required as part of the response?  It is the expiration of the token, but
I have never understood the difference between the expiration of the token
and the expiration of keying material myself.  Keying material never
expires, you just cannot use it without a valid token.



Well you have several cases of keying material here:

a.) A symmetric pop-key bound to one or more tokens. That will only be 
valid as long as there is a valid token.


b.) An asymmetric key belonging to either client of RS, which may be 
bound to a token, or used to authenticate (e.g. in a DTLS-RPK 
handshake). Those are valid independently of the ACE framework and need 
to be managed, updated and expired by some other mechanisms.


c.) A symmetric key shared between C-AS or RS-AS for authentication 
purposes. ACE has no mechanisms for managing and updating this kind of 
keys. Starting to look into this looks lite a rat-hole to me.


Does any of you feel we should document this in the framework? I'm 
currently leaning towards no, but could be convinced otherwise.




I did not find any indication how the client knows how to choose the

correct

req_aud for RS. The document must point out that C may communicate with
the wrong RS unless C and AS have a common understanding how RS is
identified.


Scope is also something that the client does not know how to build.


Learning the correct req_aud and scope is out of scope (no pun intended) 
for ACE. This would either be part of the configuration of a client, or 
a client could look it up in some resource directory.
I'll add the note about needing to 

[Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

[Ludwig Seitz]

Hello ACE,

I have just submitted new versions for draft-ietf-ace-oauth-authz and 
draft-ietf-ace-oauth-params addressing the WGLC review comments and the 
discussions from the IETF 103 meeting.


I would encourage the reviewers to check if they feel that I have 
sufficiently addressed their comments.



Regards,

Ludwig

 Forwarded Message 

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

Name:   draft-ietf-ace-oauth-authz
Revision:   17
Title:		Authentication and Authorization for Constrained Environments 
(ACE) using the OAuth 2.0 Framework (ACE-OAuth)

Document date:  2018-11-26
Group:  ace
Pages:  74
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-authz-17.txt

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


Abstract:
   This specification defines a framework for authentication and
   authorization in Internet of Things (IoT) environments called ACE-
   OAuth.  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

 Forwarded Message 

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

Name:   draft-ietf-ace-oauth-params
Revision:   01
Title:		Additional OAuth Parameters for Authorization in Constrained 
Environments (ACE)

Document date:  2018-11-26
Group:  ace
Pages:  14
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-params-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-params/

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


Abstract:
   This specification defines new parameters for the OAuth 2.0 token and
   introspection endpoints when used with framework for authentication
   and authorization for constrained environments (ACE).  These are used
   to express the desired audience of a requested access token, the
   desired proof-of-possession key, the proof-of-possession key that the
   AS has selected, and the key the RS should use to authenticate to the
   client.





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


___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC comments on draft-ietf-ace-oauth-authz and draft-ietf-ace-params

[Ludwig Seitz]

On 23/11/2018 11:31, Ludwig Seitz wrote:

Hello ACE,

I have now addressed all WGLC comments (Jim Schaad's, Mike Jones' and 
Stefanie Gerdes') except for this one:


"Do we need to write something about how a RS should handle the presence 
of multiple tokens for the same client? Perhaps a security consideration?


I see two options:

1. Multiple tokens complement themselves i.e. if token A gives you right 
R1 and token B right R2 then you have R1+R2.


2. The newer token always overwrites the old one, which means if you 
want to extend your access rights as a client, when you already have A 
-> R1 you need to ask the AS for B*->R1+R2.

"
(see https://github.com/ace-wg/ace-oauth/issues/147).


AFAIK the common usage in OAuth is option 2, however Jim has pointed out 
use cases for option 1 and refers to it in

https://datatracker.ietf.org/doc/draft-schaad-cnf-cwt-id/


Jim has expressed a preference for 1. while Olaf has (in the Jabber at 
IETF 103) expressed a preference for 2.


I would need some guidance from the WG on how to proceed here.

/Ludwig



Btw. I haven't uploaded a new draft yet. Please use the editor's copy 
and the diff here: https://github.com/ace-wg/ace-oauth and here:

https://github.com/ace-wg/ace-oauth-params
/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] WGLC comments on draft-ietf-ace-oauth-authz and draft-ietf-ace-params

[Ludwig Seitz]

Hello ACE,

I have now addressed all WGLC comments (Jim Schaad's, Mike Jones' and 
Stefanie Gerdes') except for this one:


"Do we need to write something about how a RS should handle the presence 
of multiple tokens for the same client? Perhaps a security consideration?


I see two options:

1. Multiple tokens complement themselves i.e. if token A gives you right 
R1 and token B right R2 then you have R1+R2.


2. The newer token always overwrites the old one, which means if you 
want to extend your access rights as a client, when you already have A 
-> R1 you need to ask the AS for B*->R1+R2.

"
(see https://github.com/ace-wg/ace-oauth/issues/147).


AFAIK the common usage in OAuth is option 2, however Jim has pointed out 
use cases for option 1 and refers to it in

https://datatracker.ietf.org/doc/draft-schaad-cnf-cwt-id/


Jim has expressed a preference for 1. while Olaf has (in the Jabber at 
IETF 103) expressed a preference for 2.


I would need some guidance from the WG on how to proceed here.

/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] ACE Framework Review

[Ludwig Seitz]

On 12/11/2018 15:31, Michael Richardson wrote:



 > Management of the authz-info resource: * The authz-info resource is
 > vulnerable to DoS attacks: clients may (with or without intention) send
 > large numbers of access tokens to RS. A constrained RS may soon run out
 > of memory/storage space if it needs to store large numbers of

This seems like a really serious issue, and it seems that we need
an additional RTT to really fix it.



Note Steffi's words were: "store large numbers of tokens".

In order to have the RS store a large number of tokens, an attacker 
would need to have a large number of valid tokens for starters (since 
invalid tokens are not stored but discarded).


Furthermore, since the RS checks whether the audience of a token 
applies, and can safely discard tokens that do not have a matching 
audience the attacker would need to have a large number of tokens that 
all match an audience that this RS identifies with.


Finally we just learned at IETF 103 that OAuth typically does not use 
multiple, simultaneous access tokens for the same pair of client-RS. 
Thus if the token has a subject (sub claim) or some other binding to the 
client, the RS can safely discard all older tokens bound to the same client.


Therefore I propose that an attack that induces the RS to store a large 
number of tokens is quite hard to pull of.


Even so, lets still assume it would be possible, there is this part in 
the spec:


==
5.8.1.  The Authorization Information Endpoint


   The RS MUST be prepared to store at least one access token for future
   use.

==


This means that the RS can limit the total number of tokens it stores 
for future use based on its memory and storage space, as long as it 
stores at least one (in total, not per client).


Thus I'm curious what additional protections you would suggest are 
feasible and necessary for the authz-info endpoint?


/Ludwig



--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC for draft-ietf-ace-authz

[Ludwig Seitz]

On 23/10/2018 20:44, Jim Schaad wrote:



-Original Message- From: Ludwig Seitz  
Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad

; draft-ietf-ace-oauth- au...@ietf.org Cc:
ace@ietf.org Subject: Re: [Ace] WGLC for draft-ietf-ace-authz

Hallo Jim,

thank you for the review! Comments inline.

/Ludwig

On 22/10/2018 21:09, Jim Schaad wrote:




* Section 5.8.1 - What is the purpose of creating an identifier
for a token? Is this supposed to be used rather than the one from
the AS for something like shared secret TLS?  Note that this is
an unprotected value.


AFAIK cti is not a mandatory claim of an access token, thus a RS
might want to create an identifier for tokens that do not have a
cti.


Ok - so the client has this cti - what could it use it for?


You might want to treat the token as a RESTful resource under 
/authz-info that the client can GET or DELETE using the cti as part of 
the URI.


I admit this is never explicitly stated and would need to be worked out
quite a bit (as Steffi remarked, there would need to be access control
on the tokens), so I wouldn't argue against removing the comment from
the draft altogether.


* Section 5.8.1 - If the token is "not valid" is the RS required
(i.e. MUST) to try introspection before returning a response if
the RS does introspection?  The text currently says MAY.  If this
is really MAY then the text should say that the token is always
successfully accepted by the RS.

I'm not sure I understand the issue. Introspection is optional in 
general, and may be required in specific use cases. If the RS

determines that the token is not valid on its own, why would it
want to do introspection on top of this?


The RS has just received a token.  The RS wants to validate said
token.  It can do it on its own or it can do it with introspection.
If it is going to do it with introspection can it defer this
validation until first use or does it need to do it immediately so it
is not going to store an invalid token?  It is possible that an RS is
going to both support some tokens and require introspection on
others.  In that case it would decide the token was not valid, but
would not necessarily know if it was a legal introspection token.



I'm not convinced we need to REQUIRE a certain behavior here. I would 
however agree to put some text in the draft outlining these options and 
analyzing the resulting security implications.


Would that address your comment sufficiently?

/Ludwig




--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC for draft-ietf-ace-authz

[Ludwig Seitz]

On 22/10/2018 21:09, Jim Schaad wrote:



* Registries -  I am wondering if we should think about re-writing a couple
of the registries.  As things stand it appears that the application/ace+cbor
content type is being used in 5 or 6 places.  It might make more sense to
have a registry for all of the CBOR abbreviations that are being used in a
single table and have multiple columns for each of the different places were
the content format is being used.  This would make it easier to keep
everything constant and can make re-use of integer values easier to see.



Yes in the light of the ensuing discussion with Mike, Carsten and Olaf 
it is clear that the whole registry process needs a second (third, n-th) 
go-over.


I'd very much like to have all abbreviations in a single table, however 
some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure 
on where to do the table, since I'd like to have the parameters from 
there in it.




* Comments on protection of CWT/Token:  I am wondering if there needs to be
any comments on how a CWT is going to be protected.  While it is ok to use
either a symmetric key or a direct key agreement operation for a single
recipient without forcing a signature operation to occur.  If the token is
going to be targeted a single audience hosted on multiple RSs then a
signature operation would be required for the purposes of authentication.



In the light of your and Steffi's comments, this seems to merit a 
section in the security considerations.



* I am not sure where this issue should be raised so I am putting it here.
Both of the profiles have as their last security consideration a statement
that the use of multiple access tokens is a bad idea.  Both of them also
devote a large section of text to how to deal with multiple access tokens as
does this document.  More methods of having multiple access tokens seem to
be coming down the path from the OAuth group.  This appears to be a distinct
contradiction within the set of documents that should be resolved.



I'd like to have the view of our OAuth experts here: How is OAuth 
typically used, when a client needs to get more permissions than 
initially granted?
Is the old token invalidated and a new token issued, or is there 
something like "add-on" scopes in additional tokens?


Given the amount of trouble the handling of multiple tokens for one 
client-RS pair can raise, I'm not disinclined to forbid them or at least 
recommend against their use. However with audiences possibly addressing 
overlapping sets of RSs this might be more difficult than it looks.




/Ludwig


--
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace