[Ace] FW: New Version Notification for draft-selander-ace-object-security-05.txt

[Francesca Palombini]

Dear CoRE, COSE and ACE members,

We have submitted an update to the OSCOAP draft:
https://tools.ietf.org/html/draft-selander-ace-object-security-05

For those who don’t know, OSCOAP is an application layer security protocol for 
CoAP, based on wrapping request and response messages in COSE objects which are 
sent in a CoAP message exchange.

With this version, we aimed for improved readability and we added the blockwise 
functionality, as discussed during last f2f meeting.

We are now looking for reviews. Any comment or feedback would be greatly 
appreciated!

Best regards,
Francesca

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: den 7 juli 2016 18:37
To: Göran Selander <goran.selan...@ericsson.com>; Ludwig Seitz 
<lud...@sics.se>; John Mattsson <john.matts...@ericsson.com>; Göran Selander 
<goran.selan...@ericsson.com>; Francesca Palombini 
<francesca.palomb...@ericsson.com>
Subject: New Version Notification for draft-selander-ace-object-security-05.txt


A new version of I-D, draft-selander-ace-object-security-05.txt
has been successfully submitted by Francesca Palombini and posted to the IETF 
repository.

Name:   draft-selander-ace-object-security
Revision:   05
Title:  Object Security of CoAP (OSCOAP)
Document date:  2016-07-07
Group:  Individual Submission
Pages:  36
URL:
https://www.ietf.org/internet-drafts/draft-selander-ace-object-security-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-selander-ace-object-security/
Htmlized:   
https://tools.ietf.org/html/draft-selander-ace-object-security-05
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-selander-ace-object-security-05

Abstract:
   This memo defines Object Security of CoAP (OSCOAP), a method for
   application layer protection of message exchanges with the
   Constrained Application Protocol (CoAP), using the CBOR Object
   Signing and Encryption (COSE) format.  OSCOAP provides end-to-end
   encryption, integrity and replay protection to CoAP payload, options,
   and header fields, as well as a secure binding between CoAP request
   and response messages.  The use of OSCOAP is signaled with the CoAP
   option Object-Security, also defined in this memo.


  


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

[Ace] FW: New Version Notification for draft-palombini-ace-coap-pubsub-profile-00.txt

[Francesca Palombini]

Hi all,

I have submitted a new profile for ACE, aiming at a CoAP pub-sub type of 
scenario:

https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/

@chairs: I'd like to ask for 15 minutes to present this at the IETF98.

Best regards,
Francesca

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: den 13 mars 2017 16:21
> To: Francesca Palombini <francesca.palomb...@ericsson.com>
> Subject: New Version Notification for draft-palombini-ace-coap-pubsub-
> profile-00.txt
> 
> 
> A new version of I-D, draft-palombini-ace-coap-pubsub-profile-00.txt
> has been successfully submitted by Francesca Palombini and posted to the
> IETF repository.
> 
> Name: draft-palombini-ace-coap-pubsub-profile
> Revision: 00
> Title:CoAP Pub-Sub Profile for Authentication and 
> Authorization
> for Constrained Environments (ACE)
> Document date:2017-03-13
> Group:Individual Submission
> Pages:14
> URL:https://www.ietf.org/internet-drafts/draft-palombini-ace-coap-
> pubsub-profile-00.txt
> Status: https://datatracker.ietf.org/doc/draft-palombini-ace-coap-
> pubsub-profile/
> Htmlized:   https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-
> profile-00
> 
> 
> Abstract:
>This specification defines a profile for authentication and
>authorization for publishers and subscribers in a pub-sub setting
>scenario in a constrained environment, using the ACE framework.  This
>profile relies on transport layer or application layer security to
>authorize the publisher to the broker.  Moreover, it relies on
>application layer security for publisher-broker and subscriber-broker
>communication.
> 
> 
> 
> 
> 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] New Version Notification for draft-seitz-ace-oscoap-profile-04.txt

[Francesca Palombini]

Hi all,

The draft describing the OSCOAP profile has been updated.
Thanks to Jim Schaad for the thorough review that has been the base for this 
update.
Comments are welcome.

Francesca

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: den 24 juli 2017 09:50
> To: Ludwig Seitz <ludwig.se...@ri.se>; Martin Gunnarsson
> <martin.gunnars...@ri.se>; Francesca Palombini
> <francesca.palomb...@ericsson.com>
> Subject: New Version Notification for draft-seitz-ace-oscoap-profile-04.txt
> 
> 
> A new version of I-D, draft-seitz-ace-oscoap-profile-04.txt
> has been successfully submitted by Francesca Palombini and posted to the
> IETF repository.
> 
> Name: draft-seitz-ace-oscoap-profile
> Revision: 04
> Title:OSCOAP profile of the Authentication and Authorization 
> for
> Constrained Environments Framework
> Document date:2017-07-23
> Group:Individual Submission
> Pages:17
> URL:https://www.ietf.org/internet-drafts/draft-seitz-ace-oscoap-
> profile-04.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-seitz-ace-oscoap-profile/
> Htmlized:   https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile-04
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-seitz-ace-oscoap-
> profile-04
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-seitz-ace-oscoap-profile-04
> 
> Abstract:
>This memo specifies a profile for the Authentication and
>Authorization for Constrained Environments (ACE) framework.  It
>utilizes Object Security of CoAP (OSCOAP) and Ephemeral Diffie-
>Hellman over COSE (EDHOC) to provide communication security, server
>authentication, and proof-of-possession for a key owned by the client
>and bound to an OAuth 2.0 access token.
> 
> 
> 
> 
> 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] ace - Requested session has been scheduled for IETF 99

[Francesca Palombini]

Hi again,

I would also like to request a 10 minutes slot for EDHOC: 
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-07 
John will be the slot leader.

Thanks,
Francesca

> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of "IETF Secretariat"
> Sent: den 24 juni 2017 02:07
> To: ace-cha...@ietf.org; kepeng@alibaba-inc.com
> Cc: kathleen.moriarty.i...@gmail.com; ace@ietf.org
> Subject: [Ace] ace - Requested session has been scheduled for IETF 99
> 
> Dear Kepeng Li,
> 
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by the original request.
> 
> ace Session 1 (2:30:00)
> Monday, Morning Session I 0930-1200
> Room Name: Congress Hall I size: 250
> -
> 
> 
> 
> Request Information:
> 
> 
> -
> Working Group Name: Authentication and Authorization for Constrained
> Environments Area Name: Security Area Session Requester: Kepeng Li
> 
> Number of Sessions: 1
> Length of Session(s):  2.5 Hours
> Number of Attendees: 100
> Conflicts to Avoid:
>  First Priority: core oauth saag lwig tokbind tls
> 
> 
> 
> 
> People who must be present:
>   Kathleen Moriarty
>   Hannes Tschofenig
>   Kepeng Li
> 
> Resources Requested:
> 
> Special Requests:
>   Avoid entire SEC areas. Please avoid a session on Friday!
> -
> 
> ___
> 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] review of ace-cose-ecdhe

[Francesca Palombini]

Hi Dan,

Thank you so much for a very useful review and for your support!
Most of your comments have been incorporated in v-07. We'll come back for a 
discussion on the rest.

Thanks,
Francesca

> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Dan Harkins
> Sent: den 1 juli 2017 00:17
> To: draft-selander-ace-cose-ecdhe@ietf.org
> Cc: ace@ietf.org
> Subject: [Ace] review of ace-cose-ecdhe
> 
> 
>Hello,
> 
>I reviewed the latest version of this draft from
> https://ericssonresearch.githum.io/EDHOC. I hope it's not too late to get
> these in before the cut-off, if too late then please consider them as
> comments on -07. My comments are as follows:
> 
>   -- Technical
> 
>o Consider the ability to use a deterministic AEAD
> 
>  The definition of Enc() in section 2 makes it look deterministic
>  but the mandatory algorithm (CCM) is not. I know that cose doesn't
>  define how to use SIV (RFC 5297) but perhaps this draft should.
>  I hope you don't consider this as a mere request for a vanity cipher.
>  SIV does not need additional randomness, counters, or tweaks. It
>  is, in that sense, misuse resistant and ideal for use in a key
>  management protocol like EDHOC because it removes the possibility
>  of a security critical error being accidentally performed.
> 
>  If you choose to accept this comment you'll need to not just add
>  SIV to your IANA Considerations, you'll need to make reference in
>  section 3.2 the fact that an IV is not needed for deterministic
>  AEAD algorithms.
> 
>  A related comment, in section 3 it says "The application data may
>  e.g. be protected using the negotiated AEAD algorithm". The "e.g"
>  is superfluous but what if one desires to not do that, how is the
>  cipher for the application data negotiated with EDHOC?
> 
>o Use compact representation per RFC 6090
> 
>  The draft says, in section 3.1, that for EC2 curves to use point
>  compression. There is contention regarding IP on point compression.
>  (draft-ietf-cose-msg says in 13.1.1, this "encoding has not been
>  recommended in the IETF due to potential IPR issues.")Better to
>  specify the use of "compact representation" and "compact output" per
>  RFC 6090. Since this draft is just doing ECDH there is no need for
>  any indication of which y-coordinate should be used, it doesn't
>  matter if it's y or -y. And it saves a whole byte! :-)
> 
>o Validate received points when doing EC2 curves
> 
>  When using EC2 curves, the ephemeral keys in the first two messages
>  need to be validated as points on the curve. If you use "compact
>  representation" per RFC 6090 then it's a matter of checking whether
>  there is a solution to the curve definition for the given x. If you
>  choose not to use "compact representation" per RFC 6090 then you'll
>  need to make sure that received points (once uncompressed) are valid
>  points on the curve.
> 
>  This needs reference among the other verification checks in 4.2.3 and
>  4.3.3 (for asymmetric EDHOC), and 5.2.3 and 5.3.3 (for symmetric EDHOC)
>  which result in an error message if they fail.
> 
>   -- Editorial
> 
>o Section 2, seconded bulleted paragraph, it is "full-fledged" with a "d".
> 
>o In 4.3.3 last paragraph, Party U should send the error message back,
>  right? Not Party V.
> 
>This is a very well-written draft and I am happy to see SIGMA being applied
> to every layer of the stack.
> 
>regards,
> 
>Dan.
> 
> 
> ___
> 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] ace - Requested session has been scheduled for IETF 99

[Francesca Palombini]

Hi Ace, chairs,

I would like to request 5-10 minutes to present the updates on the Ace OSCOAP 
profile: https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile 

Thanks,
Francesca

> -Original Message-
> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of "IETF Secretariat"
> Sent: den 24 juni 2017 02:07
> To: ace-cha...@ietf.org; kepeng@alibaba-inc.com
> Cc: kathleen.moriarty.i...@gmail.com; ace@ietf.org
> Subject: [Ace] ace - Requested session has been scheduled for IETF 99
> 
> Dear Kepeng Li,
> 
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by the original request.
> 
> ace Session 1 (2:30:00)
> Monday, Morning Session I 0930-1200
> Room Name: Congress Hall I size: 250
> -
> 
> 
> 
> Request Information:
> 
> 
> -
> Working Group Name: Authentication and Authorization for Constrained
> Environments Area Name: Security Area Session Requester: Kepeng Li
> 
> Number of Sessions: 1
> Length of Session(s):  2.5 Hours
> Number of Attendees: 100
> Conflicts to Avoid:
>  First Priority: core oauth saag lwig tokbind tls
> 
> 
> 
> 
> People who must be present:
>   Kathleen Moriarty
>   Hannes Tschofenig
>   Kepeng Li
> 
> Resources Requested:
> 
> Special Requests:
>   Avoid entire SEC areas. Please avoid a session on Friday!
> -
> 
> ___
> 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] Comments on draft-tiloca-ace-oscoap-joining

[Francesca Palombini]

Hi Jim,

I don't think that your statement is correct: as far as I understood the 
oscoap-joining document, the RS is the group manager, while in the pubsub 
document (even generalizing it and making a group communication profile as 
Carsten was suggesting) the entity that does group management is the AS2.

I consider these differences a reason to have separate documents, yes, they 
could be described in the same draft, but I don't see how that simplifies the 
specifications.

One more comment inline.

Thanks,
Francesca

> -Original Message-
> From: Jim Schaad [mailto:i...@augustcellars.com]
> Sent: den 20 oktober 2017 07:42
> To: draft-tiloca-ace-oscoap-join...@ietf.org; draft-palombini-ace-coap-
> pubsub-prof...@ietf.org
> Cc: ace@ietf.org
> Subject: Comments on draft-tiloca-ace-oscoap-joining
> 
> After the interim meeting, I read this document through in order to produce
> a review.  Instead you are going to get a meta-review.
> 
> I am having a hard to seeing why this document exists in its current form and
> it is not some type of simple profile of the pub-sub security draft.
> While I am not sure that this document is a sub-set of that document, it
> appears to be about 90-99% a sub set of that document.  Consider the
> following:
> 
> You have both the publisher and subscriber roles as in the pub-sub draft.
> 
> You have an entity which is doing key distribution in the system.  For the 
> pub-
> sub draft this is AS2 for you it is the RS, but they are performing the exact
> same set of tasks.
> 

Yes, they are performing the same set of tasks on a high level, but they are 
using the ACE framework differently in practice. For example the publisher and 
subscriber acquire the keys without using the token.

> The pub-sub draft as and endpoint which holds the encrypted messages, in
> its place you are using the multi-cast UDP channel.  In both cases they are
> basically unprotected-untrusted entities to distribute the content message.
> The only difference is that in the pub-sub model the RS will also provide
> restricted access to publishing which is not enforceable here.
> 
> Both of these documents are missing what I would consider to be core
> pieces.
> The pub-sub document does initial key distribution, while this document
> does not.  Neither document does any discussion of how subsequent key
> distribution is done to deal with forward and backward security of messages.
>
> 
> This document probably needs to define a new relationship, which might be
> more generally used, to say - this URL is where you get the security
> information for this URL which is published in the directory - esp in the case
> of multi-cast address URLs in the resource directory.  You might also find 
> that
> the correct answer is not to use a separate resource for each channel, but to
> allow for the use of URI path elements to define the security for a resource.
> 
> Jim
>

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

[Ace] FW: New Version Notification for draft-palombini-ace-key-groupcomm-00.txt

[Francesca Palombini]

Hi all,

We submitted a new draft, that builds on the ACE Framework to generalize group 
communication profiles. This draft was the result of comments and discussion 
with several ACE participants, at IETF100.

https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-00 

I would like to request some time at IETF101 to get feedback from the group, 
and ask for reviews. 10 minutes should be enough, and I will be the presenter.

Francesca


> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: den 1 mars 2018 17:36
> To: Marco Tiloca <marco.til...@ri.se>; Francesca Palombini
> <francesca.palomb...@ericsson.com>
> Subject: New Version Notification for draft-palombini-ace-key-groupcomm-00.txt
> 
> 
> A new version of I-D, draft-palombini-ace-key-groupcomm-00.txt
> has been successfully submitted by Francesca Palombini and posted to the
> IETF repository.
> 
> Name: draft-palombini-ace-key-groupcomm
> Revision: 00
> Title:Key Provisioning for Group Communication using ACE
> Document date:2018-03-01
> Group:Individual Submission
> Pages:10
> URL:
> https://www.ietf.org/internet-drafts/draft-palombini-ace-key-groupcomm-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-palombini-ace-key-groupcomm/
> Htmlized:   
> https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-00
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-palombini-ace-key-groupcomm-00
> 
> 
> Abstract:
>This document defines a message format for distributing keying
>material in group communication scenarios (such as based on multicast
>or publisher-subscriber model) using the ACE framework.
> 
> 
> 
> 
> 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] I-D Action: draft-ietf-ace-oscore-profile-04.txt

[Francesca Palombini]

Hi all,

We have just submitted an updated version of the OSCORE profile for ACE. 
Mainly, this version adds some examples, expands on security considerations, 
expands on updating rights, fixes some references and minor errors leftover and 
improves readability.

Thanks,
Francesca

On 2018-10-08, 17:03, "Ace on behalf of 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   : OSCORE profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-04.txt
Pages   : 26
Date: 2018-10-08

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security, server authentication,
   and proof-of-possession for a key owned by the client and bound to an
   OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-04
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-04


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

[Ace] FW: New Version Notification for draft-palombini-ace-key-groupcomm-02.txt

[Francesca Palombini]

Hi all,

We have just submitted v-02 of the ace-key-groupcomm draft.

This version expands on the re-keying of group members, after nodes join or 
leave the group. It also tries to clarify the message exchange, giving an high 
level introduction before every subsection.

With this update, we hope to have answered most of the review comments from Jim 
and Peter (thank you!), we will come back to your reviews and answer to those 
in detail soon.

Thanks,
Francesca

On 22/10/2018, 14:48, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-palombini-ace-key-groupcomm-02.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-palombini-ace-key-groupcomm
Revision:   02
Title:  Key Provisioning for Group Communication using ACE
Document date:  2018-10-22
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/internet-drafts/draft-palombini-ace-key-groupcomm-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-palombini-ace-key-groupcomm/
Htmlized:   
https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-palombini-ace-key-groupcomm
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-palombini-ace-key-groupcomm-02

Abstract:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.


  


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 for draft-ietf-ace-oscore-profile

[Francesca Palombini]

Hi Jim,

It sounds like you are assuming that the Client would have to remember only one 
security context, but it is possible that the client has several (old) security 
contexts associated with one access token, for example if the RS has rebooted 
several times. It would be unreasonable to require the client to store and 
check all of those when deriving a new one (even if it is just the nonces). 

Also, it is not required that the AS provides a new access token to the Client, 
as it may be pre-generated and not expired. So in that case, if the client does 
not keep track of access tokens and security contexts it has used, it might end 
up with reused keys and nonces.

For both these reasons, we think that the client generated nonce is needed. If 
you agree with that, we can discuss where to transport these nonces, for 
example we can avoid echoing N1 if we use it as salt. Also, as you suggested, 
it seems like a good idea to make this mechanism optional. We prepare for 
discussion about this in Bangkok.

Thanks,
Francesca

On 25/10/2018, 23:25, "Jim Schaad"  wrote:



> -Original Message-
> From: Francesca Palombini 
> Sent: Thursday, October 25, 2018 4:47 AM
> To: Jim Schaad ; draft-ietf-ace-oscore-
> prof...@ietf.org
> Cc: ace@ietf.org
> Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile
> 
> Hi Jim,
> 
> Thank you for your review comments. We agree with all your points, and
> have opened issues: https://github.com/ace-wg/ace-oscore-profile/issues to
> get this fixed.
> 
> Inline some detailed answer.
> 
> Thanks,
> Francesca
> 
> On 22/10/2018, 21:09, "Jim Schaad"  wrote:
> 
> * Section 1 - I understand the reasoning behind having the server 
send back
> a nonce, although it would be good to have a description someplace 
about
> why
> this is being done.  (I would also make it optional as not all RS 
need to do
> this.)  I do not understand the reasoning behind having the client 
send a
> nonce to the server.
> 
> FP: The motivation for the nonce construction was in the security
> considerations, but I agree that having it in the Protocol Overview makes
> sense, so I opened an issue to fix that. The reason behind having the 
client
> create a nonce is that we are protecting against an attacker replaying an 
old
> RS message (containing an old nonce), which would provoke the creation of
> an old security context on the Client, and reuse of keys and nonces for a
> different (new) message.

So what you are looking at is a client which is going to "forget" the 
current security context that it possesses for an RS but not the token, 
re-posting the token to the RS because it apparently thinks that the RS has 
forgotten the token and context without and then accepting the replay as being 
valid.  

I think that a client which has forgotten the security context is also 
going to forget the token and thus need a new one.
I think that a client which is going to remember the security context is 
also going to remember the nonce from the server and thus not rebuild the 
context if the same nonce comes back.

If this needs to be explicit - then it should be made so.

> 
> * Section 3.1 - This is more general than the section, but you should 
not
> use the URI path in the text, instead you should be using the name 
that is
> in the authz document.
> 
> FP: Agreed, issue opened to fix this.
> 
> * Section 3.2 - Does it really make sense to use 'COSE_Key' to 
transport the
> key data?  Would a different field name be better?
> 
> FP: This was brought up several times, so we will make this change now.
> 
> * Section 3.2 - Please provide a justification for the requirement 
that the
> ids must be unique over the set of all clients and RS.   I can see 
that the
> client ids need to be unique on a single RS and RS ids need to be 
unique for
> any given client but not the broader statement.
> 
> FP: You are right, this requirement is too wide. We will replace with your
> suggestion.
> 
> * Please add an explicit section on when a RS and a client should 
discard
> the security context.
> 
> FP: Ok we will add this. As mentioned in the issue, I have now only this 3
> cases in mind: Partial IV space ends (either C or RS); the kid context on 
the RS
> side does not match with N1 (RS); C receives a number of Unauthorized (C),
> although that is a consideration/recommendations, details would be
> application specific. Do you see any other cas

Re: [Ace] Fwd: review of palombini-ace-key-groupcomm

[Francesca Palombini]

Hi Peter,

Thanks a lot for this detailed review! We have uploaded a new version that 
includes (most of) your 
comments:https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02

Detailed replies and some questions inline (see FP in red below).

Thanks,
Francesca

From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Peter van der Stok mailto:stokc...@bbhmail.nl>>
Organization: vanderstok consultancy
Reply-To: "consulta...@vanderstok.org" 
mailto:consulta...@vanderstok.org>>
Date: Tuesday, 31 July 2018 at 10:52
To: Ace Wg mailto:ace@ietf.org>>
Subject: [Ace] Fwd: review of palombini-ace-key-groupcomm

Hi key-groupcomm authors,

To start the review I have looked at the dependencies between the different 
involved drafts and came up with the figure below.

[cid:15330271085b60232491128797824427@bbhmail.nl]
The arrows indicate that a draft references another draft. The dots reference 
arrow means Informative reference. According to me, this means that the work on 
CORE can proceed independently of the work in ACE. The oscoap-join and 
key-groupcomm can proceed together to their conclusion without other 
dependencies. That guarantees that we can develop the group communication 
drafts in ACE without unwanted dependencies on pubsub. The pubsub-profile 
depends on core-pusub and key-groupcomm, which does not bother me too much.


FP: That is absolutely correct, the group communication drafts do not depend on 
the pubsub work, and can be move forward without dependencies.

Keeping this in mind, I have reviewed the key-groupcomm draft.

BTW, it might be helpful to include a similar overview in the oscoap-join draft.



Abstract
OLD:This document defines a message format for distributing keying
material in group communication scenarios (such as based on multicast
or publisher-subscriber model) using the ACE framework.

NEW:This document defines a message format for distributing keying
material to groups to protect the communication between group members using the 
ACE framework.


FP: we started with your input and reformulated to:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.

Introduction
OLD: Profiles that use group communication can build on this document to 
specify exactly which of the message parameters defined in this documents are 
used, and what are their values.

NEW: Profiles that use group communication can build on this document to 
specify a selection of the message parameters defined in this document and 
their values.


FP: we included this with the smallest difference:
   Profiles that use group communication can build on this document to
   specify the selection of the message parameters defined in this
   document to use and their values.


At the end of section 1:  [RFC8152], like Authorization Server (AS) and 
Resource Server (RS).
FP: Ok, added.


[cid:15330271085b602324913fd396336200@bbhmail.nl]
Figure 1 is not referenced in the text. I suggest a slightly different figure 
where dispatcher and KDC are endpoints of the RS, and for multicast the 
communication is directly between Client and group members without passing 
through the RS.


FP: We have now referenced the figure in the text. We have not modified the 
pictures, since we are not sure the change simplifies it. Reading the proposed 
figure, it seems like KDC and Dispatcher are logical entities in the same 
physical entity (the RS), which is not correct.
Key Distribution Center (KDC): Maintains the keying material to protect group 
communications, and provides keys to clients authorized to join the group. It 
corresponds to an endpoint of the RS in the ACE Framework.
FP: We have now rephrased based on your and Jims inputs:
o  Key Distribution Center (KDC): maintains the keying material to
  protect group communications, and provides it to Clients
  authorized to join the group.  During the first part of the
  exchange (Section 
3), 
it takes the role of the RS in the ACE
  Framework.
Also, it is worth noting that in this document we use the term “endpoint” as 
defined in ACE (equivalent to “resource” in CoAP), which is different from the 
“endpoint” term in CoRE/CoAP.

Dispatcher: this is the entity the Client wants to securely
communicate with and is responsible for distribution of group
messages. Example dispatchers are the Broker in a pub-sub setting or the 
generator of unicast messages to all group members for group communication.
Alternatively, Group communication is done by transmitting to a multicast IP 
address, and entrusting message delivery to the transport channels between 
Client and Group members.


FP: We don’t think “generator” is the best word, the true generator would still 

Re: [Ace] Comments on ace key groupcomm -01

[Francesca Palombini]

Hi Jim,

Thanks a lot for your detailed review, as you might have seen we have included 
most comments in the latest version: 
https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 
Please note that this version includes also review comments from Peter, which 
in some cases overlapped, so some text might be reformulated to include both 
inputs.

Inline, detailed comments and some questions.

Thanks,
Francesca

On 13/07/2018, 20:38, "Ace on behalf of Jim Schaad"  wrote:

* Section 2 - client  - write rights and/or read rights.  Unless you think
that write implies read in which case you should state that

FP: Right, we now specify: " It can request write and/or read rights."

* Section 2 - KDC - should also say what it does in the later parts -

FP: Ok, we added the following text: " During the second part (Section 4), 
which is not based
  on the ACE Framework, it distributes the keying material." We also added 
details about the role of the KDC for redistribution of keying material.

* Section 2 - Dispatcher - If this is a bus, then you are not really
communicating with it securely.  Anybody can write on it, but people will
just ignore what comes out the other end.

FP: Right, reformulated in " entity through which the Clients communicate with 
the
  group and which distributes messages to the group members."

* Section 3-  A brief description of all of the operations would be
appreciated.

FP: we have now added several sections to describe the operations. In section 2 
(starting with " This document specifies the message flows and formats for:") 
we describe the high level operations. At the beginning of each section (3. and 
4.) we also give an overview of the exchange described in the subsections.

* Section 3.1 - Can I get authorization for multiple items at a single time?

FP: In theory, it would be possible, and that would require to change the 
format of scope, going from [ group-id, [role1, role2] ] to [ [group-id1, 
group-id2], [[role1, role2], [role1]] ]. We haven't implemented this change, 
because it seems to cause a lot of overhead and complexity, for what seems to 
be a corner case. But if people think this is a valid use case, we can 
reconsider. We have added a placeholder comment in the md for this.

* Section 3.1 - Does it make sense to allow for multiple audiences to be on
a single KDC?  

FP: I am not sure I understand the scenario, could you expand on this? (We have 
added a comment in the md for this as well)

* Section 4.x  - cnf - text does not allow for key identifier

FP: Did you get the section wrong? In 4.x we do not use cnf. In which section 
exactly would you send the kid in the cnf? That should be defined in the Ace 
framework (and params)...

* Section X.X - Define a new cnf method to hold the OSCORE context
parameters - should it be a normal COSE_Key or something new just to makes
sure that it is different.

FP: This is the same comment as in the OSCORE Profile. Again, I am not sure why 
we really need a new structure since COSE_Key is general enough to transfer all 
the keying material, with the addition of the couple of new parameters defined. 
But if you think this is necessary, we can definitely change.

* Section 3.X - I am not sure if write or POST is a better answer for what
the role being requested is.

FP: Again, I don't understand this comment. We don't really define what one 
should use as role, write or POST are both possible.

* Section 4 - Should one talk about the ability to use OBSERVE as part of
key distribution?

FP: We added a comment as a placeholder for this in the md. Observe was just 
briefly mentioned before and not really elaborated. Although it would work, it 
seems not useful to have it together with a proper rekeying scheme where the 
KDC takes the initiative anyway.

* Section 4.x - I am having a hard time trying to figure out the difference
between a group and a topic.  The text does not always seem to distinguish
these well.

FP: It was our purpose to keep the text high level enough so that it would 
apply to both. Does that create any problem/confusion?

* Seciton 4.1 - POP on client key  esp if bound to an identity (Note using
it to access the KDC is one POP)

FP: Now added the following text at the end of section 4.: " Note that 
proof-of-possession to bind the access token to the Client   
   is performed by using the proof-of-possession key bound to the 
access
   token for establishing secure communication between the Client and   
   the KDC."

* Section 4.2 - why not use the exp field from OAUTH in the response

FP: the exp field from the AS in the response relates to the token. This exp 
relates to the keying material. Yes, when the token expires the keying material 
should expire (and that is specified e.g. in the OSCORE profile), 

Re: [Ace] WGLC for draft-ietf-ace-oscore-profile

[Francesca Palombini]

Hi Jim,

Thank you for your review comments. We agree with all your points, and have 
opened issues: https://github.com/ace-wg/ace-oscore-profile/issues to get this 
fixed.

Inline some detailed answer.

Thanks,
Francesca

On 22/10/2018, 21:09, "Jim Schaad"  wrote:

* Section 1 - I understand the reasoning behind having the server send back
a nonce, although it would be good to have a description someplace about why
this is being done.  (I would also make it optional as not all RS need to do
this.)  I do not understand the reasoning behind having the client send a
nonce to the server.

FP: The motivation for the nonce construction was in the security 
considerations, but I agree that having it in the Protocol Overview makes 
sense, so I opened an issue to fix that. The reason behind having the client 
create a nonce is that we are protecting against an attacker replaying an old 
RS message (containing an old nonce), which would provoke the creation of an 
old security context on the Client, and reuse of keys and nonces for a 
different (new) message.

* Section 3.1 - This is more general than the section, but you should not
use the URI path in the text, instead you should be using the name that is
in the authz document.

FP: Agreed, issue opened to fix this.

* Section 3.2 - Does it really make sense to use 'COSE_Key' to transport the
key data?  Would a different field name be better?

FP: This was brought up several times, so we will make this change now.

* Section 3.2 - Please provide a justification for the requirement that the
ids must be unique over the set of all clients and RS.   I can see that the
client ids need to be unique on a single RS and RS ids need to be unique for
any given client but not the broader statement.

FP: You are right, this requirement is too wide. We will replace with your 
suggestion.

* Please add an explicit section on when a RS and a client should discard
the security context.

FP: Ok we will add this. As mentioned in the issue, I have now only this 3 
cases in mind: Partial IV space ends (either C or RS); the kid context on the 
RS side does not match with N1 (RS); C receives a number of Unauthorized (C), 
although that is a consideration/recommendations, details would be application 
specific. Do you see any other case relevant for this section?

* Section 6 - Ok I'll bite  - how does not echoing the nonce allow for a
man-in-the-middle attack given that the salt and shared secret are still
going to be known only to the C and RS and not to the MITM.  I can see a DOS
attack being made, but that can be done even without this just by causing
the response to never be delivered.

FP: Ok so our mistake here is to use the term MitM, so to solve this we will 
replace with "on-path attacker". The following sentence should be correct with 
that fix "Moreover, the client echoes the nonce created by the RS, which 
verifies it before deriving the Security Context, and this protects against an 
adversary acting as an on path attacker and substituting the nonce in transit 
from client to RS to provoke the creation of different Security Contexts in the 
client and RS." Yes this is a DOS, but could also lead to reuse of keys and 
nonces, as mentioned before.

* Appendix - I am not sure that I think that the EDHOC profile should be in
this document as oppose to being in it's own document.  The fact that we
have not even tried to get this to work in any of the interop tests means
that I am less sure that it is well baked.

FP: Agreed, we will remove this from this document and move it to its own 
document

Jim


> -Original Message-
> From: Ace  On Behalf Of Jim Schaad
> Sent: Monday, October 8, 2018 2:35 PM
> To: ace@ietf.org
> Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile
> 
> The chairs believe that the set of documents dealing with the OAuth
> framework for constrained environments is nearing the point that we should
> be able to advance it to the IESG for publication.   We therefore want to
> have a full list of issues that need to be dealt with at the Bangkok
> meeting.
> 
> This starts a 2 week WGLC for draft-ietf-ace-oscore-profile
> 
> We know that the following issues are outstanding:
> 
> draft-ietf-ace-oscore-profile:
> *  No current known issues
> 
> 
> Jim & Roman
> 
> 
> ___
> 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-oscore-profile-06.txt

[Francesca Palombini]

Hi all,

As promised, here is the update with the changes decided at IETF104, and 
additional comments from Jim.
Please let us know if you have any remaining comment that we should address.

Thanks,
Francesca

On 03/01/2019, 11:36, "Ace on behalf of 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   : OSCORE profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-06.txt
Pages   : 26
Date: 2019-01-03

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security, server authentication,
   and proof-of-possession for a key owned by the client and bound to an
   OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-06
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-06


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

[Ace] OSCORE profile status

[Francesca Palombini]

Hi Roman, ACE,

Just a quick update on the OSCORE Profile, and some pointers.

The draft has been updated on the github according to the decisions taken at 
IETF103. A review of this update by Jim (thanks Jim!) has brought on additional 
(minor) changes. I am now making sure I have answered all of Jim's comments 
before submitting the next version.

You can follow the update and the discussion here: 
https://github.com/ace-wg/ace-oscore-profile/pull/11 

As well as the latest editorial version here: 
https://ace-wg.github.io/ace-oscore-profile/nonces-prop3/draft-ietf-ace-oscore-profile.html
 
And diff with current datatracker version: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-oscore-profile.txt=https://ace-wg.github.io/ace-oscore-profile/nonces-prop3/draft-ietf-ace-oscore-profile.txt
 

I will be going on vacation soon and won't probably have time to conclude the 
discussion and do an upload before then. I am planning to resume the work in 
early January.

Thanks,
Francesca

On 27/11/2018, 15:52, "Ace on behalf of Roman Danyliw"  wrote:

Hello WG!

It got captured in the meeting minutes [1], but for easy reference, the 
following is the draft update schedule we discussed at IETF 103:

** draft-ietf-ace-oauth-authz -- Second-half of December 2018
** draft-ietf-ace-dtls-authorize -- December 2018
** draft-ietf-ace-oscore-profile -- Early December 2018
** draft-ietf-ace-cwt-proof-of-possession -- Week of November 12, 2018
** draft-ietf-ace-coap-est -- Early December 2018

Regards,
Roman and Jim

[1] https://datatracker.ietf.org/meeting/103/materials/minutes-103-ace-00


___
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

[Ace] draft-ietf-ace-key-groupcomm and draft-ietf-ace-key-groupcomm-oscore status

[Francesca Palombini]

Hi,

Following the adoption of ace-key-groupcomm and ace-key-groupcomm-oscore, we 
have now made some updates, to be coherent with the updates to the OSCORE 
profile. You can see the latest version of the draft, together with the diff to 
latest submission, in the new github repositories:

https://github.com/ace-wg/ace-key-groupcomm 

https://github.com/ace-wg/ace-key-groupcomm-oscore 

As we don't foresee any major changes, we authors think this is a good time for 
the wg to read and review. Some of the points on our TODO list, on which we 
plan to improve on, are: 
- Error handling
- Message format for group leaving
- Format of 'client_cred' and 'group_policies' field

Any feedback is welcome!
Francesca

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

Re: [Ace] New Version Notification for draft-palombini-ace-coap-pubsub-profile-04.txt

[Francesca Palombini]

Hi all,

As I observed interest about security for pubsub in both Ace and CoRE during 
last meeting, I thought now would be a good time to submit a new version of the 
coap-pubsub profile of ACE.

This update aligns the document to the latest version of 
draft-ietf-ace-key-groupcomm and fixes minor editorials.

Feedback is welcome!

Thanks,
Francesca

On 03/04/2019, 15:29, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-palombini-ace-coap-pubsub-profile-04.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-palombini-ace-coap-pubsub-profile
Revision:   04
Title:  CoAP Pub-Sub Profile for Authentication and 
Authorization for Constrained Environments (ACE)
Document date:  2019-04-03
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-palombini-ace-coap-pubsub-profile-04.txt
Status: 
https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/
Htmlized:   
https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-profile-04
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-palombini-ace-coap-pubsub-profile
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-palombini-ace-coap-pubsub-profile-04

Abstract:
   This specification defines a profile for authentication and
   authorization for publishers and subscribers in a pub-sub setting
   scenario in a constrained environment, using the ACE framework.  This
   profile relies on transport layer or application layer security to
   authorize the publisher to the broker.  Moreover, it relies on
   application layer security for publisher-broker and subscriber-broker
   communication.


  


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

[Ace] Pub Sub and multicast

[Francesca Palombini]

Hi all,

TL;DR: Pub/sub and multicast hallway discussion happening at IETF104 (possibly 
during the hackathon?). Slides here:
https://github.com/EricssonResearch/coap-pubsub-profile/blob/master/Pubsub-multicast.pdf
  Contact me if interested.
As mentioned during the CoRE interim, I have started to think on how to 
progress the security for pub/sub work. For the people not following, there is 
currently one draft in Ace that describes a profile of Ace for authorization 
and key distribution + communication protection for CoAP pubsub [1]: 
https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-profile-03.

While looking at how to move forward that draft, some things came up: first of 
all, it would be nice to use multicast to broadcast notifications from broker 
to subscribers, for performance reasons. Secondly, the ace-coap-pubsub document 
miss a way to protect unaware nodes to get unwillingly subscribed by attackers 
spoofing their IP address. In fact, ace-coap-pubsub does protect the 
publication, but does not set up the “authorization for subscribers” mechanism, 
or any other DoS protection mechanism.

These two points might seem parallel and independent, but one influence the 
others: depending on how multicast notifications are set up, we might reuse 
existing mechanisms that might protect against unauthorized nodes being sent 
notifications from the broker.

I put up some ideas in slides and was hoping to get some discussion started 
during the hackathon (if possible):
https://github.com/EricssonResearch/coap-pubsub-profile/blob/master/Pubsub-multicast.pdf
 and/or in the mailing list. As you can see, I try to explain the problem and 
come up with possible solutions based on the existing drafts. These are of 
course just very high level draft solutions, and require more discussion.

Any feedback welcome!

Francesca

[1] https://tools.ietf.org/html/draft-ietf-core-coap-pubsub-08
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [core] Pub Sub and multicast

[Francesca Palombini]

Hi Carsten,

Yes, the phrasing is not good on that slide... If you notice, the "proposals" 
afterward point to a general "DoS protection mechanism". How that is done 
really depends on the tools available, for example the broker might only send 
notifications to subscribers that have been added to an OSCORE group, but echo 
is definitely another way of doing that.

Thanks,
Francesca

On 21/03/2019, 17:04, "Carsten Bormann"  wrote:

I’m certainly interested.

Not sure I understand “ • Additionally, the Subscriber must be 
authorized to subscribe, otherwise an attacker could DoS external nodes that do 
not want to receive the publications”.  Whether the attacker is authorized to 
subscribe and whether the actual notification receiver is interested is kind of 
orthogonal.

Generally, we’d need a way to prove address ownership for setting up 
observation interest.  The Echo option can be used for that…

Grüße, Carsten



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

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-07.txt

[Francesca Palombini]

Hi,

This update addresses the comments from the shepherd's review, plus a couple 
minor additional comments.

Thanks,
Francesca

On 19/02/2019, 13:44, "Ace on behalf of 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   : OSCORE profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-07.txt
Pages   : 26
Date: 2019-02-19

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security, server authentication,
   and proof-of-possession for a key owned by the client and bound to an
   OAuth 2.0 access token.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-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] Shepard comments on draft-ietf-ace-oscore-profile

[Francesca Palombini]

Hi Jim,

Inline.

Thanks,
Francesca

On 31/01/2019, 01:34, "Jim Schaad"  wrote:


1.  Please update the text for MUST/SHOULD/MAY to include the language from
RFC 8174.

FP: Right, thanks. Updated now in the github.

2.  Section 3.2.1 - What to do is clear if a field is not missing.  What is
the correct behavior if a field is present that the client and/or resource
server does not recognize.  Is this a fatal error or is it sufficient that
they may not behave the same?

FP: Assuming you are referring to fields missing in the 
OSCORE_Security_Context, (please correct me otherwise) this is a good point. We 
currently do not define what happens if the security context has unrecognized 
parameters. We don't foresee this happening, as the AS should know what the 
client and RS implement. However, to cover this case (bad implementation or 
something went wrong), to be on the safe side, we propose that there is a fatal 
error in that case. In fact, we don't know what additional parameters might be 
registered in the OSCORE_Security_Context, and although they could be 
"risk-free" (as in optional additional information non-necessary for the 
security context derivation), they could also be input to the key derivation 
for example, in which case the endpoint non-recognizing them would end up 
storing a "wrong" security context. What do you think?

Jim




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

Re: [Ace] Doodle poll for virtual interims

[Francesca Palombini]

Hi,

Please enter your availability by this Friday, April 19th: 
https://doodle.com/poll/ve7rnyareri2kqer

As Klaus said, the time slots are to chose for weekly meetings, so disregard 
the exact dates in the doodle poll, but only consider the day of the week.

The goal is to restart the meetings by the 2nd week of May, and we need a 
couple of weeks to set it up with the Secretariat.

Also note that the timeslots are 90 minutes long, to allow for longer interim 
time if needed.


Thanks,
Francesca


On 13 April 2019 at 16:47:02 CEST, Klaus Hartke  wrote:
We are looking for a new time slot for the CoRE/CBOR/COSE virtual
interims until IETF 105.

Proposed options:

7am PDT / 10am EDT / 4pm CEST / 11pm JST
8am PDT / 11am EDT / 5pm CEST / 12midn JST
9am PDT / 12noon EDT / 6pm CEST / 1am JST
10am PDT / 1pm EDT / 7pm CEST / 2am JST

The interims are scheduled to be weekly, alternating between CoRE and
CBOR/COSE (and a dash of ACE).

Please use this doodle poll to indicate your preference:
https://doodle.com/poll/ve7rnyareri2kqer

Klaus

___
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] draft-ietf-ace-key-groupcomm-oscore

[Francesca Palombini]

Hi Jim,
Thanks again for your in depth review. We have identified 7 clear APs from some 
of your review comments, and we hope that we answer the other (inline). Please 
let us know if that is ok, and we will update the document as soon as possible.

Thanks,
Francesca and Marco

I was wandering through the document with a view to implementing and have
the following questions:

1.  Abstract: From the first paragraph I am not sure if the group
communications or the communications to the KDC are secured with OSCORE.

[*] Ok, we propose to change “where communications are based” to “where the 
group communication is based”. The communication to the KDC is up to the 
profile of ACE used between the joining node and the KDC. (AP1)

2.  Section 3.1 - "requester" seems to be an odd name for "sender" or
"publisher"

[*] This particular document does not consider the concept of publisher. 
Requester was chosen to identify a client in a group communication setting, 
i.e. stressing that it sends (group) requests and receives (unicast) responses. 
Sender would not be correct, as both clients and servers are senders at some 
point during the message exchange.

3. Section 3.1 - I am trying to figure out why a Gid would be a reasonable
value for the scope.  This means that the AS is going to be the one to
assign the Gid value in many cases as it needs to check the scope value
there.  Is that going to be a common case?  I.e. Are Gids going to be
assigned by administrators?

[*] The Gid of the Authorization Request would be a reasonable scope because 
the join resource is associated to it (at the GM). The GM receiving a Join 
Request must be able to retrieve the correct Gid following the access to the 
join resource. No, the AS does not assign the Gid value (if that is used as 
scope in the Authorization Request). The AS only needs to check that the client 
is authorized to get an access token for that scope, regardless that it is a 
join resource. The Gid is assigned by the resource owner of the join resource 
at the GM, that is an administrator.

4. Section 3.1 - Is the form in Appendix C of the Gid in some respect
mandatory?  If it is not, then how does a receiver of a message distinguish
between two different groups that are using the same multicast address?  Is
that going to be a non-supported case?  The most common case of this would
be having two different groups on the default CoAP multicast address talking
to RDs with different permissions at the RD to see things.

[*] As of now, that is just an example, we might reconsider and make this at 
least mandatory to implement, so it would be good with more feedback on this. 
The requirements anyway are that in a GM all the Gids are unique, and that a 
Gid is changed after a group rekeying. The format in appendix C guarantees 
both. If your second question refers to one node in 2 groups (managed by 2 
different GMs), where these 2 Gids collide, then that is up to the application 
to decide how to deal with it (discard, try both contexts…). We briefly discuss 
sec cons about it in section 8.5 of core-oscore-groupcomm. However, that is 
independent from the format of the Gid, as long as the requirements are met.

5. Section 4.1 - I can understand things relative to the key_info blob that
is being returned.  I am not sure that I think that this is being defined
correctly however.  It makes more sense to me to have the following:
key_info = [ sign_alg: COSE_Algorithm, ?sign_parameters : map,
?key_parameters: map ] where the two maps are filled in from the required
fixed parameters from the two COSE registries.  This would end up with
something like the following as a potential value   [ sign_alg: ECDSA,
key_parameters: {'kty':'EC2', 'crv': 'P256'}]

[*] Ok, we can implement that. To make sure we understand your proposal, 
‘key_parameters’ are taken from COSE Key Common Parameters and COSE Key Type 
Parameters registries?
What about ‘sign_parameters’? Can we be sure that those two field would cover 
all parameters of existing and future algorithms? If a new algorithm defines 
its own registry, we would need to add that, and say values from that registry 
can also be used in this map. (AP2)

6. Section 4.1.1 - why is the key info parameter format application
specific?  I would have assumed that it was the same as in the previous
section.

[*] Right, proposal to change “Its format” to “Its exact content”. (AP3)

7.  Section 4.2 - for 'client_cred', I am unsure what the client is supposed
to do if the joining node does not know the countersignature algorithm.  Can
the include public key not be in a consistent format?  What does consistent
format even mean?

[*] Consistent format refers to the key type based on the countersignature 
algorithm used. If the joining node does not know the countersignature 
algorithm, it might just omit this parameter, or send a public key as a guess. 
If the guess is incorrect, the GM will reply as specified in 4.3 (see point 8).

8. Section 4.3 - I 

Re: [Ace] draft-ietf-ace-key-groupcomm-oscore

[Francesca Palombini]

Hi Jim,
We have now added your review comments to the github issues, and we’ll get to 
it. Below, the couple of comments that needed additional clarification (and 
consequent APs).
Thank you again for the thorough review!
Francesca and Marco
2.  Section 3.1 - "requester" seems to be an odd name for "sender" or
"publisher"
[*] This particular document does not consider the concept of publisher. 
Requester was chosen to identify a client in a group communication setting, 
i.e. stressing that it sends (group) requests and receives (unicast) responses. 
Sender would not be correct, as both clients and servers are senders at some 
point during the message exchange.
[JLS] I will probably complain again at a later date.  My problem is that 
requester is not the opposite of listener.  A different set might be 
“requester”, “responder”, “monitor”
[FP] Ok, thanks for the proposal. We will switch to these terms. (AP8)

3. Section 3.1 - I am trying to figure out why a Gid would be a reasonable
value for the scope.  This means that the AS is going to be the one to
assign the Gid value in many cases as it needs to check the scope value
there.  Is that going to be a common case?  I.e. Are Gids going to be
assigned by administrators?
[*] The Gid of the Authorization Request would be a reasonable scope because 
the join resource is associated to it (at the GM). The GM receiving a Join 
Request must be able to retrieve the correct Gid following the access to the 
join resource. No, the AS does not assign the Gid value (if that is used as 
scope in the Authorization Request). The AS only needs to check that the client 
is authorized to get an access token for that scope, regardless that it is a 
join resource. The Gid is assigned by the resource owner of the join resource 
at the GM, that is an administrator.
[JLS] Ok – so the answer to my question is yes.  I wanted to be sure it was not 
a registration process on the KDC (I think).
[FP] Right, it is not a registration process.

4. Section 3.1 - Is the form in Appendix C of the Gid in some respect
mandatory?  If it is not, then how does a receiver of a message distinguish
between two different groups that are using the same multicast address?  Is
that going to be a non-supported case?  The most common case of this would
be having two different groups on the default CoAP multicast address talking
to RDs with different permissions at the RD to see things.
[*] As of now, that is just an example, we might reconsider and make this at 
least mandatory to implement, so it would be good with more feedback on this. 
The requirements anyway are that in a GM all the Gids are unique, and that a 
Gid is changed after a group rekeying. The format in appendix C guarantees 
both. If your second question refers to one node in 2 groups (managed by 2 
different GMs), where these 2 Gids collide, then that is up to the application 
to decide how to deal with it (discard, try both contexts…). We briefly discuss 
sec cons about it in section 8.5 of core-oscore-groupcomm. However, that is 
independent from the format of the Gid, as long as the requirements are met.
[JLS] My question dealt with having two different KDCs each of which has a Gid 
and that Gid collides for some reason.  The groups of the two KDCs are distinct 
and the resources accessible by those different KDCs are distinct and are quite 
possibly two different applications.
[FP] Ok, that’s what we thought. So we will add sec cons that this is up to the 
application to decide (AP9)



7.  Section 4.2 - for 'client_cred', I am unsure what the client is supposed
to do if the joining node does not know the countersignature algorithm.  Can
the include public key not be in a consistent format?  What does consistent
format even mean?
[*] Consistent format refers to the key type based on the countersignature 
algorithm used. If the joining node does not know the countersignature 
algorithm, it might just omit this parameter, or send a public key as a guess. 
If the guess is incorrect, the GM will reply as specified in 4.3 (see point 8).
[JLS] I don’t know what point 8 is – There are 6 points for the outer list and 
the inner point 8 defines a field and does not define a response.
[FP] I meant point 8. of your review comments: the one just below this one.

8. Section 4.3 - I don't understand why the GM is accepting the join request
if the client_cred passed in was not in the correct format.  Is this a typo?
[*] The reason for responding with a non-error response code is to be able to 
use the payload to provide the key info in a CBOR map. With a 4.XX response, 
that would not be possible since the payload is supposed to be a diagnostic 
human readable text string. We are willing to change that if the WG/CoAP 
experts can confirm that would be ok.
[JLS] So I return a 2.01 in both cases, and based on the content the client 
needs to determine what is happening?   We are breaking the 4.xx response 
already in the OAuth framework by returning an 

Re: [Ace] draft-ietf-ace-key-groupcomm review

[Francesca Palombini]

Hi Jim,

Thanks for your prompt reply! I cut out the comments that were okayed, and only 
kept those that either are not okayed, need more discussion, or for which we 
have proposed new APs following your response. Approved APs are now tracked as 
github issues and we will be working on those in the branch v-02-WIP. New 
comments in red, prefaced with [FP].

Thank you again,
Francesca and Marco



Security Model and other issues for group messaging - 09/04/2019

I need to look at this more closely – will respond later

[FP] Ok. Thanks Jim for taking the time

I have been going through the design process for getting software running

for Montreal and I have come across the following issues that I think need

some discussion. Some of these may just need clarification in documents but

other are more substantive.

It took me a while to determine that one of the strange issues I was having

is that when looking just at the multicast case my mental model of who was

making the decisions on if access was allowed did not seem to make a good

match to what was being documented.

I rather expected that all of the ACL

decisions were going to be made on the AS and none on the KDC.

This is correct. The model for the ace-key-groupcomm (and consequently 
ace-key-groupcomm-oscore and ace-coap-pubsub) is that the AS does all of the 
ACL and KDC does the key distribution.

This meant

that the inclusion of scope in all of the messages was redundant if sending

messages to a per group resource.

You are correct, scope is indeed redundant in some messages, for example in the 
Key Distribution Request, as it is present in the token. (See point 12 below)

Part of the questions involved here are

who does the configuration for what key groups are associated with what

application groups.

I was always thinking of a single key group which was

identified by the AS and sent to the KDC without the KDC needing to know the

details of multiple resources for that key group. This of course does not

match the model in the document. Some text on what model is being laid out

is probably worthwhile.

We’d like clarifications here: why do you say that this does not match the 
current model? That was the objective anyway.

There was discussions for the ACE OAuth document about how to handle

multiple access tokens for a single entity that need to be looked at in the

context of a KDC. The current rule is that a resource server needs only to

keep one token for any single supplicant. This was mostly discussed in the

context of adding and subtracting privileges for the supplicant. It may be

that this also needs to be viewed in the context of having completely

disjoint resources on a single RS which are going to have different AS

tokens issued.

Thus for example, if there is a KDC which is servicing two

different key groups. The supplicant gets a token for group1, gets the keys

from the KDC. It then asks for a token for group2. Given that the

lifetimes of these different tokens could be radically different does it

really make sense to require that the two AS tokens be merged together

(assuming they are from the same source) or would it make more sense to

relax the RS only needs to keep one token rule. An easy way out of this

might be to say one token per resource, but for constrained devices it could

be one token per RS.

We agree with relaxing the “one token per RS per client”. The requirement makes 
sense when one RS is associated with one AS, but in our case the KDC could be 
associated with several AS for different scopes. 
draft-ietf-ace-oauth-authz-24#section-5.1

says "... the AS in charge of a resource hosted at the RS ..."  So this is a 
more general problem, as it is allowed in the ACE framework to have multiple 
ASs covering different resources/scopes at a same RS. We think this requirement 
should be relaxed in the general case, as merging tokens from different ASs 
would definitely be a problem. We’d like to raise this issue to the ACE 
framework authors and get feedback from the WG.

Jim



draft-ietf-ace-key-groupcomm - 03/04/2019 03:00

3.  The document does not have a table which deals with abbreviations, does

this mean that the full text string is what is going to be the key?

Depending on the content type being considered, these values could be

assigned (new registry) or marked as TBD, but if this is supposed to happen

then it needs to be placed in the document.

Yes, we need to do this. We will create a new registry for them, and re-use the 
same number as ACE as much as possible (for parameters that appear in both, 
such as ‘profile’, ‘exp’) (AP3)

[JLS] Sounds reasonable.  I am currently building a spreadsheet with some of 
this date and will forward it to you.
[FP] Got it, thank you for that, it will be very useful!



6.  Section 3.1 - Is there a reason why one cannot request access 

Re: [Ace] [Cbor] Doodle poll for virtual interims

[Francesca Palombini]

Hi all,

Thank you to those participating in the doodle poll, and thanks to lpwan WG for 
adjusting their interim time around our preferred time! The winning timeslot is 
the 15:00 – 16:30 UTC.

As a result, CBOR WG will have conference calls every other Wednesday starting 
May 22nd, 15:00 to 16:00 UTC : 
https://www.epochconverter.com/timezones?q=1558537200=Europe%2FBerlin

The Secretariat will announce the calls soon, but here is a summary:

Day: every other Wednesday beginning on May 22nd
Dates:  22 May; 5, 19 June; 3, 17, 31 July; 14, 28 Aug; 11, 25 Sept; 9, 23 Oct; 
6 Nov
Time: 15:00 to 16:00 UTC for all dates except 6 Nov; 6 Nov: 16:00 – 17:00 UTC

** Note that local time in NA will change for the 6 Nov meeting. Local time 
will not change in Europe. **

We will use the working group WebEx for the calls.  The IETF WebEx
account does not allow International dialling nor US toll free ("800"
numbers), but you can use the WebEx app to connect your device audio,
and there's also the option of connection directly from your browser
if your browser supports it.

WebEx details will be sent to the mailing list before each call (the
details will be the same for all calls, but the messages will serve as
reminders).


Thanks,
Francesca (as CBOR chair)

From: CBOR  on behalf of Francesca Palombini 

Date: Monday, 15 April 2019 at 17:44
To: Cose Wg , "c...@ietf.org WG" , 
"c...@ietf.org" , Ace Wg 
Subject: Re: [Cbor] [Ace] Doodle poll for virtual interims

Hi,

Please enter your availability by this Friday, April 19th: 
https://doodle.com/poll/ve7rnyareri2kqer

As Klaus said, the time slots are to chose for weekly meetings, so disregard 
the exact dates in the doodle poll, but only consider the day of the week.

The goal is to restart the meetings by the 2nd week of May, and we need a 
couple of weeks to set it up with the Secretariat.

Also note that the timeslots are 90 minutes long, to allow for longer interim 
time if needed.


Thanks,
Francesca

On 13 April 2019 at 16:47:02 CEST, Klaus Hartke  wrote:
We are looking for a new time slot for the CoRE/CBOR/COSE virtual
interims until IETF 105.

Proposed options:

7am PDT / 10am EDT / 4pm CEST / 11pm JST
8am PDT / 11am EDT / 5pm CEST / 12midn JST
9am PDT / 12noon EDT / 6pm CEST / 1am JST
10am PDT / 1pm EDT / 7pm CEST / 2am JST

The interims are scheduled to be weekly, alternating between CoRE and
CBOR/COSE (and a dash of ACE).

Please use this doodle poll to indicate your preference:
https://doodle.com/poll/ve7rnyareri2kqer

Klaus

___
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] Adoption call for draft-sengul-ace-mqtt-tls-profile

[Francesca Palombini]

+1

Francesca

On 23/04/2019, 08:38, "Ace on behalf of Ludwig Seitz"  wrote:

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



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

[Ace] FW: New Version Notification for draft-ietf-ace-oscore-profile-08.txt

[Francesca Palombini]

Hi all,

I just submitted v-08 of the OSCORE profile. This version answers the latest 
comments from Jim, plus a couple more issues that were left on the github issue 
tracker (issue #13 and following, at 
https://github.com/ace-wg/ace-oscore-profile/issues?utf8=%E2%9C%93=is%3Aissue 
)

Chairs: I would like to request 10 minutes at IETF105. I would be presenting, 
in person. 

Thanks,
Francesca

On 08/07/2019, 18:06, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-ietf-ace-oscore-profile-08.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-ietf-ace-oscore-profile
Revision:   08
Title:  OSCORE profile of the Authentication and Authorization 
for Constrained Environments Framework
Document date:  2019-07-08
Group:  ace
Pages:  27
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-oscore-profile-08.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-08
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-08

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security, server authentication,
   and proof-of-possession for a key owned by the client and bound to an
   OAuth 2.0 access token.


  


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

[Ace] FW: New Version Notification for draft-palombini-ace-coap-pubsub-profile-05.txt

[Francesca Palombini]

Hi all,

I just submitted a new version of the ACE profile of CoAP pubsub.

This version makes the updates necessary to comply with ace-key-groupcomm, as 
well as answer Marco's review (thank you Marco!) and some other minor changes. 
Any feedback is welcome!

Chairs: I'd like to ask for 5/10 minutes presentation time during IETF105. I 
would be presenting in person, not remote. Possibly, after ace-key-groupcomm, 
as this draft depends on that one.

Thanks,
Francesca

On 08/07/2019, 17:33, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-palombini-ace-coap-pubsub-profile-05.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-palombini-ace-coap-pubsub-profile
Revision:   05
Title:  CoAP Pub-Sub Profile for Authentication and 
Authorization for Constrained Environments (ACE)
Document date:  2019-07-08
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-palombini-ace-coap-pubsub-profile-05.txt
Status: 
https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/
Htmlized:   
https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-profile-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-palombini-ace-coap-pubsub-profile
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-palombini-ace-coap-pubsub-profile-05

Abstract:
   This specification defines a profile for authentication and
   authorization for publishers and subscribers in a pub-sub setting
   scenario in a constrained environment, using the ACE framework.  This
   profile relies on transport layer or application layer security to
   authorize the publisher to the broker.  Moreover, it relies on
   application layer security for publisher-broker and subscriber-broker
   communication.


  


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] Comments draft-palombini-ace-coap-pubsub-profile-04

[Francesca Palombini]

Hi Marco,

Thanks a lot for this review! I finally managed to include your comments and 
update the document, and will be posting a new version soon. You can see the PR 
to this update here in the meantime: 
https://github.com/EricssonResearch/coap-pubsub-profile/pull/2 
Answers inline.

Thanks,
Francesca

On 09/04/2019, 10:18, "Ace on behalf of Marco Tiloca"  wrote:

Hi,

Please, find below some comments on this profile. I hope it helps!

Best,
/Marco



[Abstract]

"This profile relies on transport layer or application layer security to
authorize the publisher to the broker" is due to the current profiles of
ACE, right? Otherwise, this can be (even) more general without
mentioning particular layers.

FP: That is correct, that is due to what profile of ACE is used. I haven't made 
a change here.

[Section 1]

Here the claimed scope is authorizing nodes, but it is actually also
about key provisioning (Section 3.1) and actual communication (Section 6.1).

FP: Right, I added some text about that.

[Section 2]

Here the claimed scope is protecting communication (in a broad sense),
while it can again mention also authorizing nodes (as per ACE) and key
provisioning (Section 3.1).

FP: Yes, added text about that as well.

I believe that the paragraph "There are four phases, ..." and the
numbered list would read better if placed right before the final
paragraph "Note that AS1 and AS2 ..."

FP: I tried to make this change but could not split the numbered list from the 
following paragraph, since it talks about this exchange in particular, so I 
ended up not implementing this one. We can discuss more about this.

[Section 3.1]

I think this will also need a way for clients to agree with the AS2 on
the correct format of their own public key (if they don't know already),
similarly to what suggested in ace-key-groupcomm-oscore. The only type
of approach that would not work is the one embedded with a Token POST,
since that does not happen with AS2.

FP: Right, I now specified the optional key format negociation in the document. 

The text says: "... the AS2 is both the AS and the KDC, ... so the
Authorization Response and the Post Token message are not necessary" .
Shouldn't we then have the Token POST to the KDC defined as optional
already in ace-key-groupcomm ? See for instance its Figure 2.

FP: No, we do not need to change that in Key groupcomm, as that would be more 
complicated to motivate.

In the Key Distribution Request, only one role can be indicated in
scope. What if a client wants to be both publisher and subscriber? This
seems allowed in Section 3.3 of core-coap-pubsub . Should a client
separately contact the AS2 multiple times?

FP: Fixed that.

In the Authorization Response, the 'profile' field can point at Section
8.1 where the profile value is defined.

FP: Ok, done.

In the Authorization Response, see above for the 'scope' field in case
of a client that wants two roles.

FP: Yes, same.

[Section 4]

Page 8, second bullet point, it can say "... protect the publication
end-to-end with the subscribers (see Section 6.1)".

FP: Ok, added

[Section 5]

Page 9, it can say "... keying material to verify the publication
protected end-to-end with the publishers".

FP: Ok, added


[Section 6]

It would be good to refer to core-coap-pubsub , and its usage of Observe
for subscriptions.

FP: Ok, added

The text says: "The (F) message is ... , which is unprotected." ,
although Section 3 admitted the possibility of communication secured
also between Broker and Subscribers.

FP: that's right, I added some text about that.

[Section 6.1]

In the unprotected headers of the COSE object, what is used as Partial IV?

FP: I added something about this, although this probably requires more thinking.

[Section 8.2]

The value of 'Profile' should be "coap_pubsub' , consistently with the
name of the profile registered in Section 8.1.

FP: Yes, this needed update.

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se




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

[Ace] FW: New Version Notification for draft-palombini-ace-coap-pubsub-profile-06.txt

[Francesca Palombini]

Hi,

I just submitted an update to the CoAP PubSub profile. This update reflects the 
update in the ace-key-groupcomm draft.

ACE Chairs: I'd like to request 10 minutes during IETF106, possibly after 
ace-key-groupcomm. I'd like for the chairs to ask for adoption in the wg, 
either now in the mailing list or during the f2f meeting. As I have mentioned, 
I feel like we are lacking work on CoAP PubSub security, and this is my 
proposal (still rough) to work on that. As CoAP PubSub is approaching maturity, 
we need to start working on securing it. This draft describes a profile of ACE 
for CoAP Pubsub, but also includes a mechanism based on COSE to protect the 
content of publications. 

CC CoRE because CoAP PubSub is is CoRE.

Thanks,
Francesca

On 04/11/2019, 16:45, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-palombini-ace-coap-pubsub-profile-06.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-palombini-ace-coap-pubsub-profile
Revision:   06
Title:  CoAP Pub-Sub Profile for Authentication and 
Authorization for Constrained Environments (ACE)
Document date:  2019-11-04
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-palombini-ace-coap-pubsub-profile-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/
Htmlized:   
https://tools.ietf.org/html/draft-palombini-ace-coap-pubsub-profile-06
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-palombini-ace-coap-pubsub-profile
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-palombini-ace-coap-pubsub-profile-06

Abstract:
   This specification defines an application profile for authentication
   and authorization for publishers and subscribers in a pub-sub setting
   scenario in a constrained environment, using the ACE framework.  This
   profile relies on transport layer or application layer security to
   authorize the publisher to the broker.  Moreover, it relies on
   application layer security for publisher-broker and subscriber-broker
   communication.


  


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] I-D Action: draft-ietf-ace-key-groupcomm-03.txt

[Francesca Palombini]

Hi all,

We updated the draft according to the very useful discussion to IETF 105 
("RESTification") and reviews from Daniel and Ludwig (thank you!). In the next 
couple of days we will get back to the individual review threads and answer 
those in detail, but we feel that everything was addressed with this new 
version.

Chairs: I'd like to request 10-15 minutes in Singapore to discuss how we solved 
previous open points and ways forward.

Thanks,
Francesca

On 04/11/2019, 16:14, "Ace on behalf of 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   : Key Provisioning for Group Communication using ACE
    Authors : Francesca Palombini
  Marco Tiloca
Filename: draft-ietf-ace-key-groupcomm-03.txt
Pages   : 41
Date: 2019-11-04

Abstract:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-03
https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-03


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] Review of draft-ietf-ace-key-groupcomm

[Francesca Palombini]

Hi,

Answering the one issue left from Ludwig's review, including Jim's reaction 
inline.

Thanks,
Francesca

On 23/07/2019, 14:56, "Ace on behalf of Jim Schaad"  wrote:

-Original Message-
From: Ace  On Behalf Of Ludwig Seitz
Sent: Friday, July 19, 2019 7:22 AM
To: draft-ietf-ace-key-groupc...@ietf.org
Cc: ace@ietf.org
Subject: [Ace] Review of draft-ietf-ace-key-groupcomm

Hello Francesca, Marco,

I have finally managed to read the whole of draft-ietf-ace-key-groupcomm 
and have a few comments for you:


==
5.2

"If the leaving node wants to be part of a group with fewer roles, it 
does not need to communicate that to the KDC, and can simply stop acting 
according to   such roles."

There are legitimate cases where a node might want to explicitly 
deactivate roles it is currently using (principle of least priviledge) 
and not just stop using them.

[JLS] I trimmed because I only wanted to address this one topic.  I totally 
agree that there are cases where a node might want to deactivate roles, however 
in the case of group communication I don't see how this could be done in a 
reasonable manner.  

FP: I agree with Jim that I am not sure this can be done "in a reasonable 
manner" (where reasonable means "worth the effort").

If a node says - please stop advertising my public key because I am no 
longer a publisher, that is reasonable for a KDC to start doing.  However, 
there are currently no provisions in the protocol for a KDC to advertise that 
fact to all of the subscribers.   Even if a key roll over were to occur, as the 
node still is part of the group, it can produce the correct key material and 
sign a message.  A subscriber with the signature key would successfully 
validate the signature and accept it the message, only those subscribers which 
had not yet pulled down a public key would fail to validate the message.

This would require a new mechanism for the purpose of asking if a public 
key is still associated with a specific key identifier (which is a good reason 
for the note about keeping the same key ids when rolling keys).  I am not sure 
that the traffic would be worth the effort for this small gain.

FP: The KDC keeps track of nodes being in the group now, and for each node it 
has an associated token with authorization information, so the KDC knows what 
roles each node has within the group. A possible new mechanism to solve this 
would be: we could add
*  an (observable) resource at the KDC that allows any member of the group to 
get information about nodes’ roles, say POSTing an array of node identifiers to 
the KDC and getting back the roles, or observing it and getting any changes it 
might happen, and 
* another resource where a node can POST updates to its own role
But I am not sure that is very useful/worth the effort vs the amount of traffic 
generated. The node requesting to “leave a role” could still request to “get 
the role” again, if it is still authorized to do so (for example, a publisher 
could decide to suddenly only be a subscriber, but could still get back its 
publisher role if it wanted to). I am interested in hearing more opinions about 
this (“no we don’t need this” “yes we need this and why”).


Note that for a gated transmission system such as a pub-sub server, the 
node can get lesser privilege for the gate system without getting less 
privilege for the KDC.

Jim



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

Re: [Ace] Review of draft-ietf-ace-key-groupcomm

[Francesca Palombini]

Hi Ludwig,

Thank you so much for your detailed review! We have addressed your comments in 
the -03 update submitted. It might be a bit hard to see from the diff, as we 
also made a restructuring based on comments at IETF105, but I answer to 
detailed comments inline.

Thanks again,
Francesca

On 19/07/2019, 13:21, "Ludwig Seitz"  wrote:

Hello Francesca, Marco,

I have finally managed to read the whole of draft-ietf-ace-key-groupcomm 
and have a few comments for you:


Figure 2: I suggest you move the "Defined in ..." to the left
they way it is now, it looks as if the Dispatcher was defined in the ACE 
framework.

FP: Ok, done.

==
"3.1.  MUST contain ... 'grant_type'"

This is no longer true. Grant_type was made optional in one of the 
latest updates of the ACE framework. When it is absent, 
grant_type=client_credentials is assumed as default.

FP: Ah, we had missed this, thanks for pointing that out! So fixed as you 
suggest.

==
3.3  "... and includes the following parameters: "

How is that supposed to work? The framework defines sending of the token 
to /authz-info as a CoAP POST, where the payload is the bytes of the 
token. In order to include additional parameters you would have to 
redefine this payload to be a CBOR map (as the OSCORE profile does).

FP: We do specify the content-format to be ace+cbor in that case, now we have 
clarified that the payload is a CBOR Map, containing token plus those 
parameters.

==
The whole section 3 talks about parameters send back and forth between 
the client and the KDC without defining how these are carried. It seems 
to be implied that there are CBOR maps in the payload, but that should 
be made explicit, especially where it differs from what the framework 
defines.

FP: Yes, we have now clarified that.

==
3.1  the text about the parameters in the client's post to the 
/authz-info endpoint at the KDC talks about parameters "sign_info" and 
"pub_key_enc" and claims they are specified in 3.3.1 and 3.3.2, but 
these sections specify the parameters for the "AS request creation 
hints" messages and not in this context. At least some clarification 
should be added.

FP: Ok, we have now added some text about that at the end of sections 3.3.1 and 
3.3.2.

==
Section 4

"If not previously established, the Client and the KDC MUST first
establish a pairwise secure communication channel using ACE."

This sentence is not strictly correct. Using what part of ACE? The ACE 
framework just says that you should establish a secure communication 
channel, it's the specific profiles that define how these channels are 
established. Please add some clarification.

FP: Note that this text is now moved to section 4.2. We have clarified by 
replacing with the 2 following sentences: 
"   If not previously established, the Client and the KDC MUST first
   establish a pairwise secure communication channel (REQ15).  This can
   be achieved, for instance, by using a transport profile of ACE."


==

"The Client and the KDC MAY use that same secure channel to protect 
further pairwise communications, that MUST be secured."

This is very questionable use of requirements language. How do I claim 
or test conformance with the second MUST?

FP: Right. We have rephrased. The MUST was not supposed to be normative

" The Client and
   the KDC MAY use that same secure channel to protect further pairwise
   communications that must be secured."

==
Section 4:
"The same set of message ..." should be "messages"

FP: Ok, this text actually disappeared with the restructuring.

==
"  Note that proof-of-possession to bind the access token to the Client
is performed by using the proof-of-possession key bound to the access
token for establishing secure communication between the Client and
the KDC."

This may or may not be true for a specific secure communication protocol
(e.g. think of DTLS with X.509 certificates without client 
authentication). You need to require this from the underlying secure 
communication protocol.

FP: Thanks for pointing this out. We replaced the previous text with the 
following:
"   The secure communication protocol is REQUIRED to establish the secure
   channel by using the proof-of-possession key bound to the access
   token.  As a result, the proof-of-possession to bind the access token
   to the Client is performed by using the proof-of-possession key bound
   to the access token for establishing secure communication between the
   Client and the KDC."

==
4.1 "The endpoint in the KDC is associated to the 'scope' value of the 
Authorization Request/Response."

Associated how? This is too unspecific to lead to interoperable 
implementations. I 

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

[Francesca Palombini]

Hi Daniel,

You missed my request to present ace-key-groupcomm and coap-pubsub-profile. I’d 
need 15 minutes for the first and 10 for the second.

Thanks,
Francesca

From: Ace  on behalf of Daniel Migault 

Date: Tuesday, 5 November 2019 at 22:03
To: Cigdem Sengul 
Cc: Ace Wg , Daniel Migault 

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

Thanks for the feed back, please find the current agneda below:

https://datatracker.ietf.org/doc/agenda-106-ace/

Yours,
Daniel

On Tue, Nov 5, 2019 at 6:38 AM Cigdem Sengul 
mailto:cigdem.sen...@gmail.com>> wrote:
Hello Jim and Daniel,

I would like 10 minutes in the agenda to present the updates we made to the:
 https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/

I will be presenting remotely.

Thanks,
--Cigdem

On Thu, Oct 31, 2019 at 6:27 PM Daniel Migault 
mailto:40ericsson@dmarc.ietf.org>>
 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

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

Re: [Ace] ace-key-groupcomm-oscore-03

[Francesca Palombini]

Hi Peter!

Thanks for your comment. We will definitely go back to try to shorten and 
remove duplicate text even more, I agree with you that we could do better there.

I might come back with questions on more precise advice once we give it another 
try.
Thanks!
Francesca

From: Ace  on behalf of Peter van der Stok 

Organisation: vanderstok consultancy
Reply to: "consulta...@vanderstok.org" 
Date: Tuesday, 19 November 2019 at 17:12
To: Ace Wg 
Subject: [Ace] ace-key-groupcomm-oscore-03

Hi Authors,

Having read the document and comparing it with ace-key-groupcomm, I have to 
agree with Jim that this document repeats in "other" words the same subjects as 
specified in ace-key-groupcomm.
In this form, it is very difficult to find out the differences between the two 
documents.

It would be good if the same terminology was used or their equivalence was 
pointed out:
eg: Client vs joining node
Group-manager versus KDC
joining request versus joining authorization

Secondly, I suggest to make this draft much shorter, and mostly refer to the 
sections of ace-key-groupcomm and point out the differences. In many cases a 
list of items that MUST be present, are optional or not present at all will 
suffice.
For example such an enumeration is done under the bullet key on page 15.

New parameters can receive more text as is done for cs_alg, cs_params, 
cs_key_params, and cs_key_enc.

Hope this helps,
Thanks for all your work,
greetings,

Peter
--
Peter van der Stok
vanderstok consultancy
mailto: consulta...@vanderstok.org, 
stokc...@bbhmail.nl
www: 
www.vanderstok.org
tel NL: +31(0)492474673 F: +33(0)966015248
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile

[Francesca Palombini]

Hi,

This adoption call has ended a while ago, I am waiting for a conclusion before 
submitting the next version of the document, also in view of next interim.

Hope you have a happy new year celebration,
Francesca

From: Ace  on behalf of Daniel Migault 

Date: Tuesday, 19 November 2019 at 09:45
To: Ace Wg 
Subject: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile

Dear working group,

As mentioned during the ACE meeting, this mail starts a call for adoption for 
draft-palombini-ace-coap-pubsub-profile. Please provide your feed backs by 
December 4.


https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/


Yours,
Daniel


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

Re: [Ace] Jim's Proposal on legal requestor

[Francesca Palombini]

Jim now I see, thanks for explaining.

Yes, we do need to send roles with the public keys, that makes sense. It also 
makes sense to have this formatted with 2 arrays as Marco suggests. I’d also 
make use of CBOR sequences:

<<(  [ key1, key2, key3] , [role1, role2, [role1, role2] ] ) >> where ( , ) 
denotes CBOR sequence and << >> bstr wrapping. Key1 has role1, key 3 has roles 
1 and 2.

I believe ace-key-groupcomm should define the above formatting (in 4.1.2.1. 
parameter pub_keys, possibly renaming it if you think it’s necessary). 
Ace-key-groupcomm does not need to discuss roles formatting, as that is left to 
application profiles.
Ace-key-groupcomm-oscore should define roles formatting and possibly give 
shortened values to use for those defined. Also I do not believe they should be 
registered in IANA as you Marco seem to imply.

Thanks,
Francesca

From: Ace  on behalf of Marco Tiloca 
Date: Thursday, 27 February 2020 at 13:52
To: Jim Schaad , Ace Wg 
Subject: Re: [Ace] Jim's Proposal on legal requestor

Hi Jim,
On 2020-02-26 18:59, Jim Schaad wrote:


From: Ace  On Behalf Of 
Marco Tiloca
Sent: Wednesday, February 26, 2020 6:08 AM
To: Michael Richardson ; 
Jim Schaad ; 
ace@ietf.org
Subject: Re: [Ace] Jim's Proposal on legal requestor

Hi!

Jim, I think now I understand your idea and it makes sense to me.

Some comments in line below.

Best,
/Marco
On 2020-02-26 14:17, Michael Richardson wrote:



clarifying question.



Jim Schaad  wrote:

> I do not seem to have been doing a good job of explaining the issue

> that I am raising here, so I am going to go scenario based for a

> description.



> (1) I get an access token from an AS with a scope of [

> "coap://multicast-01", ["responder"]]

> (2) I join the group associated

> with that address

> (3) I then decide to send the message below out

> encrypted with the group symmetric key and signed with the public key I

> registered during the join



>GET coap://multicast-01/resource1



 (I numbered the steps)

I believe that (1) was intended to allow you to become a responder for this 
resource.

==>MT
Step (1) is intended to allow access to the group-membership resource at the 
Group Manager (GM), to get the keying material for communicating in the group.

Practically, the roles are currently used only at the GM to determine which 
public keys is relevant to return to a node upon its joining.
<==
[JLS] When implies that the only roles of interest are “monitor” vs not 
“monitor”.









> It then processes the get request

> because it does not know that this is a violation of the scope assigned

> to me by the AS.



!

==>MT
As above, the original idea for that scope was to have it applied to the group 
joining itself and the resource at the GM to access for joining.

But I agree that we should inform the other group members of that role, i.e. 
"allowed to send requests" and/or "allowed to send responses".
<==








> The only way that I know for the server TimeX to enforce the allowable

> operations is for that information to be propagated along with the

> signature public key from the KDC to the server.

==>MT
This can be one more parameter in the Joining Response or in the Public Key 
Response, when request public keys of group members are included.

Together with the array of public keys, we can have a same-ordered array of 
roles echoing the roles from the scope of the Access Token above. Each element 
of the array can possibly be an array of roles.

How does it sound?
<==
[JLS] Yes this makes sense.  The only potential issue is what happens if the 
set of roles becomes in some sense unbounded for an application.  However, in 
that case I would expect that the list of roles would be known to the joining 
clients.  The one thing that comes up here is should there be a compression of 
these values since we are sending them to a larger group of people.

==>MT
Yes, I think so. One integer per role should work, registered by the profile or 
application defining that role.

Other that the wider distribution you mention above, compression is good anyway 
considering the recently discussion on 'scope' covering multiple groups, each 
with its role(s) indicated.
<==

Best,
/Marco





One can create a

> similar scenario on the other side where a client sends a response when

> it is only authorized as a "requester".

==>MT
Right, if it's "requester"-only.
<==






It seems to me that if the access control to the group is a group-shared

symmetric key + asymmetric signature, that each responder requires the list of 
valid signers.

Or, we need LAKE to turn the group key into 1:1.

==>MT
What I understand from Jim's proposal is essentially enabling at each group 
member a list of valid request signers and valid response 

Re: [Ace] [EXTERNAL] RE: Access token question

[Francesca Palombini]

Thanks all! Section 8.13 of the framework is exactly what I was looking for, I 
don’t know how I did not see it. A bit surprised there is no text referencing 
it in the framework itself.

Also, about the “scope” claim registration: the claim description and the 
specification document give 2 different pointers. The claim description ref 
points to the description for JWT (JSON string etc), I think this should be 
adapted to using CBOR (writing a section in the ACE framework, which could then 
reference both pointers). Also minor, I would add the precise section of 6749 
we should look at, which I assume is 3.3.

Francesca

From: Mike Jones 
Date: Friday, 21 February 2020 at 19:45
To: Jim Schaad , Francesca Palombini 
, 'Seitz Ludwig' 
Cc: Ace Wg 
Subject: RE: [EXTERNAL] RE: Access token question

And https://tools.ietf.org/html/rfc8693#section-7.4, which registers “scope” at 
https://www.iana.org/assignments/jwt/jwt.xhtml.

-- Mike

From: Jim Schaad 
Sent: Friday, February 21, 2020 9:15 AM
To: 'Francesca Palombini' ; 'Seitz Ludwig' 
; Mike Jones 
Cc: 'Ace Wg' 
Subject: [EXTERNAL] RE: Access token question

You are missing something

https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-8.13<https://protect2.fireeye.com/v1/url?k=72002d7d-2ed426d6-72006de6-864b0d136b87-400f082a818228df=1=a5d76c10-357e-4834-9e8c-56996a757268=https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-ietf-ace-oauth-authz-33%2523section-8.13%26data%3D02%257C01%257CMichael.Jones%2540microsoft.com%257C41e26bbcdb7c4f902d7908d7b6f1a860%257C72f988bf86f141af91ab2d7cd011db47%257C1%257C0%257C637179021340478864%26sdata%3DbMozqI2BYqMAAViWLIIKzJBvQFa30eqKVHtqUiC3bH8%253D%26reserved%3D0>

defined here

From: Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>
Sent: Friday, February 21, 2020 4:37 AM
To: Seitz Ludwig mailto:ludwig.se...@combitech.se>>; 
Mike Jones mailto:michael.jo...@microsoft.com>>; 
Jim Schaad mailto:i...@augustcellars.com>>
Cc: Ace Wg mailto:ace@ietf.org>>
Subject: Access token question

Hi,

Quick question regarding access token and scope.
I know that “scope” semantics is left to the application to define, but in 
general I would expect to include there some information about resource and 
method/operations allowed on that resource. Please correct me if any of this is 
not exact.

It was my understanding that “scope” (or more precisely the “scope” value) 
defined for the Client-AS request and response should be included in the access 
token as well. Checking in CWT, there is no such “scope” claim defined. “aud” 
claim is indeed defined for the CWT, but that should correspond to “aud” 
parameter in the ACE request/response. So where do I put the exact resource and 
operations in the access token?

What am I missing?

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

Re: [Ace] AD review of draft-ietf-ace-oscore-profile-08

[Francesca Palombini]

Hi Ben,

No worries, I took enough time answering your review, on the contrary thank you 
for making it before the interim!
I saw you already reviewed the PR, otherwise you can see the diff with the 
latest submission more easily here: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-oscore-profile.txt=https://ace-wg.github.io/ace-oscore-profile/v-09/draft-ietf-ace-oscore-profile.txt
 
I have replied to your latest PR comments, waiting for final OK for merging it. 
Also answering inline to your open comments below, prefaced with [FP], I think 
we agree on all now.


 Thanks a lot!
Francesca


On 25/02/2020, 06:34, "Benjamin Kaduk"  wrote:

Hi Francesca,

Sorry to cut this so close to the wire...I was on vacation and came back to
a sizeable inbox.

On Mon, Feb 17, 2020 at 03:55:29PM +, Francesca Palombini wrote:
> Hi Ben,
> 
> I am now done with updating the draft following most of your review 
comments. Out of the 105, I have implemented 88 in the draft, while those left 
need agreement in the wg as previously mentioned, or require your OK (see 
inline).
> 
> You can see the result of the update in the PR here: 
https://github.com/ace-wg/ace-oscore-profile/pull/25 If you give me the 
go-ahead, I will merge this PR and submit a new version, and then we can 
continue working on the open issues.

I will have to download the changes locally to view them, as the in-browser
viewer does not do well with the long lines.

[FP] Sorry about that, should have split the lines better.

> These open issues are:
> 
> * The mechanism of letting the RS pick the identifier of the client is 
not worth the additional complexity.
>   6, 7, 32, 61, 65,
> * Recommendation about length of nonces N1 and N2 to use.
>   5, 52
> * Define and register 2 new ACE parameters to transport the nonces used 
in the exchange, instead of using "cnonce".
>   3,  53, 60
> * Check with IANA
>   102
> 
> I hope to discuss these in the mailing list (continuing on the separate 
thread), and at the interim. 
> 
> I will cut and paste the rest (46 , 47,  58 , 67 , 92 + a couple of more) 
which I have answered below, whatever is not reported below I found no issue in 
doing the modifications you suggested, or is covered by the open points I 
mentioned. Please do bring any of those I do not touch on up again if you feel 
they were not solved in the PR.
> 
> Thanks again for your extensive review!
> Francesca
> 
> On 03/02/2020, 05:06, "Benjamin Kaduk"  wrote:
> > 29.   The AS MUST also assign an identifier to the RS 
(serverId), MAY
> >assign an identifier to the client (clientId), and MAY 
assign an
> >identifier to the context (contextId).  These identifiers 
are then
> >used as Sender ID, Recipient ID and ID Context in the OSCORE 
context
> >as described in section 3.1 of 
[I-D.ietf-core-object-security].  The
> >couple (client identifier, context identifier) MUST be 
unique in the
> >set of all clients on a single RS.  Moreover, when assigned,
> >serverId, clientId and contextId MUST be included in the
> >OSCORE_Security_Context, as defined in Section 3.2.1.
> > 
> > When certain fields are optional, we typically have to ask 
whether it's
> > possible for the two parties to disagree about whether the 
field is
> > present.  IIUC, the OSCORE context derivation procedure 
includes enough
> > information to prevent that possibility, but it would be good 
if someone
> > would confirm that.
> > 
> > FP: That is correct, a number of fields have default values when 
non present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId 
and serverId need to be set.
> 
> Hmm, so there is not a great mechanism to distinguish "absent" from
> "present with default value", but the practical consequences of such 
an
> attack seem quite limited.
> 
> FP: That is right. I did not add any text about this, as this is more 
OSCORE implication.

That's okay.

> > 
> > 34. "access_token" : h'a5037674656d7053656e73 ...'
> >   (remainder of access token omitted for brevity)',
> > 
> > In addition to the invalid-CBOR-diagnostic-notation-syntax 
comment, we
> > also have unbalanced quotes.
> > 
> > FP: Right, but this is no

Re: [Ace] Webex meeting invitation: ACE interim meeting

[Francesca Palombini]

Hi,

Re: status update ace-key-groupcomm:

The document has been updated to v-04 in preparation for next week interim. The 
update covers almost all review comments received, including what discussed at 
IETF106.

From: Ace  on behalf of Daniel Migault 

Date: Friday, 24 January 2020 at 13:38
To: "ace-cha...@ietf.org" 
Cc: Ace Wg 
Subject: Re: [Ace] Webex meeting invitation: ACE interim meeting

Hi,
This is a reminder of the interim meeting next week. By the interim meeting, we 
would especially appreciate your feed backs on the following documents.

* ace-mqtt-profile
* ace-key-groupcomm
* ace-key-groupcomm-oscore

I would also ask the authors to respond to this email with a (short) status 
update for each WG documents. Especially mentioning how far each document is - 
in their opinion - from a WGLC.

Yours,
ACE chairs

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
[2] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
[3] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/


On Thu, Jan 2, 2020 at 11:24 PM ACE Working Group 
mailto:messen...@webex.com>> wrote:

ACE Working Group invites you to join this Webex meeting.



Meeting number (access code): 641 066 992

Meeting password: akZaYmff



Friday, January 31, 2020
11:00 am  |  (UTC-05:00) Eastern Time (US & Canada)  |  1 hr 30 mins



Join 
meeting



Join by phone
Tap to call in from a mobile device (attendees only)
1-650-479-3208 Call-in toll 
number (US/Canada)



Join from a video system or application
Dial 641066...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.



Join using Microsoft Lync or Microsoft Skype for Business
Dial 641066992.i...@lync.webex.com

Need help? Go to http://help.webex.com

___
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] AD review of draft-ietf-ace-oscore-profile-08

[Francesca Palombini]

Hi Ben,

I am now done with updating the draft following most of your review comments. 
Out of the 105, I have implemented 88 in the draft, while those left need 
agreement in the wg as previously mentioned, or require your OK (see inline).

You can see the result of the update in the PR here: 
https://github.com/ace-wg/ace-oscore-profile/pull/25  If you give me the 
go-ahead, I will merge this PR and submit a new version, and then we can 
continue working on the open issues.

These open issues are:

* The mechanism of letting the RS pick the identifier of the client is not 
worth the additional complexity.
6, 7, 32, 61, 65,
* Recommendation about length of nonces N1 and N2 to use.
5, 52
* Define and register 2 new ACE parameters to transport the nonces used in the 
exchange, instead of using "cnonce".
3,  53, 60
* Check with IANA
102

I hope to discuss these in the mailing list (continuing on the separate 
thread), and at the interim. 

I will cut and paste the rest (46 , 47,  58 , 67 , 92 + a couple of more) which 
I have answered below, whatever is not reported below I found no issue in doing 
the modifications you suggested, or is covered by the open points I mentioned. 
Please do bring any of those I do not touch on up again if you feel they were 
not solved in the PR.

Thanks again for your extensive review!
Francesca

On 03/02/2020, 05:06, "Benjamin Kaduk"  wrote:
> 29.   The AS MUST also assign an identifier to the RS (serverId), MAY
>assign an identifier to the client (clientId), and MAY assign an
>identifier to the context (contextId).  These identifiers are then
>used as Sender ID, Recipient ID and ID Context in the OSCORE 
context
>as described in section 3.1 of [I-D.ietf-core-object-security].  
The
>couple (client identifier, context identifier) MUST be unique in 
the
>set of all clients on a single RS.  Moreover, when assigned,
>serverId, clientId and contextId MUST be included in the
>OSCORE_Security_Context, as defined in Section 3.2.1.
> 
> When certain fields are optional, we typically have to ask whether 
it's
> possible for the two parties to disagree about whether the field is
> present.  IIUC, the OSCORE context derivation procedure includes 
enough
> information to prevent that possibility, but it would be good if 
someone
> would confirm that.
> 
> FP: That is correct, a number of fields have default values when non 
present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and 
serverId need to be set.

Hmm, so there is not a great mechanism to distinguish "absent" from
"present with default value", but the practical consequences of such an
attack seem quite limited.

FP: That is right. I did not add any text about this, as this is more OSCORE 
implication.

> 
> 34. "access_token" : h'a5037674656d7053656e73 ...'
>   (remainder of access token omitted for brevity)',
> 
> In addition to the invalid-CBOR-diagnostic-notation-syntax comment, we
> also have unbalanced quotes.
> 
> FP: Right, but this is not valid CBOR diagnostic notation syntax anyway, 
do you have a better idea? I do not think it would be useful to have the full 
token here. Will remove the unbalanced quote.

This is probably manageable, though we do often see people put a disclaimer
before the example that  are truncated for readability;
some other ADs may have other suggestions, too.

FP: Thanks for the input text :) Now added.

...

> 43.   hkdf:  This parameter identifies the OSCORE HKDF Algorithm.  
For more
>   information about this field, see section 3.1 of
>   [I-D.ietf-core-object-security].  The values used MUST be
>   registered in the IANA "COSE Algorithms" registry and MUST be
>   HMAC-based HKDF algorithms.  The value can either be the integer
> 
> It's a little unfortunate that we basically are relying on "I know it
> when I see it" for determining which algorithms are HKDF algorithms.
> 
> FP: Agreed, but we don’t really have another way to say this. If you or 
COSE experts (Jim) have any idea please let us know.

I think we inherited this from JOSE :-/

FP: That would make sense. I have not done any modifications here, still 
waiting for more input if any.

> Also, "HKDF" expands to "HMAC-based Extract-and-Expand Key Derivation
> Function", i.e., is definitionally HMAC-based.  So this should be
> reworded to reflect the actual intent.
> 
> FP: Right, that is because COSE also defines HKDF using AES-MAC, see 
Table 12 of RFC8152, so we needed to specify that only HMAC-based can be used.

Oof, rather unfortunate IMO that the terminology was 

Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile

[Francesca Palombini]

Hi,

Thanks, done just now. Please note that:


  *   I picked the name “draft-ietf-ace-pubsub-profile” and dropping “coap”, 
following the discussion and in view of the updates planned, where MQTT will be 
considered as well. Name can of course be reconsidered if anybody has a better 
idea.
  *   The draft itself has not been updated with the planned changes. I will 
get back to it as soon as I am back from vacation.

Happy new year!
Francesca

--


A new version of I-D, draft-ietf-ace-pubsub-profile-00.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-ietf-ace-pubsub-profile
Revision:  00
Title:  Pub-Sub Profile for Authentication and 
Authorization for Constrained Environments (ACE)
Document date:2020-01-04
Group:  ace
Pages:   19
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-pubsub-profile-00.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/
Htmlized:   https://tools.ietf.org/html/draft-ietf-ace-pubsub-profile-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile


Abstract:
   This specification defines an application profile for authentication
   and authorization for publishers and subscribers in a pub-sub setting
   scenario in a constrained environment, using the ACE framework.  This
   profile relies on transport layer or application layer security to
   authorize the publisher to the broker.  Moreover, it relies on
   application layer security for publisher-broker and subscriber-broker
   communication.




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

The IETF Secretariat


From: Daniel Migault 
Date: Monday, 23 December 2019 at 03:29
To: Francesca Palombini 
Cc: Daniel Migault , Ace Wg 
Subject: Re: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile

Hi,

You are correct, the call has expired. Please upload the document as a WG 
document!

Yours,
Daniel

On Sat, Dec 21, 2019 at 10:28 AM Francesca Palombini 
mailto:40ericsson@dmarc..ietf.org>>
 wrote:
Hi,

This adoption call has ended a while ago, I am waiting for a conclusion before 
submitting the next version of the document, also in view of next interim.

Hope you have a happy new year celebration,
Francesca

From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Daniel Migault 
mailto:40ericsson@dmarc.ietf.org>>
Date: Tuesday, 19 November 2019 at 09:45
To: Ace Wg mailto:ace@ietf.org>>
Subject: [Ace] Call for adoption draft-palombini-ace-coap-pubsub-profile

Dear working group,

As mentioned during the ACE meeting, this mail starts a call for adoption for 
draft-palombini-ace-coap-pubsub-profile. Please provide your feed backs by 
December 4.

https://datatracker.ietf.org/doc/draft-palombini-ace-coap-pubsub-profile/

Yours,
Daniel

___
Ace mailing list
Ace@ietf.org<mailto: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-oscore-profile-10.txt

[Francesca Palombini]

Hi Ben, ace,

These 2 updates (09 and 10) address almost all the AD review comments of v-08.

V-09 covers the majority of them, as we discussed in this thread: 
https://mailarchive.ietf.org/arch/msg/ace/rgVfs3dzcWQnNlXn331DdpQfwwQ/ and 
listed in this issue: https://github.com/ace-wg/ace-oscore-profile/issues/26 

v-10 covers the remaining: 

* The mechanism of letting the RS pick the identifier of the client is not 
worth the additional complexity.
6, 7, 32, 61, 65,
* Define and register 2 new ACE parameters to transport the nonces used in the 
exchange, instead of using "cnonce".
3,  53, 60

The following issue is still open (during the interim meeting Jim volunteered 
to give a try to draft some text, and we really appreciate his help) and we 
should pinpoint what we need to include in the document about: 

* Recommendation about length of nonces N1 and N2 to use.
5, 52


Thanks,
Francesca


On 09/03/2020, 17:44, "Ace on behalf of 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   : OSCORE profile of the Authentication and 
Authorization for Constrained Environments Framework
    Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-10.txt
Pages   : 30
Date: 2020-03-09

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security, server authentication,
   and proof-of-possession for a key owned by the client and bound to an
   OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-10
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-10


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] Update of access rights

[Francesca Palombini]

Hi Michael,

On 05/05/2020, 18:01, "Ace on behalf of Michael Richardson" 
 wrote:


    Francesca Palombini  
wrote:
> 7. Client wants to update its access rights: retrieves T2 from AS. 
Note
> that this T2 has different authorization info, but does not contain
> input keying material ("osc"), only a reference to identify Sec1 
("kid"

Is there an assumption that the access rights(T2) >= access rights(T1)?

FP: No. But at the same time if access rights(T2) is a subset of access 
rights(T1), then there is no point in the client requesting T2 from the AS... 
These could be a disjoint sets of access rights.

> Moreover, while comparing with DTLS profile, we realized there is no
> reason for which 8. should be sent unprotected. In fact, doing so 
opens
> up to possible attacks where an old update (token non expired) is
> re-injected to the RS by an adversary:

I agree and I see your point.
Thank you for explaining it so well.

FP: Thank you! I tried to be as clear as possible :)

My question is whether step 8 results in Sec Ctx sec1 being deleted?
Could Client want to keep it alive in the case that T1 and T2 actually do
different things?

FP: As currently defined in the document, yes, Sec1 ends up being deleted as 
soon as Sec2 is validated (i.e. a request is correctly decrypted by the 
receiving endpoint using Sec2). If T1 and T2 do different things and the client 
wants to (and is allowed to - T1 is not expired or revoked for some reason) 
keep T1 alive, then we are not in the case of "update of access rights", i.e. 
the case where T2 replaces T1. My "Final point" was to cover exactly the case 
you mention, where T1 and T2 are used to derive 2 different security contexts, 
where the RS does not realize they come from the same Client. It is up to the 
AS to make sure that T1 and T2 are disjoints: why would the AS even send 2 
different tokens that cover part of or the entire same scope at the same RS to 
the same client? By the way, if it is not already in there, I think that that 
is another excellent consideration point for the Ace framework.

Thanks,
Francesca

-- 
]   Never tell me the odds! | ipv6 mesh 
networks [
]   Michael Richardson, Sandelman Software Works|IoT architect  
 [
] m...@sandelman.ca [


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

[Ace] Update of access rights

[Francesca Palombini]

Hi Ace chairs, DTLS authors, Ace framework authors, Ben,

TL;DR: we propose some changes on the OSCORE profile for the "update of access 
rights" scenario. We have comments for the DTLS profile and the ACE framework 
regarding this scenario, and we ask for feedback from ACE OSCORE implementers 
and Ace in general.

In an attempt to answer Jim's 
(https://github.com/ace-wg/ace-oscore-profile/issues/20) and Ben's 
(https://github.com/ace-wg/ace-oscore-profile/pull/30) review of the OSCORE 
profile, we have been thinking more about the case of updating access rights. 
This has revealed to us authors that something is missing from the document, 
and I believe that this part is not explicitly covered in the DTLS profile 
either, hence this email. 

This is the scenario, and what is currently defined in the OSCORE profile:

1. Client retrieves access token T1 from AS
2. Client posts T1 to RS, together with nonce N1
3. RS replies with 2.01 and nonce N2
4. Client and RS derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2
5. Client uses Sec1 to protect its request to RS
6. RS uses Sec1 to verify request. Verification success => Sec1 is validated 
and associated with T1 (at the RS)

7. Client wants to update its access rights: retrieves T2 from AS. Note that 
this T2 has different authorization info, but does not contain input keying 
material ("osc"), only a reference to identify Sec1 ("kid" in "cnf")
8. Client posts T2 to RS, together with nonce N1'
9. RS replies with 2.01 and nonce N2'
10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input material 
("osc" object), N1', N2'
11. Client uses Sec2 to protect its request to RS
12. RS uses Sec2 to verify request. Verification success => Sec2 is validated 
and associated with T2 (at the RS) ; T1 is removed ; Sec1 is removed

In the document right now, we are missing the exact description of how in 8. RS 
identifies that this is an update of access rights for C, aiming at replacing 
T1. We propose to add text stating that (in 3. and 9.) RS MUST check the kid 
(in the "kid" in the "cnf" of the access token), and match it with existing 
security contexts, to realize that this is an update for an existing token 
associated to the sec ctx identified by kid.

Moreover, while comparing with DTLS profile, we realized there is no reason for 
which 8. should be sent unprotected. In fact, doing so opens up to possible 
attacks where an old update (token non expired) is re-injected to the RS by an 
adversary:

* Client sends T1 to RS  --> accepted
* Client sends update of access rights T2 --> accepted
* Client sends update of access rights T3 --> accepted
* Malicious node re-sends T2 --> accepted

Of course that could be mitigated with expiration times and with checking 
"issued at time" field (which is optional). But we believe even though these 
are good points (which might actually be worth adding to the framework), 
sending the token to the RS over the existing protected channel solves this 
issue. So we propose that 8. is protected with OSCORE and Sec Ctx Sec1. For 
DTLS authors: I believe Jim has extrapolated from your document that that is 
the case for the DTLS profile already, i.e. POST token to RS for update of 
access rights is over DTLS; I think it would be worth explicitly stating that 
in the DTLS profile.

Additionally, analogously to DTLS where the same channel is kept even if access 
rights are updated, I do not see any reason at this point to have the endpoints 
re-derive a new security context. This is the biggest change I propose, and can 
be summarized by replacing the points above as follows:

7. Client wants to update its access rights: retrieves T2 from AS. Note that 
this T2 has different authorization info, but does not contain input keying 
material, only a reference to identify Sec1 
8. Client posts T2 to RS, *without nonce* *protected with Sec1*
9. RS *verifies that this is an update of access right, replacing T1 
(associated with Sec1) ; Sec1 is associated with T2; T1 is removed *; RS 
replies with 2.01 *without nonce* *protected with Sec1*
10. Client uses *Sec1* to protect its request to RS

I can already see the objection from implementers: the authz-info endpoint at 
the RS becomes accessible both unprotected (in case the Client is posting a 
token for the first time, points 1. to 6.) and protected (in case Client needs 
to update rights, points 7. to 10.) I believe that defining a NEW endpoint at 
the RS for the "update rights" mechanism would be the best solution, but I 
understand that would require modifications to the framework that Ludwig 
probably would not want to do, as it might delay the document. I think these 
would in practice be 2 different endpoints with the same URI, one OSCORE 
protected and one unprotected. But I need more input from our implementers to 
know if this absolutely cannot be done.

Our proposal:
An RS receiving a token (point 2 and 8) MUST check the kid of the token against 
existing security 

Re: [Ace] Update of access rights

[Francesca Palombini]

Hi Ludwig,

What you state is in fact the change proposed below, I'm happy you support 
making this change. The reason why it does not work that way already is because 
of the way authz-info is defined for the "general" case (exchange of nonces is 
necessary, and derivation of sec ctx). The change I am making suggests to 
differentiate processing between this general case and the update case, but 
doing so without reaching a different endpoint, (which in my opinion would have 
been the cleaner solution) might be slightly annoying for implementers, as you 
also mention.

Francesca

On 05/05/2020, 16:07, "Seitz Ludwig"  wrote:

Hello Francesca,

I have not followed this discussion in detail so excuse me if I missed an 
important detail. That said: I cannot understand why you would want to 
negotiate a new context in step 8 by sending N1'? At that point you have a 
functional OSCORE context established and could just send T2 associated to the 
same context Sec1. That is how I assumed it would work, if that is not clear we 
need to add text to the profiles to clarify.

It is a bit complicated code-wise to have an endpoint that is accessible 
both unprotected and with OSCORE, but I think it is feasible (however not be my 
in the ACE-Java codebase, @Marco?).

/Ludwig

-Original Message-
From: Francesca Palombini  
Sent: den 5 maj 2020 15:37
To: Ace Wg ; Benjamin Kaduk ; Jim Schaad 

Cc: draft-ietf-ace-dtls-author...@ietf.org; 
draft-ietf-ace-oscore-prof...@ietf.org
Subject: Update of access rights

Hi Ace chairs, DTLS authors, Ace framework authors, Ben,

TL;DR: we propose some changes on the OSCORE profile for the "update of 
access rights" scenario. We have comments for the DTLS profile and the ACE 
framework regarding this scenario, and we ask for feedback from ACE OSCORE 
implementers and Ace in general.

In an attempt to answer Jim's 
(https://protect2.fireeye.com/v1/url?k=17a4fe0f-49044461-17a4be94-86b1886cfa64-00f9c0b2a1a8d8cb=1=8a619c43-1ab6-414f-b576-6511488153e9=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fissues%2F20)
 and Ben's 
(https://protect2.fireeye.com/v1/url?k=371c3a3f-69bc8051-371c7aa4-86b1886cfa64-9410fc645a865781=1=8a619c43-1ab6-414f-b576-6511488153e9=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fpull%2F30)
 review of the OSCORE profile, we have been thinking more about the case of 
updating access rights. This has revealed to us authors that something is 
missing from the document, and I believe that this part is not explicitly 
covered in the DTLS profile either, hence this email. 

This is the scenario, and what is currently defined in the OSCORE profile:

1. Client retrieves access token T1 from AS 2. Client posts T1 to RS, 
together with nonce N1 3. RS replies with 2.01 and nonce N2 4. Client and RS 
derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2 5. Client uses Sec1 
to protect its request to RS 6. RS uses Sec1 to verify request. Verification 
success => Sec1 is validated and associated with T1 (at the RS)

7. Client wants to update its access rights: retrieves T2 from AS. Note 
that this T2 has different authorization info, but does not contain input 
keying material ("osc"), only a reference to identify Sec1 ("kid" in "cnf") 8. 
Client posts T2 to RS, together with nonce N1'
9. RS replies with 2.01 and nonce N2'
10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input 
material ("osc" object), N1', N2'
11. Client uses Sec2 to protect its request to RS 12. RS uses Sec2 to 
verify request. Verification success => Sec2 is validated and associated with 
T2 (at the RS) ; T1 is removed ; Sec1 is removed

In the document right now, we are missing the exact description of how in 
8. RS identifies that this is an update of access rights for C, aiming at 
replacing T1. We propose to add text stating that (in 3. and 9.) RS MUST check 
the kid (in the "kid" in the "cnf" of the access token), and match it with 
existing security contexts, to realize that this is an update for an existing 
token associated to the sec ctx identified by kid.

Moreover, while comparing with DTLS profile, we realized there is no reason 
for which 8. should be sent unprotected. In fact, doing so opens up to possible 
attacks where an old update (token non expired) is re-injected to the RS by an 
adversary:

* Client sends T1 to RS  --> accepted
* Client sends update of access rights T2 --> accepted
* Client sends update of access rights T3 --> accepted
* Malicious node re-sends T2 --> accepted

Of course that could be mitigated with expiration times and with checking 
"issued at time" field (which is optional). But we believe even though these 
are good points (which might actually be worth adding to the fra

Re: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-06.txt

[Francesca Palombini]

Hi all,

We just submitted an update to the ace-key-groupcomm document, as promised 
during last interim.

This update covers the points discussed during the meeting, and a couple more 
clarification points that the authors believed necessary. You can see all the 
commits in the PR: https://github.com/ace-wg/ace-key-groupcomm/pull/93 .

Feedback is welcome!
Thanks,
Francesca

On 11/05/2020, 17:11, "Ace on behalf of 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   : Key Provisioning for Group Communication using ACE
Authors : Francesca Palombini
  Marco Tiloca
Filename: draft-ietf-ace-key-groupcomm-06.txt
Pages   : 57
Date: 2020-05-11

Abstract:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-06
https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-06


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] Fwd: Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-05-18

[Francesca Palombini]

Hi,

I’d like to take some time to get a conclusion on the “Update of access rights” 
discussion started here: 
https://mailarchive.ietf.org/arch/msg/ace/dLkW-MYHXfZqmtY7AP7ZBDJpxOw/
(the result of this discussion would have an impact on ace framework and 
profiles).

I’d also like to talk about ace-key-groupcomm-06 and discuss open points. I 
will submit slides.

Thanks,
Francesca


From: Ace  on behalf of Daniel Migault 

Date: Thursday, 14 May 2020 at 05:17
To: Ace Wg 
Subject: [Ace] Fwd: Authentication and Authorization for Constrained 
Environments (ace) WG Virtual Meeting: 2020-05-18

Hi,

This is a reminder that we have an interim meeting Monday May 18. We are 
preparing the agenda, so please let the chairs know if you are willing to 
present.

Please also upload you slides here by Sunday 23:59 anywhere in the world.
https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace

Information on the meeting:
https://datatracker.ietf.org/meeting/interim-2020-ace-06/session/ace

Yours,
Jim and Daniel
-- Forwarded message -
From: IESG Secretary mailto:iesg-secret...@ietf.org>>
Date: Mon, Apr 20, 2020 at 10:12 PM
Subject: [Ace] Authentication and Authorization for Constrained Environments 
(ace) WG Virtual Meeting: 2020-05-18
To: IETF-Announce mailto:ietf-annou...@ietf.org>>
Cc: mailto:ace@ietf.org>>


The Authentication and Authorization for Constrained Environments (ace) Working 
Group will hold
a virtual interim meeting on 2020-05-18 from 10:00 to 11:30 America/New_York 
(14:00 to 15:30 UTC).

Agenda:
(No agenda submitted)

Information about remote participation:
https://ietf.webex.com/ietf/j.php?MTID=md8728a7cd7aa263c70a3c712da89f3ee

___
Ace mailing list
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

Re: [Ace] OSCORE Profile IANA questions

[Francesca Palombini]

Hi Ludwig, Jim,

Thanks for your input.

Ludwig: I agree with you, they do not belong in the token request. I would be 
fine with not registering them as OAuth parameters and only register them as 
Ace parameters, but if I understand correctly the only way to register Ace 
parameters right now is:
1. register them in the OAuth Parameter Registry
2. register the CBOR mapping in the OAuth Parameters CBOR Mappings Registry.
Did I miss something? Is there a better registry where to put these? Otherwise 
I am ok with defining a new category, more on that below.

> [JLS] Look at the OAuth registries - they have some "standardized" names for 
> these interactions as well as the RS-AS pair.

Jim: yes, they have standardized names, but as far as I can see only those 4 
(token request/response, authorization request/response) are allowed in this 
registry (see https://tools.ietf.org/html/rfc6749#section-11.2.1 ), and they 
seem to indicate C-resource owner and C-AS messages.
I went and checked the registry [*], and there is actually one exception from 
Kantara UMA, they registered some parameters with the following locations: 
"client request", "token endpoint", " authorization server response". So now I 
am wondering what these locations mean, and how come they have managed to 
register parameters with locations outside of the template. I am fine with 
using "client request" and "resource server response" but these are not 
standardized names in OAuth.
I think the best way forward is: agree within the working group on some names 
(such as those above, or better ones if you have proposals), then request the 
OAuth Parameters Registry expert review, which is necessary for IANA ok.

[*] 
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
 

On 31/08/2020, 15:42, "Seitz Ludwig"  wrote:

1.) I would not put these parameters in the "token request" category, they 
belong into a new category. Whether they should be registered in the OAuth 
parameters registry is doubtful to me, since I don't see them being used in a 
non-ACE OAuth context. Somewhere in the ACE registries?

2.)  I would propose to put it on ACE page to be created for the framework 
by IANA.

/Ludwig

-Original Message-
From: Ace  On Behalf Of Francesca Palombini
Sent: den 31 augusti 2020 14:53
To: Ace Wg 
Cc: ace-cha...@ietf.org
Subject: [Ace] OSCORE Profile IANA questions

Hi all,

I have two quick questions concerning IANA actions to be done for the 
OSCORE profile:

1) The framework (-params) and the profile are currently conflicting on the 
registration of parameters, and we need to fix that.
In the framework, parameters that are sent from Client to AS (such as 
req_cnf) are registered in the OAuth Parameters Registry as having "Parameter 
Usage Location: token request". The OSCORE profile registers parameters sent 
from Client to RS (such as nonce1) with "Parameter Usage Location: token 
request". The possible "Parameter Usage Location" are "token request" "token 
response" "authorization request" "authorization response" (see 
https://tools.ietf.org/html/rfc6749#section-11.2.1 ). It seems that 
"authorization request/response" are to the Resource Owner, and "token 
request/response" are to the Authorization Server. I think the framework is 
using the right names, but I am not sure what other location to put there, I 
think there is no name for Client-to-RS and RS-to-Client in the registry right 
now.

2) The OSCORE profile defines a new registry, the OSCORE Security Context 
Parameters registry. The question is where to put this registry? My proposal is 
to put it under 
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml . Any 
objections?

Thanks,
Francesca

___
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] Agenda for next monday

[Francesca Palombini]

The OSCORE profile needs around 10 minutes to agree on the IANA registration of 
new parameters. I'll be presenting (but don't need slides).

Francesca

On 01/09/2020, 18:12, "Ace on behalf of Jim Schaad"  wrote:

The chairs need to start building the agenda for next Monday.  If you want
to be on it then you need to let us know.  We are more interested in seeing
items which need to have decisions made than summaries of what has been
done.

Topic
Presenter
Expected Time

Jim


___
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

[Ace] Framework Figure 12

[Francesca Palombini]

Hi,

I noticed a mistake in the current document, that escaped the several rounds of 
review.

Figure 12 states that the ace_profile is supposed to have for value an unsigned 
integer. The ACE Profile registry in Section 8.8 implies that the profile can 
be both positive and negative integers.

Same, in Figure 12, the error is marked as to be an unsigned integer. The OAuth 
Error Code CBOR Mappings Registry (column CBOR value) in section 8.4 implies 
that the errors can be both positive and negative.

The token_type has the same problem, looking at the OAuth Access Token Type 
CBOR Mappings.

I don't know if I missed anything (I only took a look at Fig 12 but the same 
should be done for Fig 2 and Fig 16), but it might be worth for other people to 
take a look as well.
I am starting to think that adding a value to those figures with a reference to 
the registries of values where these apply might have helped, and might still 
help readers.

Thanks,
Francesca

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

Re: [Ace] Framework Figure 12

[Francesca Palombini]

And just to use the correct CBOR terminology, I indeed meant _unsigned and 
negative_ seems to be allowed rather than just unsigned.

Francesca

On 10/09/2020, 10:38, "Francesca Palombini"  
wrote:

Hi,

I noticed a mistake in the current document, that escaped the several 
rounds of review.

Figure 12 states that the ace_profile is supposed to have for value an 
unsigned integer. The ACE Profile registry in Section 8.8 implies that the 
profile can be both positive and negative integers.

Same, in Figure 12, the error is marked as to be an unsigned integer. The 
OAuth Error Code CBOR Mappings Registry (column CBOR value) in section 8.4 
implies that the errors can be both positive and negative.

The token_type has the same problem, looking at the OAuth Access Token Type 
CBOR Mappings.

I don't know if I missed anything (I only took a look at Fig 12 but the 
same should be done for Fig 2 and Fig 16), but it might be worth for other 
people to take a look as well.
I am starting to think that adding a value to those figures with a 
reference to the registries of values where these apply might have helped, and 
might still help readers.

Thanks,
Francesca


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

[Ace] WGLC review of draft-ietf-ace-mqtt-tls-profile-07

[Francesca Palombini]

Hi,

Thank you for this work! Here is my review of the document.

Thanks,
Francesca

  The response includes the
   parameters described in Section 5.6.2 of the ACE framework
   [I-D.ietf-ace-oauth-authz].

The fact that the profile parameter with value "mqtt_tls" is included in this 
response must be specified here.

--

" The Client and the AS MUST
   perform mutual authentication."

I am not sure this is a testable statement. What about specifying that they 
MUST use a protocol that provides mutual authentication instead?

--

 The Client requests an access token
   from the AS as described in Section 5.6.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz], however, it MUST set the profile
   parameter to 'mqtt_tls'. 

Why adding this here? This is in practice implementing a negotiation of 
profile. If this is necessary in this MQTT profile I am wondering why it is 
defined here and not in the framework. In general, I dislike the profile to 
contradict what defined in the framework.

--

 When CBOR is used, the
   interactions must implement Section 5.6.3 of the ACE framework
   [I-D.ietf-ace-oauth-authz].

normative MUST?

--

The Client and the Broker MUST perform mutual authentication.

Same as before, is this a testable statement? Maybe this sentence does not need 
to use normative language, but rather descriptive. The details of what Client 
and Broker MUST do is in the following sentences.

--

"TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen.

Any reason why this is a SHOULD NOT? Can we add motivation of when this would 
be allowed (although not recommended)

--

 It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.

I think it would be helpful to say when this option is recommended vs the 
others. In the next section, it is described in more details that the 
communication with authz-info is done with "TLS:Anon-MQTT:None" and then after 
that TLS:Known(RPK/PSK)-MQTT:none. This seems to not agree with the 
recommendation, which is why I think the recommendation needs more context.

--

 In this profile, the Broker SHOULD always start with a
   clean session regardless of how these parameters are set.

Does this mean that when the Broker recognize that this spec is used, it SHOULD 
disregard the parameters value and start a clean session? What are the cases 
where this is not done ("If necessary" in the next paragraph)?

--

 includes state on client subscriptions, QoS 1 and QoS 2 messages

At this point I don't know what QoS 1 and QoS messages are, they have not been 
introduced. Only QoS levels have. Maybe a reference or a pointer would help.

--

RE Authentication Data (Sections 2.2.4.1, 2.2.4.2 etc): I haven't read MQTT in 
details, but I don't really see any encoding of the Authentication Data field 
in this spec, only that it contains one or more parameters. I would assume that 
is should be in scope of this doc, but if it isn't, that should be clarified.

--

2.2.6.1.  Unauthorised Request: Authorisation Server Discovery

If the Client does not provide a valid token or omits the
   Authentication Data field, the Broker triggers AS discovery. 

Following discussion about AS discovery in this ML: I think this should change 
to being possible, not mandatory. That means changing: s/the Broker triggers AS 
discovery/the Broker MAY trigger AS discovery. I still think it is useful to 
have this section, I am just suggesting it becomes optional.

Also note that not providing a token or omittion the Authentication Data field 
are not the possible error messages. A malformed token or Authenticated Data 
are also possible.

--

 Figure 5: AIF-MQTT data model

Need to reference CDDL.

--

Section 3:
What does it mean to have an empty array for scope? (as that is allowed)

--

Scope appears in section 2.1 for the first time, but its encoding is only 
defined in section 3.

--

  If the Will Flag is set, then the Broker MUST check that the
   token allows the publication of the Will message (i.e. the Will Topic
   filter is found in the scope).

This sentence is not super clear to me: "if the Will Flag is set" in which 
message? How is the Will Topic filter added to scope? This comes from my 
ignorance of MQTT, so feel free to skip it, but I think an example would have 
helped me here.

--

Section 4 talks about reauthentication. What described for reauthentication 
should work also for update of access rights, is that correct? Does that add 
any considerations? Anyway I think update of access rights should be discussed 
in this document.

--

If a client's permissions get revoked but the access
   token has not expired, the RS may still grant publish/subscribe to
   revoked topics. 

What does it mean in practice that client's permissions get revoked? (also nit 
s/permissions get/permission gets) Do you mean that there is no way to do 
access right revocation? If that's the case, I did not understand "the RS may 
still grant ..." as being a negative consequence, so maybe it 

[Ace] FW: New Version Notification for draft-ietf-ace-key-groupcomm-09.txt

[Francesca Palombini]

Hi,

This update deals with Jim's review comments for version -07 and following 
IETF108.
We are going to address Christian's review ( 
https://mailarchive.ietf.org/arch/msg/ace/q03pyqFHFT4CpdsckLLlifPB3w0/ ) in the 
next update.

Thanks,
Francesca

On 04/09/2020, 15:00, "internet-dra...@ietf.org"  
wrote:


A new version of I-D, draft-ietf-ace-key-groupcomm-09.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-ietf-ace-key-groupcomm
Revision:   09
Title:  Key Provisioning for Group Communication using ACE
Document date:  2020-09-04
Group:  ace
Pages:  61
URL:https://www.ietf.org/id/draft-ietf-ace-key-groupcomm-09.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
Html:   https://www.ietf.org/id/draft-ietf-ace-key-groupcomm-09.html
Htmlized:   https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-09
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-09

Abstract:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   
https://protect2.fireeye.com/v1/url?k=b951d6d2-e7f1781f-b9519649-86073b36ea28-dd68199b84112dab=1=43c18049-3363-489e-9e80-01780d314b99=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm.




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

[Ace] OSCORE Profile IANA questions

[Francesca Palombini]

Hi all,

I have two quick questions concerning IANA actions to be done for the OSCORE 
profile:

1) The framework (-params) and the profile are currently conflicting on the 
registration of parameters, and we need to fix that.
In the framework, parameters that are sent from Client to AS (such as req_cnf) 
are registered in the OAuth Parameters Registry as having "Parameter Usage 
Location: token request". The OSCORE profile registers parameters sent from 
Client to RS (such as nonce1) with "Parameter Usage Location: token request". 
The possible "Parameter Usage Location" are "token request" "token response" 
"authorization request" "authorization response" (see 
https://tools.ietf.org/html/rfc6749#section-11.2.1 ). It seems that 
"authorization request/response" are to the Resource Owner, and "token 
request/response" are to the Authorization Server. I think the framework is 
using the right names, but I am not sure what other location to put there, I 
think there is no name for Client-to-RS and RS-to-Client in the registry right 
now.

2) The OSCORE profile defines a new registry, the OSCORE Security Context 
Parameters registry. The question is where to put this registry? My proposal is 
to put it under 
https://www.iana.org/assignments/core-parameters/core-parameters.xhtml . Any 
objections?

Thanks,
Francesca

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

Re: [Ace] FW: New Version Notification for draft-ietf-ace-key-groupcomm-09.txt

[Francesca Palombini]

Hi Daniel,

We believe we can address Christian’s comments by next IETF meeting. We will 
request some time on the agenda to present the update and discuss any open 
point.

Thanks,
Francesca

From: Daniel Migault 
Date: Thursday, 15 October 2020 at 20:35
To: Francesca Palombini 
Cc: Ace Wg 
Subject: Re: [Ace] FW: New Version Notification for 
draft-ietf-ace-key-groupcomm-09.txt

Hi Francesca and Marco,

I am just wondering if Christian's comment could be addressed by the next IETF 
meeting.

Yours,
Daniel

On Fri, Sep 4, 2020 at 9:05 AM Francesca Palombini 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi,

This update deals with Jim's review comments for version -07 and following 
IETF108.
We are going to address Christian's review ( 
https://mailarchive.ietf.org/arch/msg/ace/q03pyqFHFT4CpdsckLLlifPB3w0/ ) in the 
next update.

Thanks,
Francesca

On 04/09/2020, 15:00, 
"internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" 
mailto:internet-dra...@ietf.org>> wrote:


A new version of I-D, draft-ietf-ace-key-groupcomm-09.txt
has been successfully submitted by Francesca Palombini and posted to the
IETF repository.

Name:   draft-ietf-ace-key-groupcomm
Revision:   09
Title:  Key Provisioning for Group Communication using ACE
Document date:  2020-09-04
Group:  ace
Pages:  61
URL:https://www.ietf.org/id/draft-ietf-ace-key-groupcomm-09.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
Html:   https://www.ietf.org/id/draft-ietf-ace-key-groupcomm-09.html
Htmlized:   https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-09
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-09

Abstract:
   This document defines message formats and procedures for requesting
   and distributing group keying material using the ACE framework, to
   protect communications between group members.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   
https://protect2.fireeye.com/v1/url?k=b951d6d2-e7f1781f-b9519649-86073b36ea28-dd68199b84112dab=1=43c18049-3363-489e-9e80-01780d314b99=https%3A%2F%2Fgithub.com%2Face-wg%2Face-key-groupcomm.




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<http://tools.ietf.org>.

The IETF Secretariat



___
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

Re: [Ace] OSCORE Profile status update and way forward

[Francesca Palombini]

Hi Christian, Daniel,

Daniel: I agree that what you describe is the best way forward. Once the PR 
regarding the negotiation of Ids is merged, I can only see a minor addition to 
the draft, to clarify what Christian has brought up. By the end of this week we 
should have Christian's comment implemented as well. After that, we're ready 
for another round of reviews, and I think a WGLC is warranted.

Christian, let us know if there is anything else except some more 
considerations covering what you are saying. Göran summarized it well, but 
basically no, there is no particular benefit. The sentence was added as the 
response from a review comment, but it seems like a good idea to add more 
context to it. 

Thanks,
Francesca

On 15/10/2020, 20:01, "Göran Selander"  wrote:

Hi Christian,

The purpose of the update was to clarify that Appendix B.2 of RFC 8613 
could be used in conjunction with the ACE OSCORE profile. But as you point out, 
the use of B.2 would need to be understood between the client and server 
beforehand. There are slight differences: With B.2 there is no need to 
transport the access token again. And B.2 can be triggered by the (resource) 
server, if it understands that it does not have the right context (which can 
happen even if there is no ID context in the request). Just using the ACE 
OSCORE profile, the client would need to understand that the context is lost 
and run the protocol again. So, there is a difference but essentially the same 
functionality can be obtained.

Would it be sufficient to clarify the differences as above to address your 
comment?

Thanks,
Göran


On 2020-10-09, 17:45, "Christian Amsüss"  wrote:

Hello Francesca, hello ACE group,

On Mon, Sep 21, 2020 at 01:48:33PM +, Francesca Palombini wrote:
> - clarified that Appendix B.2 of OSCORE can be used with this profile,
> and what implementers need to think about if they do.

I understand B.2 to be something that the involved parties need to agree
on beforehand; after all, the ID context may be something the server
relies on (at least for the initial attempt) to find the right key,
especially when multiple AS are involved. (For example, the RS could
have an agreement that the AS may issue any KID as long as they use a
particular ID context). If the server expects B.2 to happen (which, as
it is put now, it can as long as it supports it in general), it needs to
shard its KID space for the ASs it uses. (Generally, B.2 is mutually
exclusive with ID contexts's use of namespacing KIDs).

Is the expectation that clients that do not anticipate B.2 by the time
they are configured with their AS just don't offer B.2 to their peers?

Given B.2 is in its current form client-initiated only (AFAIR we had
versions where ID1 could be empty in draft versions, but currently it
reads as client-initialized), does B.2 have any benefits for ACE-OSCORE
clients? After all, they could just as well post the token with a new
nonce1 to the same effect.

Kind Regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater 
powers.
  -- Bene Gesserit axiom


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

[Ace] OSCORE profile update

[Francesca Palombini]

Hi,

This mail is to notify the WG of a minor change to the OSCORE profile. It was 
brought up in the github issues by Christian (see: 
https://github.com/ace-wg/ace-oscore-profile/issues/40 ) and discussed offline 
during IETF108 that the profile adds a requirement of the token always being 
encrypted, that is not inherited from the framework. The reason for this 
additional requirement was that the authors assumed the token to always be 
self-contained. After discussion, we have come to the conclusion that this 
requirements does not need to be in the profile, and we have removed it: 
https://github.com/ace-wg/ace-oscore-profile/commit/dd7a9b5a30dacd0ca55a1eb42b26cd13d1048d57
 

We do not think this is a major change, but rather a fix, so we don't think we 
need to move back to the WG, but the chairs/AD can let us know if that's not 
the case. We are ready to submit a v-11 including this change and updates 
following Last Call reviews and IANA review, assuming there is no objection. 
Pull request including all changes is here: 
https://github.com/ace-wg/ace-oscore-profile/pull/42 

Once v-11 is up, we consider all comments addressed, and are ready for the next 
step.

Thanks,
Fracesca

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

Re: [Ace] Genart last call review of draft-ietf-ace-oscore-profile-11

[Francesca Palombini]

Hi Elwyn,

Thank you so much for your review. We have now worked on all your comments in a 
pull request, and will soon submit an update to the document. All the nits are 
adressed in two commits: 
https://github.com/ace-wg/ace-oscore-profile/commit/a7f9483e96107a678b80217ba0b2d3dcfb488192
  and 
https://github.com/ace-wg/ace-oscore-profile/commit/855c34865120a1f09c28ebe6dce93acedb1f3e04
 . Detailed comments inline, prefaced with [FP].

Thanks again for the good comments,
Francesca

On 22/07/2020, 00:56, "Elwyn Davies via Datatracker"  wrote:

Reviewer: Elwyn Davies
Review result: Almost Ready

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.

For more information, please see the FAQ at

.

Document: draft-ietf-ace-oscore-profile-11
Reviewer: Elwyn Davies
Review Date: 2020-07-21
IETF LC End Date: 2020-07-20
IESG Telechat date: Not scheduled for a telechat

Summary:  Almost ready.  There is one minor issue that needs sorting out 
and a
fair number of nits.  Overall I have to say that I found it difficult to 
keep
clear in my mind what messages were fully encrypted and which ones were 
sent en
clair and which are in some intermediate class.  The authors might wish to 
go
back over the document from the point of a naive reader to ensure that it is
clear for implementers.

Major issues:
None

Minor issues:
s2, para 5:  Where does the 'input salt' come from?  The term is not used
anywhere else in this document and  isn't defined or mentioned in either
dreft-ace-oauth-authz or RFC 8613.

[FP]: Right, as Ben mentioned, this was the result of an update to the name of 
the term. The input salt is used as one of the inputs to the OSCORE Master 
Salt. I have now rephrased to clarify that "salt" contains in fact an input to 
the OSCORE Master Salt. 
(https://github.com/ace-wg/ace-oscore-profile/commit/07ced6a4f908491d7d70c8c2d6fca7596e3801d4
 )

Nits/editorial comments:
s1:  Need to expand CoAP on first use.

[FP]: Ok.

s1: Need to expand CBOR on first use.

[FP]: Actually, because CBOR appears on first use as the first term of COSE, I 
have not expanded it in this location. I have added a normative reference to 
CBOR in the terminology and expanded it there.

s1.2, CDDL:  It would useful to mention that the predefined type names from
CDDL, especially bstr for byte strings and tstr for text strings,  are used
extensively in the document.

[FP]: Thanks for the suggestion, now added.

s2, para 1: s/overview on how/overview of how/

[FP]: Ok.

s2, para 1: s/as well as OSCORE setup/as well as the OSCORE setup/

[FP]: Ok.

s2, para 2: s/that's/that is/

[FP]: Ok.

s2, para 8: Need to expand AEAD on first use.

[FP]: Ok.

s2 and Figure 1:  It would be helpful to the reader if Figure 1 and its
descriptive paragraph was placed closer to the beginning of s2.  Otherwise
things like Client C' need more explanation to point the reader at the 
figure.

[FP]: I have kept Figure 1 at the end of the section, but I have now removed 
all instances of "Client C", since they don't make sense before seeing the 
picture, as you rightly noted.

s2, para 3:

This says:
To determine the AS in charge of a resource hosted at the RS, the client C 
MAY
send an initial Unauthorized Resource Request message to the RS. The RS then
denies the request and sends the address of its AS back to the client C as
specified in section 5.1 of [I-D.ietf-ace-oauth-authz]. The access token
request and response MUST be confidentiality-protected and ensure 
authenticity

I found the combination of the Unauthorized Requst and the
confidentiality-protected etc confusing.  If the last sentence does apply to
the Unuthorized Request it would be helpful to make it clear that this is 
not
just a generic statement but does apply to the Unauthorized Request as well.

[FP]: Ok, thank you for pointing it out. I have now clarified in the beginning 
of the paragraph that the access token request is different from the 
Unauthorized Request.

Figure1:  For consistency the first line should say Unauthorized Rsource
Request.  I would also suggest explaining the mapping between what is said 
in
the text and the terms 'Ceation Hints' and 'Access Information' used in the
figure.

[FP]: Ok about the Unauthorized Resource Request. I have not explained further 
about the mapping between the overview text and the figure, as I do not want to 
go into too much detail there, but I have clarified that the names of messages 
come from the framework.

s3.1, para after Figure 2:  The term 'audience' appears in this paragraph
without any context 

Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11

[Francesca Palombini]

Hi Linda,

Thank you for your review. Ben has already clarified our aim for most of your 
points, thanks Ben. I just want to add that we have now added some text to 
clarify the CBOR formatting of Figure 7, you can see the diff here: 
https://github.com/ace-wg/ace-oscore-profile/commit/55d500a8922b5694dd821d4b1109cc162313fc2f
 This will be included in the next update of the document.

Thanks,
Francesca

On 27/07/2020, 20:08, "Benjamin Kaduk"  wrote:

Hi Linda,

On Sun, Jul 19, 2020 at 08:16:17PM -0700, Linda Dunbar via Datatracker 
wrote:
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's 
ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any 
other
> last call comments.
> 
> This document describes how to set specific parameters in using  the
> Authentication and Authorization for Constrained Environments (ACE) 
framework
> [I-D.ietf-ace-oauth-authz]. The document is written clear, except some 
minor
> issues:
> 
>  Section 4.1.1 states that Nonce Parameter must be sent from the client 
to RS.
>  What would be the problem if the client doesn't include the "NONCE"?

There's a little more discussion of the N1 in the previous section, but in
essence, this nonce is required to protect the client against replayed
responses.  Since the token contents (including key derivation material)
would be unchanged across security contexts, the nonce is used to make each
one different; it has to be client-generated so that the client is sure
that this security context is "fresh" (vs. replayed).

> Page 12: It asks RFC editor to validate the numbers listed in Figure 7.  
There
> is no explanation or comments for those values. It will be very difficult 
for
> RFC editor to validate. It seems to me there are 4 columns but  I can't
> understand the meaning of the values under 1st, 2nd, and 3rd columns.

I think this is just a note that the RFC Editor should make sure that
someone has checked the values (i.e., the authors).  The RFC Editor does
not need to be the one actually doing the checking.

Thanks for the review,

Ben

> it is kind of difficult to validate the correctness by just reading 
through the
> document.  It would be better to have an implementation report of the 
proposed
> "Profile".
> 
> Best Regards,
>  Linda Dunbar
> 
> 
> 

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

Re: [Ace] WGLC review of draft-ietf-ace-mqtt-tls-profile-07

[Francesca Palombini]

Hi Cigdem,

Thanks for the quick reply! Answers inline.

To Ludwig and the WG, which might not otherwise see the comment: Cigdem and I 
have a different interpretations of what the framework allows to put in the 
“ace_profile” parameter in the request from Client to AS (See (***) below). I 
think this might require clarifications in the framework either way.

Thanks,
Francesca

From: Cigdem Sengul 
Date: Sunday, 20 September 2020 at 23:02
To: Francesca Palombini 
Cc: Ace Wg , “draft-ietf-ace-mqtt-tls-prof...@ietf.org” 

Subject: Re: WGLC review of draft-ietf-ace-mqtt-tls-profile-07




Hello Francesca,

Thank you for your review. My responses are inside; in the cases I have not
understood a comment, I asked for clarifications.
Kind regards,
--Cigdem


On Tue, Sep 15, 2020 at 2:38 PM Francesca Palombini <
rancesca.palombini@ericsson.com> wrote:

>
>   The response includes the
>parameters described in Section 5.6.2 of the ACE framework
>[I-D.ietf-ace-oauth-authz].
>
> The fact that the profile parameter with value “mqtt_tls” is included in
> this response must be specified here.
>
> [CS:  Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65, and
will be fixed in the next revision.]


> --
>
> “ The Client and the AS MUST
>perform mutual authentication.”
>
> I am not sure this is a testable statement. What about specifying that
> they MUST use a protocol that provides mutual authentication instead?
>
> [CS: I followed the core document statement, which also says: “It is also
REQUIRED that the
   communicating endpoints perform mutual authentication.”.
]

FP: Right. However I think that the framework’s requirement is ok even if it is 
not implementable because the framework is not supposed to be implemented by 
itself. So the framework’s requirement is more a requirement on what the 
profile must specify. What I was looking for in the profile was some indication 
on how to perform the mutual authentication, hence the suggested rephrasing. 
It’s not a major change though, so feel free to disregard.

> --
>
>  The Client requests an access token
>from the AS as described in Section 5.6.1 of the ACE framework
>[I-D.ietf-ace-oauth-authz], however, it MUST set the profile
>parameter to ‘mqtt_tls’.
>
> Why adding this here? This is in practice implementing a negotiation of
> profile. If this is necessary in this MQTT profile I am wondering why it is
> defined here and not in the framework. In general, I dislike the profile to
> contradict what defined in the framework.
>
> [CS: This is because I’ve interpreted what I read in 5.6.4 as the
ace_profile can be used as a parameter in the request.

“5.6.4.  Request and Response Parameters:  This section provides more
detail about the new parameters that can be used in access token requests
and responses”
5.6.4.3.  Profile
“
So, I did not think that specifying what the profile should be contradicted
the document.
]

(***)
FP: Your interpretation was surprising to me. I always understood that the 
ace_profile parameter can only be included in the request with the null value, 
so that the client can indicate to the AS that it wants to receive the 
ace_profile back. I went through the relevant sections again, and the following 
text in 5.6.1. "Client-to-AS Request" is what I based my understanding on.

o  The client can send an empty (null value) "ace_profile" parameter
  to indicate that it wants the AS to include the "ace_profile"
  parameter in the response.  See Section 5.6.4.3.

And in 5.6.4.3. "Profile":

   Clients that want the AS to provide them with the "ace_profile"
   parameter in the access token response can indicate that by sending a
   ace_profile parameter with a null value (for CBOR-based interactions)
   or an empty string (for JSON based interactions) in the access token
   request.

There is no text about allowing any other value than the null value in the 
ace_profile, or how the AS should react to receiving such a parameter with 
non-null value (what if it does not support the profile? That at least should 
be documented) so I just assumed that it was not supported.

I'd like to get the opinion of Ludwig and the WG on this, but I think this 
requires some clarifications in the framework in both cases:
* if your interpretation is correct, there should be more text in the framework 
about how that works
* if my interpretation is correct, it should be clarified that in the request 
the only acceptable value for the "ace_profile" is null.


--
>
>  When CBOR is used, the
>interactions must implement Section 5.6.3 of the ACE framework
>[I-D.ietf-ace-oauth-authz].
>
> normative MUST?
>
>   [CS:  Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65,
and will be fixed in the next revision.]

--
>
> The Clie

Re: [Ace] WGLC review of draft-ietf-ace-mqtt-tls-profile-07

[Francesca Palombini]

Hi Ludwig,

Thank you for the lightning quick reply! I think that maybe something on the 
lines of “The client MUST NOT send a non-empty “ace_profile” parameter.” in 
5.6.1. I think the confusion might have come from the term “can”, “it can send 
an empty parameter” does not imply that “it must not send the parameter if the 
value is non-empty”. Also Cigdem maybe has a better proposal on how to clarify, 
since she interpreted the text that way.

Thanks,
Francesca

From: Seitz Ludwig 
Date: Thursday, 24 September 2020 at 15:39
To: Francesca Palombini , Cigdem Sengul 

Cc: "draft-ietf-ace-mqtt-tls-prof...@ietf.org" 
, Ace Wg 
Subject: RE: WGLC review of draft-ietf-ace-mqtt-tls-profile-07

Hello Francesca, Cigdem,
I believe I know the reason for the confusion:  Earlier versions of the 
framework allowed the clients to indicate a preference for a specific profile 
by sending in values with the “ace_profile” parameter in the access token 
request.
This option was removed because we came to the conclusion that the AS would 
determine the profile to be used based on the registration information from 
both client and RS. Instead the only option for the client is (as Francesca 
wrote at *** below)  to send an empty “ace_profile” parameter in the access 
token request in order to query the selected profile (here the assumption was 
that this would be hard-coded in the client in most cases and therefore 
querying is optional).

I believe the text in the framework is quite clear:

“5.6.1.  Client-to-AS Request
[…]
o  The client can send an empty (null value) "ace_profile" parameter
  to indicate that it wants the AS to include the "ace_profile"
  parameter in the response.  See Section 5.6.4.3.
“

And later:

“5.6.4.3.  Profile
[…] Clients that want the AS to provide them with the "ace_profile"
   parameter in the access token response can indicate that by sending a
   ace_profile parameter with a null value (for CBOR-based interactions)
   or an empty string (for JSON based interactions) in the access token
   request.”

What kind of extra clarification would you suggest I add?

/Ludwig



From: Ace  On Behalf Of Francesca Palombini
Sent: den 24 september 2020 15:13
To: Cigdem Sengul 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
Subject: Re: [Ace] WGLC review of draft-ietf-ace-mqtt-tls-profile-07

Hi Cigdem,

Thanks for the quick reply! Answers inline.

To Ludwig and the WG, which might not otherwise see the comment: Cigdem and I 
have a different interpretations of what the framework allows to put in the 
“ace_profile” parameter in the request from Client to AS (See (***) below). I 
think this might require clarifications in the framework either way.

Thanks,
Francesca

From: Cigdem Sengul mailto:cigdem.sen...@gmail.com>>
Date: Sunday, 20 September 2020 at 23:02
To: Francesca Palombini 
mailto:rancesca.palomb...@ericsson.com>>
Cc: Ace Wg mailto:ace@ietf.org>>, 
“draft-ietf-ace-mqtt-tls-prof...@ietf.org<mailto:draft-ietf-ace-mqtt-tls-prof...@ietf.org>”
 
mailto:draft-ietf-ace-mqtt-tls-prof...@ietf.org>>
Subject: Re: WGLC review of draft-ietf-ace-mqtt-tls-profile-07




Hello Francesca,

Thank you for your review. My responses are inside; in the cases I have not
understood a comment, I asked for clarifications.
Kind regards,
--Cigdem


On Tue, Sep 15, 2020 at 2:38 PM Francesca Palombini <
rancesca.palombini@ericsson.com> wrote:

>
>   The response includes the
>parameters described in Section 5.6.2 of the ACE framework
>[I-D.ietf-ace-oauth-authz].
>
> The fact that the profile parameter with value “mqtt_tls” is included in
> this response must be specified here.
>
> [CS:  Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65, and
will be fixed in the next revision.]


> --
>
> “ The Client and the AS MUST
>perform mutual authentication.”
>
> I am not sure this is a testable statement. What about specifying that
> they MUST use a protocol that provides mutual authentication instead?
>
> [CS: I followed the core document statement, which also says: “It is also
REQUIRED that the
   communicating endpoints perform mutual authentication.”.
]

FP: Right. However I think that the framework’s requirement is ok even if it is 
not implementable because the framework is not supposed to be implemented by 
itself. So the framework’s requirement is more a requirement on what the 
profile must specify. What I was looking for in the profile was some indication 
on how to perform the mutual authentication, hence the suggested rephrasing. 
It’s not a major change though, so feel free to disregard.

> --
>
>  The Client requests an access token
>from the AS as described in Section 5.6.1 of the ACE framework
>[I-D.ietf-ace-oauth-authz], however, it MUST set the profile
>parameter to ‘mqtt_tls’.
>
> Why adding this here? This is in pr

[Ace] OSCORE Profile status update and way forward

[Francesca Palombini]

Hi all,

Following the discussions here and at the latest interim, I have submitted a 
new version of the OSCORE profile. This version addresses the last call/post 
last call comments: Gen ART review, the OPS Dir review, IANA comments and 
John's review. Diff here: 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-12.txt 

Re IANA comments, I have gone with Ludwig's suggestion and named the "location" 
for the new IANA parameters as "client-rs request" and "rs-client response". I 
think this is the clearest and simplest option. If there is no objection to 
those names, I will send the email to the DE on Wednesday.

Gen ART and OPS Dir review were mostly editorial with some bug fixes. To answer 
John's review, I have done some bigger changes, additional to what I consider 
editorial and clarifications. Main changes are summarized here:
- Master Salt construction for JSON/Base64 encoding is now specified. Examples 
for both CBOR and JSON are added.
- added a requirement: clarified that the AS MUST send different OSCORE Input 
Material to different clients
- added security considerations on one client using the same OSCORE Input 
Material with different RS
- removed AS discovery mechanism (this is just inherited from the framework)
- clarified that Appendix B.2 of OSCORE can be used with this profile, and what 
implementers need to think about if they do.
- renamed OSCORE_Security_Context into OSCORE_Input_Material

I consider all of John's comments addressed, with two exceptions: 
a. renaming clientId and serverId, as that was discussed previously and I don't 
see a better option for it, and 
b. the id negotiation mechanism. As discussed in the meeting, I worked on 
several options to add the identifier negotiation mechanism: 

1. define an additional optional mechanism that would work on top of the 
existing OSCORE profile if both nodes support it. Because such a mechanism is 
optional, attackers in the middle could easily make the nodes roll back to 
OSCORE without this mechanism, which is why I don't think this is the optimal 
solution
Draft: https://tools.ietf.org/html/draft-palombini-ace-oscore-profile-id-00 

2. define an OSCORE profile v-2 which is equal to the existing OSCORE profile + 
adds the negotiation mechanism. Much more thought is needed about how these two 
different profiles interact (can the client try to run a v2 profile if it 
receives a v1 token? How does the RS react if it does support v1 but not v2? ), 
but it seems to me that it becomes very complicated to try to cover all 
cornercases and profiles overlap. Moreover I was hoping for a simple, short 
document. It is not.
Draft: https://tools.ietf.org/html/draft-palombini-ace-oscore-profile-v2-00 

3. include the identifier negotiation mechanism in the profile itself. I 
implemented this in a separate branch in the github: 
https://github.com/ace-wg/ace-oscore-profile/tree/id-negotiation . You can see 
the diff with the draft here: 
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-oscore-profile.txt=https://ace-wg.github.io/ace-oscore-profile/id-negotiation/draft-ietf-ace-oscore-profile.txt
 
Considered the changes which have already happened as a consequence of last 
call reviews, it might be worth for the working group to consider this option, 
although it is a major change conceptually to the document. You can see that 
the changes are not huge, it actually removes a lot of text.

We welcome opinions from everybody in the wg, and guidance from our chairs and 
AD on what's the best way to move forward at this point.

Francesca

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

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-13.txt

[Francesca Palombini]

Hi all,

This is the update implementing the ID negotiation, and the minor clarification 
concerning appendix B.2 of OSCORE, as brought up by Christian.

Any feedback is welcome.
Thanks,
Francesca

On 27/10/2020, 17:14, "Ace on behalf of 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   : OSCORE Profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-13.txt
Pages   : 32
Date: 2020-10-27

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security and proof-of-possession
   for a key owned by the client and bound to an OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13


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] Review of ietf-ace-key-groupcomm-07

[Francesca Palombini]

Hi Jim,

Thank you so much for another extensive review! We have submitted v-08 of the 
draft to answer it.
Comments inline. If there is any answer/update that does not satisfy you, 
hopefully we can continue the discussion by mail and figure out the major 
points to discuss during IETF108.

Thanks,
Francesca and Marco

On 26/06/2020, 06:02, "Jim Schaad"  wrote:

* Section 1 para 1 - I have a vague memory of deciding that we were going to
become CBOR only with this document per the argument from Carsten.  I did
not find this in the minutes so this could easily be some other document
that I am thinking of.

FP: Yes, and we are in fact limiting this document to CBOR, since we don’t have 
any JSON media-type registered anymore (there used to be). This sentence was 
included just to mention that a conversion to JSON is possible to, while not 
explicitly supported here.

* Section 2 - I have a problem with Figure 1 in terms of what is labeled as
an RS.  The text below calls the KDC and RS and not the Dispatcher.  

FP: : Yes, in terms of ACE the KDC is the RS. In general terms, the RS can be a 
dispatcher (e.g. pubsub) or the group members (e.g. multicast). But I agree 
this is confusing, we have removed the “RS” from the Dispatcher in the picture.

* Section 2 - update DTLS reference

FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no profile 
defined to set up DTLS 1.3, so I don’t think we should update to 1.3 here.

* Section 2 - I think you might want the last sentence to refer to step 3
rather than section  - The pointer to the section has already been provided
but pointing back to the figure makes a degree of sense.

FP: Ok, fixed now.

* Section 2 - KDC - This is the first time that I have heard about the fact
that this is a two part protocol - You should tell me about the phases
before you get here.

FP: Ok, we have added some text in the beginning of Section 2, before the 
figure.

* Section 2 - "Leaving or removing" this is a sentence which does not read
well.  (Also why is this current when no other line is.)

FP: Ok, we have tried rephrasing the bullet list again.

* Section 2 - You should probably have a numbered item that corresponds to
the secure group communication line in the picture.

FP: Ok, we have added that and added the 2 paragraphs after the picture to the 
bulleted list, as we felt it fitted better there.

* Section 3 - The content format application/ace+cbor is not defined by the
transport profiles but by the framework.

FP: The point is that the profiles might change the content format, so even if 
this specific one ace+cbor is defined in Ace, profiles might define and use 
other ones. Rephrased to clarify.

* Section 3.1 - Given that a role is defined as a tstr, that format is not
usable if one wishes to assign an integer abbreviation per OPT7.

FP: I tried to reformulate here that the aif is the default encoding, and 
specify that the other format defined is an example. In the end it is up to the 
application profile to specify the format of scope.

* Section 3.1 - the "Other additional" seems to be a strange thing to have
in this list because it does not match the lead in paragraph.

FP: Right, we have moved it out of the list.

* Section 3.1 - Is there a reason that a gid is a bstr and not a tstr.  I
assume that this is the same as GROUPNAME which much be a text string to be
in a url-path.

FP: We have modified that to be tstr to be consistent with ace key groupcomm 
oscore, but please note this is only an example.

* Section 3.2 - s/non expired/non-expired/

FP: Fixed.

* Section 3.2 - the def of scope seems odd because it is not well defined if
it would be the same as the requested scope. (AS response)

FP:  I need more clarifications: Is it the following that is strange “'scope' 
containing the granted scope, if different from the scope requested by the 
client. “ ? Note that the terminology “requested and granted scope” comes  from 
OAuth: https://tools.ietf.org/html/rfc6749#section-3.3. I removed the second 
part of the sentence as per comment below.

* Section 3.2 - the text w/ scope can be simplified to the scope that the AS
grants access to and skip the last sentence.

FP: Ok, simplified. I kept the last sentence as it is more precise in my 
opinion to keep the pointer to the encoding.

* Section 3.2 - ditto w/ above on "other additional"

FP: Ok, fixed.

* Section 3.3 - s/request necessary information/request information/

FP: Ok, fixed.

* Section 3.3 - Am I supposed to know why I care about public keys at this
point?

FP:  I thought this sentence was supposed to cover it (second paragraph of 
3.3): “Optionally, the Client might want to request necessary information 
concerning the public keys in the group, as well as concerning the algorithm 
and related parameters for computing signatures in the group.” What’s 

Re: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-01.txt

[Francesca Palombini]

Hi,

This update converts the document to the more general structure to cover for 
MQTT as well. There is some TODOs left for the MQTT parts, that we plan to 
update.

Thanks,
Francesca

On 03/07/2020, 13:41, "Ace on behalf of 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   : Pub-Sub Profile for Authentication and 
Authorization for Constrained Environments (ACE)
Author  : Francesca Palombini
Filename: draft-ietf-ace-pubsub-profile-01.txt
Pages   : 21
Date: 2020-07-03

Abstract:
   This specification defines an application profile for authentication
   and authorization for publishers and subscribers in a pub-sub setting
   scenario in a constrained environment, using the ACE framework.  This
   profile relies on transport layer or application layer security to
   authorize the publisher to the broker.  Moreover, it relies on
   application layer security for publisher-broker and subscriber-broker
   communication.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-pubsub-profile-01
https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-pubsub-profile-01


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] Call for adoption draft-tiloca-ace-oscore-gm-admin

[Francesca Palombini]

Hi,

I have reviewed the document and I believe this will be helpful for the work we 
are doing in Ace. +1 for adoption.

Thanks,
Francesca

From: Ace  on behalf of Daniel Migault 

Date: Monday, 22 June 2020 at 22:31
To: Ace Wg 
Subject: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin

Hi,

Following the interim meeting this morning, this email starts a call for 
adoption of "Admin Interface for the OSCORE Group Manager"[1]. Please state 
your opinion by July 6 2020 whether the WG should adopt or not this document.

Yours,
Jim and Daniel

[1] https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/

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

Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt)

[Francesca Palombini]

Hi Carsten,

Thanks for this quick update! Just some short high level comments, to make sure 
we can use this for ace-key-groupcomm-oscore.

In ace-key-groupcomm-oscore, we would say that Toid is the identifier of the 
OSCORE group, so the OSCORE "group name", which is encoded as a bstr. For 
Tperm, it's a bit further away from what the aif document specifies (which is 
why I want to check with you), but we would go for array of tstr, since we 
can't really encode the permission to be a "monitor" node (for example) by 
indicating a REST method. This is a bit stretched from the document right now, 
but it should work.

We would have to register a media type (and content format) for this, so what 
would this be? You use aif+cbor for the default, so maybe something like 
"aif-ace-group+cbor". For section 5.3, we would have to register Toid and Tperm 
with something like:

Toid registry:
* name: gname
* description: group name of the OSCORE group as specified in 
ace-key-groupcomm-oscore

Tperm registry:
* name: roles
* description: role of the group member as specified in ace-key-groupcomm-oscore

I think we are missing some form of "encoding" column in the registries above. 
In that case it would be "bstr" for Toid gname and "CBOR array of tstr" for 
Tperm role. It would also be "tstr" for local-part Toid and "int" for Tperm 
REST-method-set. (also, minor, but you sometimes use "local-part" and sometimes 
"local-uri", see section 4). Even better, the description or the encoding in 
the registry could point to "path" and "permissions" cddl, for the default 
values in the aif doc.

Using "array of tstr" for roles allows us to express what we need for "set of 
roles". I don't see this being in contrast with the aif document right now.

So all in all, I think this can work for ace-key-groupcomm-oscore. Please let 
me know if you see anything that bothers you in my summary.

Thanks,
Francesca 

On 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann"  wrote:

I went ahead and quickly implemented what we had discussed today.

https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html

Lots more editing to do, but the gist of what I was trying to say should be 
there.
Comments welcome!

Grüße, Carsten


> On 2020-06-23, at 00:12, 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   : An Authorization Information Format (AIF) for ACE
>Author  : Carsten Bormann
>   Filename: draft-bormann-core-ace-aif-08.txt
>   Pages   : 9
>   Date: 2020-06-22
> 
> Abstract:
>   Constrained Devices as they are used in the "Internet of Things" need
>   security.  One important element of this security is that devices in
>   the Internet of Things need to be able to decide which operations
>   requested of them should be considered authorized, need to ascertain
>   that the authorization to request the operation does apply to the
>   actual requester, and need to ascertain that other devices they place
>   requests on are the ones they intended.
> 
>   To transfer detailed authorization information from an authorization
>   manager (such as an ACE-OAuth Authorization Server) to a device, a
>   representation format is needed.  This document provides a suggestion
>   for such a format, the Authorization Information Format (AIF).  AIF
>   is defined both as a general structure that can be used for many
>   different applications and as a specific refinement that describes
>   REST resources and the permissions on them.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-bormann-core-ace-aif-08
> https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-bormann-core-ace-aif-08
> 
> 
> 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/
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Ace mailing list
Ace@ietf.org

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-11.txt

[Francesca Palombini]

Hi,

We have just submitted v-11 of the OSCORE profile. With this update, a couple 
minor clarifications that came as comments from OCF are included, and the text 
about update of access rights agreed during the last interim is also added.

Comments are welcome.
Thanks,
Francesca

On 18/06/2020, 23:53, "Ace on behalf of 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   : OSCORE profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-11.txt
Pages   : 31
Date: 2020-06-18

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security, server authentication,
   and proof-of-possession for a key owned by the client and bound to an
   OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-11
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-11


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] Review of ietf-ace-key-groupcomm-07

[Francesca Palombini]

Hi Jim,

Thanks for your reply! Comments inline.

Francesca





On 16 July 2020 at 23:01:47 CEST, Jim Schaad  wrote:


> -Original Message-
> From: Francesca Palombini 
> Sent: Tuesday, July 14, 2020 2:25 PM
> To: Jim Schaad ; draft-ietf-ace-key-
> groupc...@ietf.org
> Cc: ace@ietf.org
> Subject: Re: Review of ietf-ace-key-groupcomm-07
>
> Hi Jim,
>
> Thank you so much for another extensive review! We have submitted v-08 of
> the draft to answer it.
> Comments inline. If there is any answer/update that does not satisfy you,
> hopefully we can continue the discussion by mail and figure out the major
> points to discuss during IETF108.
>
> Thanks,
> Francesca and Marco
>
> On 26/06/2020, 06:02, "Jim Schaad"  wrote:
>
>
> * Section 2 - update DTLS reference
>
> FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no profile
> defined to set up DTLS 1.3, so I don’t think we should update to 1.3 here.

[JLS] Fine - but be prepared for pushback from the IESG on this.

FP: A possible alternative is to rephrase to mention the profiles rather than 
the protocols. For example:

OLD:
“Possible ways to provide a secure communication association are DTLS [RFC6347] 
and OSCORE [RFC8613].”

NEW:
“Possible ways to provide a secure communication association are described in 
the DTLS transport profile [I-D.ietf-ace-dtls-authorize] and OSCORE transport 
profile [I-D.ietf-ace-oscore-profile] of ACE.”

Would that be better?

>
> * Section 3 - The content format application/ace+cbor is not defined by 
> the
> transport profiles but by the framework.
>
> FP: The point is that the profiles might change the content format, so even if
> this specific one ace+cbor is defined in Ace, profiles might define and use 
> other
> ones. Rephrased to clarify.

[JLS] No, the profile can dictate the media type between C and RS, but between 
C and AS is set by the framework.

FP: Ah, I see what you mean. I checked again in the framework, and to be 
nitpicking it does says “Profiles that use CBOR encoding of protocol message 
parameters at the
outermost encoding layer MUST use the media format 'application/
ace+cbor'. So in some sense the content-format depends on if the profile uses 
CBOR or not. That does not change the fact that we need to rephrase our text 
here to be completely correct.

OLD:
The Content-Format
used in the message is the one indicated by the used transport
profile of ACE. For example, ...
NEW:
The Content-Format
used in the message depends on the used transport
profile of ACE. For example, ...


>
> * Section 3.1 - Given that a role is defined as a tstr, that format is not
> usable if one wishes to assign an integer abbreviation per OPT7.
>
> FP: I tried to reformulate here that the aif is the default encoding, and 
> specify
> that the other format defined is an example. In the end it is up to the
> application profile to specify the format of scope.

Sure, but why not express figure 4 in terms of AIF rather than as something 
that looks like a new structure?

FP: We can do that, we will port the example from the OSCORE application 
profile (the one in section 3 of 
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-08 ).


>
> * Section 3.1 - Is there a reason that a gid is a bstr and not a tstr.  I
> assume that this is the same as GROUPNAME which much be a text string to
> be
> in a url-path.
>
> FP: We have modified that to be tstr to be consistent with ace key groupcomm
> oscore, but please note this is only an example.

[JLS] Yes I know it is an example, but the gname cannot be anything other than 
a tstr unless you are going to completely break the connection between this 
value and the name in the URI.

FP: This is a good point, we might want to specify that if it’s not a tstr 
there needs to be something in place to make the translation between the group 
name and GROUPNAME used in the URI (ex: bstr gets translated into tstr 0x0123 
becomes “0123”)


> * Section 3.2 - the def of scope seems odd because it is not well defined 
> if
> it would be the same as the requested scope. (AS response)
>
> FP:  I need more clarifications: Is it the following that is strange “'scope'
> containing the granted scope, if different from the scope requested by the
> client. “ ? Note that the terminology “requested and granted scope” comes
> from OAuth: https://tools.ietf.org/html/rfc6749#section-3.3. I removed the
> second part of the sentence as per comment below.

[JLS] What seems odd is that if it is absent, then it is not clear what the 
grants are.  I don't know if you need to specify that the grant is the same as 
the request when it is not present.  On the other hand this is duplicating 
information in the framework document.

FP: Yes, that was the idea, t

Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif

[Francesca Palombini]

Hi,

I support adoption of this document, and believe Ace should adopt it. I am 
willing to review, but I don't have any implementation plans.

Thanks,
Francesca

On 15/07/2020, 22:52, "Ace on behalf of Jim Schaad"  wrote:

I had been holding off doing an adoption call waiting for a formal request
to adopt it.  However, given that this is now a dependency for three
different WG documents I think we need to do this now.

Adoption call for
https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ 

This document provides a template for an authorization information format
(AIF) using a CDDL generic.  Questions to be answered:

1.  Do you think the ACE WG should adopt this document?  If not please
provide some reasoning.

2.  If adopted are you willing to review the document?

3.  Would you have any implementation plans?  Currently this is referenced
by the MQTT-TLS document, the Group KDC documents.

Adoption call ends on July 28.

Jim & Daniel


___
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] WGLC draft-ietf-ace-oscore-profile-13.txt

[Francesca Palombini]

Hi Marco,

Thanks, very helpful as always! I have implemented all the comments in this PR 
https://github.com/ace-wg/ace-oscore-profile/pull/44 , if you give me the OK I 
can merge and upload a new submission. Happy to see that the comments were 
about clarifications and editorials.

Inline detailed answers.

Thanks again!
Francesca

From: Marco Tiloca 
Date: Thursday, 19 November 2020 at 17:04
To: , Ace Wg 
Subject: Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt
Resent from: 
Resent to: Francesca Palombini , 
, Göran Selander , 

Resent date: Thu, 19 Nov 2020 08:03:54 -0800 (PST)

Hello OSCORE profile authors and ACE,

Please, find below some WGLC comments. Hope it helps!

Best,
/Marco



Section 1

* s/is not done by a/is not achieved through a

FP: Ok, fixed.

* s/after the first OSCORE exchange/after the first message exchange
using OSCORE

FP: Ok, fixed.

Section 2

* "This specific identifier, encoded as a byte string, is assigned by
the AS to be unique in the sets of its OSCORE Security Contexts ..."

   To avoid confusion, it's probably better to say "unique among the
issued sets of OSCORE input material", since the AS can have actual
OSCORE Security Contexts it uses to communicate with Clients or Resource
Servers.

FP: Ok, fixed. Replaced with OSCORE security input materials

* Referring to 'id' as specific identifier, the text says: "and is not
used as input material to derive the full OSCORE Security Context."

   That's correct, but then the identifier is later included in Table 1
"OSCORE_Input_Material Parameters" :-)

   Perhaps it's fine to just revert to OSCORE_Security_Context_Object,
both for the name of Table 1 and in different spots of the text? They
would still consider 'id' as OSCORE Input Material Identifier, while
aligned with the registry name from Section 9.4.

FP: I see your point, but the name was source of discussion before and I'd 
rather not go back on that. I don't think it is a problem that the 'id' is both 
part of the "OSCORE_Input_Material" object and also not part of the actual 
input material. After all it needs to be part of the object to identify it. 
What I did is to change its CBOR label though, to have it as 0, since I think 
that makes more sense that to be in the middle of other input materials. Note 
that this is a change that will affect implementations.

* s/If the request verifies/If the request is successfully verified

FP: Ok, fixed.

* s/until token expiration/until token deletion, due to e.g. expiration
or revocation

FP: thanks for this comment. I did only keep expiration as example,

* s/the same or different/the same or a different one

FP: Ok, fixed.

* Figure 1 can also show the achievement of mutual authentication,
following the OSCORE exchange at the end

FP: Good point, added.


Section 3.1

* s/object. kid field carrying/object, with the kid field carrying

FP: Ok, fixed.

Section 3.2

* "... profile negotiation can be omitted" - I think "profile signaling"
better reflects what may happen here, see also the beginning of the
paragraph.

FP: Ok, fixed.

* s/in the the/in the

FP: Ok, fixed.

* s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token

FP: Ok, fixed.

Section 3.2.1

* In the text entries following Table 1, the CBOR integer labels need to
be aligned with the CDDL summary at the end of the section.

FP: I think it was? Now I moved id to index 0, so I switched the order there 
too.

* s/This parameter identifies the OSCORE_Input_Material/This parameter
identifies the OSCORE_Input_Material object

FP: I will let the RFC editors decide on that one :) Don't want to become too 
verbose if it's not needed.

* s/the "id" type is byte string/the "id" type is bstr

FP: ah, good point. I actually changed all the description to extend the type 
(so byte string instead of bstr, etc), in order not to use CDDL in text.

* This version -13 has removed 'clientId' and 'serverId' from Table 1
and thus as code points from the "OSCORE Security Context Parameters"
registry.

  No strong need to include them back, but even if this profile does not
use them and does not send them on the wire, I think they still belong
to the same namespace, since they are descriptive of a security context
and are in fact also used as input material to derive it :-)
FP: I agree with that, and think the first draft to use them will register 
them. The registration of the OSCORE_Input_Material does not specify how this 
material is used, that is up to the draft describing the derivation process, so 
it does not make sense to register them here without explaining the derivation 
process using those parameters.

Section 4

* s/the RS and client authenticates themselves/the RS and client
authenticate each other

FP: Ok, fixed.
* s/successfully verified the response from the RS/successfully verified
a response from the RS as protected with the establis

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-14.txt

[Francesca Palombini]

Hi all,

This update answers Marco's latest review (thanks Marco!), answering all 
comments received as WGLC.

Thanks,
Francesca

On 14/12/2020, 09:49, "Ace on behalf of 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   : OSCORE Profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-14.txt
Pages   : 33
Date: 2020-12-14

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security and proof-of-possession
   for a key owned by the client and bound to an OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-14
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-14


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-oscore-profile-14.txt

[Francesca Palombini]

Ah, of course, they are indeed out of sync, thank you for noticing! I am fixing 
it already in the github, but I am thinking of waiting for Daniel's go ahead 
before submitting one more version, see if he wanted to review one last time.

Francesca

On 14/12/2020, 16:32, "Benjamin Kaduk"  wrote:

Thanks, Francesca!

It looks like the CBOR label values have gotten out of sync between Table 1
and the prose.  (The IANA Considerations just refer to Table 1, so I think
that Section 3.2.1 is the only thing that needs to be kept in sync.)

-Ben

On Mon, Dec 14, 2020 at 09:58:21AM +, Francesca Palombini wrote:
> Hi all,
> 
> This update answers Marco's latest review (thanks Marco!), answering all 
comments received as WGLC.
> 
> Thanks,
> Francesca
> 
> On 14/12/2020, 09:49, "Ace on behalf of 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   : OSCORE Profile of the Authentication and 
Authorization for Constrained Environments Framework
> Authors : Francesca Palombini
>   Ludwig Seitz
>   Göran Selander
>   Martin Gunnarsson
>   Filename: draft-ietf-ace-oscore-profile-14.txt
>   Pages   : 33
>   Date: 2020-12-14
> 
> Abstract:
>This memo specifies a profile for the Authentication and
>Authorization for Constrained Environments (ACE) framework.  It
>utilizes Object Security for Constrained RESTful Environments
>(OSCORE) to provide communication security and proof-of-possession
>for a key owned by the client and bound to an OAuth 2.0 access 
token.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-14
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-14
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-14
> 
> 
> 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

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

Re: [Ace] Call for agenda item for IETF 109

[Francesca Palombini]

Hi Daniel,

We’d like to request 15 minutes to discuss updates on ace-key-groupcomm at 
IETF109.

Thanks,
Francesca

From: Ace  on behalf of Daniel Migault 

Date: Tuesday, 13 October 2020 at 18:33
To: Ace Wg 
Subject: [Ace] Call for agenda item for IETF 109

Hi,

The Ace WG will meet during IETF 109. If you are willing to present, please let 
me know by the end of the month what you are willing to present and the 
necessary time you need.

Yours,
Daniel

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

Re: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-02.txt

[Francesca Palombini]

Hi all,

This is a keep-alive update. It also adds Cigdem as co-author of the document 
who is going to especially help with the MQTT parts of the document (to come).

Francesca

On 03/01/2021, 23:23, "Ace on behalf of 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   : Pub-Sub Profile for Authentication and 
Authorization for Constrained Environments (ACE)
Authors : Francesca Palombini
  Cigdem Sengul
Filename: draft-ietf-ace-pubsub-profile-02.txt
Pages   : 21
Date: 2021-01-03

Abstract:
   This specification defines an application profile for authentication
   and authorization for publishers and subscribers in a pub-sub setting
   scenario in a constrained environment, using the ACE framework.  This
   profile relies on transport layer or application layer security to
   authorize the publisher to the broker.  Moreover, it relies on
   application layer security for publisher-broker and subscriber-broker
   communication.


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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ace-pubsub-profile-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-pubsub-profile-02


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-oscore-profile-16.txt

[Francesca Palombini]

This is a minor update, which implements a minor clarification described here: 
https://mailarchive.ietf.org/arch/msg/ace/IxrbGjbAPH7RSB5IUMEF1UI5gQc/

Francesca

On 28/01/2021, 17:38, "Ace on behalf of 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   : OSCORE Profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-16.txt
Pages   : 33
Date: 2021-01-28

Abstract:
   This memo specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security and proof-of-possession
   for a key owned by the client and bound to an OAuth 2.0 access token.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-16
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-16


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] Francesca Palombini's Yes on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

[Francesca Palombini]

Hi Olaf, Steffi,

My turn to apologize for the late reply :) I went through the comment again and 
I believe I must have misread something. I am ok with the current text, or the 
previous one as well, if you'd rather not add this sentence.

I do have one additional comment, which came out while looking this over again 
- about the following text:

   correct public key in the DTLS handshake.  If the authorization
   server has specified a "cnf" field in the access token response, the
   client MUST use this key.  Otherwise, the client MUST use the public

The access token is opaque to the client (as defined the ace framework), so the 
client is not necessarily able to read and extract the key it is supposed to 
use from it. If I am not mistaken, the correct way for the AS to tell the 
client what key to use would be to use the "cnf" field defined in Section 3.2 
of oauth-params.

Francesca

On 27/05/2021, 13:25, "Olaf Bergmann"  wrote:

Hi Francesca,

Did you have chance to take another look at comment #3 of your review
(see below)?

Grüße
Olaf


On 2021-05-11, Stefanie Gerdes  wrote:

    >
    > On 3/24/21 4:49 PM, Francesca Palombini via Datatracker wrote:
>> 
>> --
>> COMMENT:
>> --
>> 
>> 3. --
>> 
>>raw public keys, it needs to determine which key to use.  The
>>authorization server can help with this decision by including a "cnf"
>>parameter in the access token that is associated with this
>>communication.  In this case, the resource server MUST use the
>> 
>> FP: The example in Figure 4 show how the whole RPK of the client can be
>> included in the access_token, so maybe this paragraph should cover that 
case,
>> or the example changed.
>
> I am not quite sure if I understand your comment. In Figure 4, the
> contents of the access token is omitted for brevity. The response
> contains access information for the client with the server's RPK in
> the rs_cnf parameter. This is required by the client to authenticate
> its peer during the DTLS handshake. We changed the example paragraph
> so that it now explains the use of the rs_cnf parameter. Does that
> make it more clear?

The new text we have included reads:

"The response comprises access information for the client that contains
the server's public key in the rs_cnf parameter."

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

Re: [Ace] Francesca Palombini's Yes on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

[Francesca Palombini]

Hi Olaf,

Right! Somehow I managed to miss the « response » from the « access token 
response ».

Thanks for the answers, it all looks good to me and ready to ship.

Francesca





On 8 June 2021 at 11:59:19 CEST, Olaf Bergmann  wrote:
Hi Francesca,

On 2021-06-08, Francesca Palombini  wrote:

> My turn to apologize for the late reply :) I went through the comment
> again and I believe I must have misread something. I am ok with the
> current text, or the previous one as well, if you'd rather not add
> this sentence.

Thanks for the followup — we have kept the new text in version -18.

> I do have one additional comment, which came out while looking this over 
> again - about the following text:
>
>correct public key in the DTLS handshake.  If the authorization
>server has specified a "cnf" field in the access token response, the
>client MUST use this key.  Otherwise, the client MUST use the public
>
> The access token is opaque to the client (as defined the ace
> framework), so the client is not necessarily able to read and extract
> the key it is supposed to use from it. If I am not mistaken, the
> correct way for the AS to tell the client what key to use would be to
> use the "cnf" field defined in Section 3.2 of oauth-params.

You are correct. That is basically what this text says (= if the AS has
provided the cnf in its response, the client has to use it).

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)

[Francesca Palombini]

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.

>8. -
>
>  While the structure and encoding of the access token varies
>  throughout deployments, a standardized format has been defined
>  with the JSON Web Token (JWT) [RFC7519] where claims are encoded
>  as a JSON object.  In [RFC8392], an equivalent format using CBOR
>  encoding (CWT) has been defined.
>
>FP: Would it make sense to RECOMMEND the use of JWT when HTTP is used? Or is
>CWT always RECOMMENDED?
>
>LS: I'd rather avoid making general recommendations here, I believe this is 
>best handled in the profiles.
>

FP: Ok.

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

>
>11. -
>
>   The OAuth 2.0 AS uses a JSON structure in the payload 

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

[Francesca Palombini]

Hi all,

This is my official "Ok" for that point. Thanks.

I still have the following point open from the mail exchange with Ludwig, to 
which I hadn't replied (all other points are good). CC Cigdem, Carsten and 
Göran as they participated in the discussion.

6.7.  Combining Profiles

   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.

My original comment and Ludwig's replies:

>FP: This seems strange - maybe I just don't understand how this is 
>supposed to work, but each profile defines exactly at least C - RS 
>communication and security, if several are combined, it seems that at 
>least the C-RS would conflict.
>
>LS: You could use one profile for C-RS (e.g. MQTT) and another one for C-AS 
>(e.g. DTLS) in the same interaction. So the writer of e.g. the DTLS profile 
>MUST NOT make security assumptions that this profile is used on _every_ leg of 
>the communication.
>

FP: Ok, I see, you mean that the C-RS interaction uses for example one profile, 
while the C-AS uses another? I am not convinced this text is enough - first of 
all you'd have to make sure that the profiles are "combinable" - the OSCORE 
profile for example requires the security context to be derived, and simply 
using another profile without tweaking it would not be enough. Additionally, I 
am confused about the implications for implementers to mix and match different 
profiles for different legs of communication, this sounds like interoperability 
could be an issue. Can we discuss this more?

LS: I don't really see the problem here. Say you have a client that uses DTLS 
to talk to the AS. The AS determines that the client should use the OSCORE 
profile to talk to the RS and prepares the token accordingly (including the 
OSCORE parameters in the cnf claim of the token and the cnf parameter of the 
response). The client is informed of the chosen profile with the 'profile' 
parameter and proceeds to derive the OSCORE context for client-RS communication.

We discussed this during the May interim: 
https://datatracker.ietf.org/doc/minutes-interim-2021-ace-08-202105111000/ 
However the minutes don't capture the whole discussion so I suggest you listen 
to the recording to catch up (and I am sorry I was indeed delayed and breaking 
up): https://youtu.be/Cp5P2q78iVY?t=823 . 13:43 I try to explain what problem I 
have with the section; 16:20 the discussion starts; 27:40 the conclusion 
starts; 31:40 we move on.

To summarize my understanding - we agreed that the Section 6.7 was unclear.
* The first sentence is confusing in the sense that it is not clear what 
"combining profiles" mean. The way MQTT interprets it: different transport and 
security protocols can be used in different legs. Profiles MUST specify how 
that works (as for example MQTT allows for CoAP and CBOR to be used, and 
defines how).
* The last sentence is problematic because a profile cannot guess all profiles 
that will be defined afterwards and make sure they could interoperate.

So my suggestion for this section is 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 were different transport and security protocols
   are allowed for the different interactions, and that corresponds to 
combining profiles.
   For example, a new profile could define 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.
   

I hope this helps,
Francesca

On 05/07/2021, 13:59, "Ludwig Seitz"  wrote:

Hello,

I am waiting for an "OK" from Francesca, since the change was originally 
related to her IESG DISCUSS.

/Ludwig

-Original Message-
From: Stefanie Gerdes  
Sent: den 5 juli 2021 13:27
To: Carsten Bormann ; Daniel Migault 
Cc: ace-cha...@ietf.org; Ludwig Seitz ; 
art-...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; The IESG 
; Seitz Ludwig ; ace@ietf.org; 
Francesca Palombini 
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's D

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

[Francesca Palombini]

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] [Russ Mundy] Re: secdir review of draft-ietf-ace-dtls-authorize-14

[Francesca Palombini]

Hi,

I am fine with Daniel's change to the DTLS profile (which wants to add 
motivation on why the DTLS profile is RECOMMENDED), and prefer Göran's 
formulation to the Ace framework. 

I had to think about it and figured out where the different interpretations 
come from, and hence what needs to be clarified:

"Profiles MUST specify a communication security protocol that provides
   the features required above."

Russ reads this sentence as: one (and only one) protocol MUST be specified *and 
used* between Client and AS.
I (and others) read this sentence as: (at least) one protocol fulfilling the 
security requirements MUST be specified in the profile. (and as a consequence: 
One and only one of these protocols specified in the profile MUST be used 
between client and AS)

I think Göran's modification clarifies the above, but hopefully Russ can let us 
know how to make his even clearer.

Francesca

On 11/02/2021, 12:35, "Stefanie Gerdes"  wrote:


On 02/11/2021 04:26 AM, Daniel Migault wrote:

> 
> OLD: section 6.2
>  "Profiles MUST specify how communication security according
>to the requirements in Section 5 is provided."
> NEW:
> section 6.2 is focused on security but the security requirements are
> provided in section 5. We may simply remove this sentence.
> 
> OLD section 5.
> "Profiles MUST specify a communication security protocol that provides
>the features required above."
> NEW:
> Profiles MUST provide some recommendation on protocols used to establish
> these communications.
> These communications MUST meet these security requirements. As
> communications meeting these requirements may be established in multiple
> ways, profiles MUST provide some recommendations as to favor
> interoperability. In most cases the recommendations aim at limiting the
> number of libraries the client has to support.
> 

The reason that this requirement on the profiles was included in the
framework is that the framework itself does not specify how
communication security is provided. For the security of the solution it
is important that the profiles fill this gap. I think that it is
important to emphasize this security requirement. I therefore prefer
Goeran's proposals:

Proposal 1 (Section 6.2):
OLD
  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
NEW
"The requirements for communication security of profiles are specified
in Section 5."

Proposal 2 (Section 5):
OLD
"Profiles MUST specify a communication security protocol that provides
   the features required above."
NEW
"Profiles MUST specify at least one communication security protocol that
provides the features required above."


Viele Grüße
Steffi

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

Re: [Ace] draft-ietf-ace-dtls-authorize

[Francesca Palombini]

Hi Olaf,

When I read the draft I don't see how the change is reflected in your summary, 
actually your summary shows no difference between OSCORE and DTLS profile, 
while actually there is one. This is the difference we are discussing in the 
DTLS profile, about secure communication between Client and Authorization 
Server:

1. DTLS OLD:
   The use of CoAP
   and DTLS for this communication is RECOMMENDED in this profile, other
   protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be
   used instead.

2. DTLS CURRENT:
  The use of CoAP
   and DTLS for this communication is REQUIRED in this profile.  Other
   protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will
   require specification of additional profile(s).

3. OSCORE CURRENT:
The
   use of CoAP and OSCORE ([RFC8613]) for this communication is
   RECOMMENDED in this profile; other protocols fulfilling the security
   requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such
   as HTTP and DTLS or TLS) MAY be used instead.

3. allows for applications to use this OSCORE profile "coap_oscore" and OSCORE 
between C and AS, but also if they prefer, DTLS between C and AS, or other 
security protocols that fulfil the security requirements of the framework.
1. also allows for the same for the DTLS profile (although it might be good to 
clarify that other protocols are only allowed if they fulfil the sec 
requirements).
2. does NOT allow for "coap_dtls" to use anything else than DTLS between C and 
AS. If C and AS want to use e.g. TLS, a new profile needs to be defined. This 
doesn't seem like a good idea.

About the "need to look somewhere else" : the only thing we say in the profiles 
is that C and AS have to have set up a secure communication channel. That is 
not really protocol specific, how that is established is out of scope of the 
profiles.

The question is: do we really need to specify one different profile for each 
security protocol used between C and AS? I hope not.

So my preference would update the text in the DTLS profile:

NEW:
   The use of CoAP
   and DTLS for this communication is RECOMMENDED in this profile, other
   protocols fulfilling the security
   requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be
   used instead.

Francesca

On 28/01/2021, 18:11, "Ace on behalf of Olaf Bergmann"  wrote:

Hi Daniel,

On 2021-01-28, Daniel Migault 
 wrote:

> Apparently, the change on the DTLS profile has not been noticed by
> everyone in the WG, so I am bringing the discussion here.
>
> The change has been made as a response to a comment from the security
> directorate. Please provide your feed backs by Feb 4 (but preferably
> before)- and potentially propose the text you would like to see if you
> disagree with the change.

I agree with the change (although I do not care very much but the new
text makes more sense than the old) because the change suggested in the
secdir review is not about mandating one protocol or the other. It is
about which protocol you need to implement if you want to use that
protocol between C and AS. In short:

* the OSCORE profile mandates that "if you want to use CoAP over OSCORE
  between the C and the AS, you need to follow the steps in the
  OSCORE specification and look somewhere else if you want to use
  another protocol", and
* the DTLS profile mandates that "if you want to use CoAP over DTLS
  between the C and the AS, you need to follow the steps in the
  DTLS specification  and look somewhere else if you want to use
  another protocol"

Grüße
Olaf

___
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] [EXTERNAL] Francesca Palombini's No Objection on draft-ietf-ace-oauth-params-13: (with COMMENT)

[Francesca Palombini]

Hi Ludwig,

Thanks for the quick reply! Both updates sound good and address my comments. 

Francesca

On 25/03/2021, 08:22, "Seitz Ludwig"  wrote:

Hello Francesca,

Thank you for your review. I have some comments inline.

/Ludwig

> --
> COMMENT:
> --
> 
> Thank you for this document. A couple of minor comments below.
> 
> Francesca
> 
> 1. -
> 
>   better symmetric keys than a constrained client.  The AS MUST
>   verify that the client really is in possession of the
>   corresponding key.  Values of this parameter follow the syntax and
> 
> FP: I think it would have been helpful to give some details about how 
this is
> done "by verifying the signature ..." or a reference to where this is 
described.
>
I believe this would expand the scope of this document in a way I'd rather 
leave to the profiles.
The AS can verify possession of a key in various ways, some of which may be 
provided by the 
security protocol used between the client and the AS, which in turn would 
be defined in the profiles.

Would you be ok with the following addendum: "Profiles of [framework] using 
this specification MUST define the proof-of-possession method used by the AS, 
if they allow clients to request the use of asymmetric keys as 
proof-of-possession key."? 


> 2. -
> 
>parameters.  An RS MUST reject a proof-of-possession using such a
>key.
> 
> FP: Is any error message supposed to be sent in such a case?

I suggest to update to add a 4.00 (Bad Request) here.


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

[Francesca Palombini]

Ludwig,

Thank you for the quick reply, and for the useful background information.

As I said, I think this document is important and should move forward asap, and 
it can do so without changing the main assumptions, with some additional 
clarifications in the text about CBOR vs "other" when HTTP is used (which in my 
opinions are necessary - see points 1, 8, 10, 11, 13, 15, 17, 22, 23, 26, 28).

What I wanted to highlight is that it would simplify the document a lot to just 
remove this flexibility, for which I don't understand the motivation, and say 
"CBOR is mandatory" even when HTTP is used. The flexibility could be added in a 
future document if needed. However, I understand that there is history in the 
working group, and I will step back and remove my DISCUSS if I am in the rough. 
Note however that in terms of work on the document I suspect that keeping this 
flexibility will require more work, not less.

Looking forward to discussing this with Ben during the telechat.
Francesca

On 25/03/2021, 08:50, "iesg on behalf of Seitz Ludwig"  wrote:

Hello Francesca,

Thank you for your review. I will address your detailed comments 
separately, with regards to your DISCUSS:

The option to allow both HTTP and JSON for any leg of the communication 
(client-AS, rs-AS, client-rs) was the result of long discussions in the WG. If 
I recall correctly the intent was to allow legacy OAuth 2.0 equipment (i.e. not 
supporting ACE) to be used in ACE interactions on those legs of the 
communication where no constrained devices are involved.
I am reluctant to reopen these discussions at this point in time, and I 
suspect doing the necessary analysis to provide in-depth considerations on the 
choices between HTTP/CoAP and JSON/CBOR will significantly delay the progress 
of this document.

@ace-chairs: What is your suggestion on how to best handle this?
(Please note that I am unable to commit significant amounts of time to this 
work in the foreseeable future)

Regards,

Ludwig


> -Original Message-----
> From: Ace  On Behalf Of Francesca Palombini via
> Datatracker
> Sent: den 24 mars 2021 15:50
> To: The IESG 
> Cc: art-...@ietf.org; ace-cha...@ietf.org; draft-ietf-ace-oauth-
> au...@ietf.org; ace@ietf.org
> Subject: [EXTERNAL] [Ace] Francesca Palombini's Discuss on draft-ietf-ace-
> oauth-authz-38: (with DISCUSS and COMMENT)
> 
> Francesca Palombini has entered the following ballot position for
> draft-ietf-ace-oauth-authz-38: Discuss
> 
> When responding, please keep the subject line intact and reply to all 
email
> addresses included in the To and CC lines. (Feel free to cut this 
introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/
> 
> 
> 
> --
> DISCUSS:
> --
> 
> Thank you for this document. I think this is an important document which
> should move forward, but I would like to discuss some points before it 
does
> so. These might result in simple clarifications, or might require more
> discussion, but I do hope they help improve the document.
> 
> General comments:
> 
> I found confusing to understand how optional or mandatory is the use of
> CBOR for profiles of this specification compared to the transport used. I
> understand the need for flexibility, but maybe it should be clarified the
> implication of using CoAP (is CBOR mandatory then?) vs HTTP (is CBOR 
always
> permitted? How is the encoding in that case? Is the same media type
> application/ace+cbor used in that case?). Note also that while requests
> include the content type to use, both in case HTTP or CoAP+CBOR are used,
> the response don't seem to include this information.
> 
> I would like it to be clarified what requirements (or even just
> recommendations) are there to use CoAP vs HTTP for different legs of the
> exchange - not necessarily remove the flexibility but to clarify for
> implementers what can be done and what would be the reasoning to do
> that: for example if both endpoints support HTTP with the AS, most likely 
you
> can have HTTP between C and RS, so does it really make sense to run this
> instead of OAuth 2.0? Right now all is permitted, but does it all make 
sense? I
> feel like this t

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

[Francesca Palombini]

Hi Cigdem, 

I just quickly scanned the MQTT profile, and noticed that for example the C-AS 
interaction defined in the MQTT-TLS profile (using a new media type 
"application/ace+json") do not map with what is currently defined in the ACE 
framework (which maps more closely to what OAuth 2.0 does, using 
"application/x-www-form-urlencoded" format with a character encoding of UTF-8 
in the HTTP request entity-body for example for the C-AS request).

My comment on point 13. is that: right now I read the framework as "it requires 
CBOR" for this exchange, and I agree with you this didn't seem to go with the 
rest of the specification - I was not requesting CBOR to be made mandatory, on 
the contrary I was pointing out an inconsistency within the document.

To re-iterate: I am ok with keeping a different encoding than CBOR in, but I do 
believe it needs clarification in the document. Also I did not suggest to 
remove HTTP from the specification.

Hannes - could you please remind me the substance of the discussion and the 
motivations for having this flexibility on encoding? Ludwig mentions "to allow 
legacy OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE 
interactions on those legs of the communication where no constrained devices 
are involved." I feel like it would not be hard for OAuth2.0 ASes to support 
CBOR, they would need to support more processing defined by the Ace framework 
anyway.. Again, as I said several times, I am ok with stepping back, I just 
wanted to make sure I understood the motivation for a discussion which I 
haven't followed closely.

Francesca

On 25/03/2021, 15:10, "Cigdem Sengul"  wrote:

Hello,
I would like to add my two cents to this as the MQTT-TLS profile does use
HTTP/JSON for client-AS and rs-AS communication as similar already was
supported in MQTT implementations between an MQTT broker and external
servers (e.g., via auth plug-ins).

For points like 13: Making CBOR mandatory would break how it is implemented
for MQTT-TLS, which implements the AS creation hints as a User Property
inside an MQTT message.
"The User Property is a UTF-8 string pair, composed of a name and a value.
The name of the User Property MUST be set to
   "ace_as_hint".  The value of the user property is a UTF-8 encoded
   JSON string containing the mandatory "AS" parameter, and the optional
   parameters "audience", "kid", "cnonce", and "scope" as defined in
   Section 5.1.2 of the ACE framework"

Kind regards,
--Cigdem



On Thu, Mar 25, 2021 at 1:53 PM Francesca Palombini  wrote:

> Ludwig,
>
> Thank you for the quick reply, and for the useful background information.
>
> As I said, I think this document is important and should move forward
> asap, and it can do so without changing the main assumptions, with some
> additional clarifications in the text about CBOR vs "other" when HTTP is
> used (which in my opinions are necessary - see points 1, 8, 10, 11, 13, 
15,
> 17, 22, 23, 26, 28).
>
> What I wanted to highlight is that it would simplify the document a lot to
> just remove this flexibility, for which I don't understand the motivation,
> and say "CBOR is mandatory" even when HTTP is used. The flexibility could
> be added in a future document if needed. However, I understand that there
> is history in the working group, and I will step back and remove my 
DISCUSS
> if I am in the rough. Note however that in terms of work on the document I
> suspect that keeping this flexibility will require more work, not less.
>
> Looking forward to discussing this with Ben during the telechat.
> Francesca
>
> On 25/03/2021, 08:50, "iesg on behalf of Seitz Ludwig" <
> iesg-boun...@ietf.org on behalf of ludwig.se...@combitech.se> wrote:
>
> Hello Francesca,
>
> Thank you for your review. I will address your detailed comments
> separately, with regards to your DISCUSS:
>
> The option to allow both HTTP and JSON for any leg of the
> communication (client-AS, rs-AS, client-rs) was the result of long
> discussions in the WG. If I recall correctly the intent was to allow 
legacy
> OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE
> interactions on those legs of the communication where no constrained
> devices are involved.
> I am reluctant to reopen these discussions at this point in time, and
> I suspect doing the necessary analysis to provide in-depth considerations
> on the choices between HTTP/CoAP and JSON/CBOR will significantly delay 
the
> progre

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

[Francesca Palombini]

Oh, sorry - I see point 13. I reference got cut from the mail thread... I got 
that impression from the AS Request Creation Hints message. From my review:

13. -

   valid access token.  The AS Request Creation Hints message is a CBOR
   map, with an OPTIONAL element "AS" specifying an absolute URI (see

FP: another case where CBOR seem mandatory.. Is this the case, even if HTTP or 
other protocol is used?

Thank you, that would be useful. Links to mail threads and/or your recalled 
summary are much appreciated.
Francesca

On 25/03/2021, 16:36, "Hannes Tschofenig"  wrote:

Hi Francesca,

CBOR is used in different places throughout the document. There are several 
different interfaces (C<->AS, C<->RS, RS<->AS and also the token encoding 
itself).

For which part does the document give you the impression that CBOR is 
mandatory?

Ciao
Hannes

PS: I will dig out discussion with the OAuth group on the issue of PoP 
tokens and how to request a PoP token with HTTP over the client-to-AS interface 
to then present it via a different transport to the RS.

    -Original Message-
From: Francesca Palombini 
Sent: Thursday, March 25, 2021 3:59 PM
To: Cigdem Sengul ; Francesca Palombini 
; Hannes Tschofenig 

Cc: Seitz Ludwig ; The IESG ; 
ace-cha...@ietf.org; draft-ietf-ace-oauth-au...@ietf.org; ace@ietf.org; 
sec-...@ietf.org
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on 
draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Hi Cigdem,

I just quickly scanned the MQTT profile, and noticed that for example the 
C-AS interaction defined in the MQTT-TLS profile (using a new media type 
"application/ace+json") do not map with what is currently defined in the ACE 
framework (which maps more closely to what OAuth 2.0 does, using 
"application/x-www-form-urlencoded" format with a character encoding of UTF-8 
in the HTTP request entity-body for example for the C-AS request).

My comment on point 13. is that: right now I read the framework as "it 
requires CBOR" for this exchange, and I agree with you this didn't seem to go 
with the rest of the specification - I was not requesting CBOR to be made 
mandatory, on the contrary I was pointing out an inconsistency within the 
document.

To re-iterate: I am ok with keeping a different encoding than CBOR in, but 
I do believe it needs clarification in the document. Also I did not suggest to 
remove HTTP from the specification.

Hannes - could you please remind me the substance of the discussion and the 
motivations for having this flexibility on encoding? Ludwig mentions "to allow 
legacy OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE 
interactions on those legs of the communication where no constrained devices 
are involved." I feel like it would not be hard for OAuth2.0 ASes to support 
CBOR, they would need to support more processing defined by the Ace framework 
anyway.. Again, as I said several times, I am ok with stepping back, I just 
wanted to make sure I understood the motivation for a discussion which I 
haven't followed closely.

Francesca

On 25/03/2021, 15:10, "Cigdem Sengul"  wrote:

Hello,
I would like to add my two cents to this as the MQTT-TLS profile does 
use
HTTP/JSON for client-AS and rs-AS communication as similar already was
supported in MQTT implementations between an MQTT broker and external
servers (e.g., via auth plug-ins).

For points like 13: Making CBOR mandatory would break how it is 
implemented
for MQTT-TLS, which implements the AS creation hints as a User Property
inside an MQTT message.
"The User Property is a UTF-8 string pair, composed of a name and a 
value.
The name of the User Property MUST be set to
   "ace_as_hint".  The value of the user property is a UTF-8 encoded
   JSON string containing the mandatory "AS" parameter, and the optional
   parameters "audience", "kid", "cnonce", and "scope" as defined in
   Section 5.1.2 of the ACE framework"

Kind regards,
--Cigdem



On Thu, Mar 25, 2021 at 1:53 PM Francesca Palombini 
 wrote:

> Ludwig,
>
> Thank you for the quick reply, and for the useful background 
information.
>
> As I said, I think this document is important and should move forward
> asap, and it can do so without changing the main assumptions, with 
some
> additional clarifications in the text about CBOR vs "other" when HTTP 
is
> used (which in my opinions are necessary - see points 1, 8, 10, 11, 
13, 15,
> 17, 22, 23, 26, 28).
>
> What I wanted to highlight is that it would s

Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

[Francesca Palombini]

Hi,

(Adding back the ace ml that was dropped at some point)

Here is a proposal for the paragraph in Section 5 with a different last 
sentence to hopefully clarify the need for recommendations but not mandate only 
one sec protocol per profile:

Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides the 
features required above."

  NEW
"Profiles MUST specify a communication security protocol between client and 
RS that provides the features required above. Profiles MUST  specify a 
communication security protocol RECOMMENDED to be used between client and AS 
that provides the features required above. Profiles MUST  specify for 
introspection a communication security protocol RECOMMENDED to be used between 
RS and AS that provides the features required above. These recommendations 
enable interoperability between different implementations, without the need to 
define a new profile if the communication between C/RS and AS is protected with 
a different security protocol complying with the security requirements above."


The proposal for the other section looks good to me.
Francesca

From: Daniel Migault 
Date: Thursday, 4 March 2021 at 17:49
To: Göran Selander 
Cc: Stefanie Gerdes , Olaf Bergmann , 
Francesca Palombini , Russ Mundy 
, "draft-ietf-ace-oauth-au...@ietf.org" 
, Loganaden Velvindron 

Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

HI Goran,

sure any wordsmithing / alternative are fine to me. For the second alternative 
the repetition of "with" may sound to me a bit strange.

Unless anyone objects that would be greatly appreciate to have a new version 
submitted. Thanks!

Yours,
Daniel



On Thu, Mar 4, 2021 at 11:12 AM Göran Selander 
mailto:goran.selan...@ericsson.com>> wrote:
Hi Daniel,

The proposal coincides with the text I proposed Feb 22 except for one sentence:

"Such recommendations are expected, among others, to guarantee independent 
implementations interoperate."

This sentence does not read well to me, perhaps we can change it? For example:

"These recommendations are expected to enable interoperability between 
independent implementations."

 . . . or even add the reason why it is only a recommendation:

"These recommendations are expected to enable interoperability between 
independent implementations, without preventing this profile to be used with 
other security protocols with the AS complying with the security requirements."

I can make the changes and submit a new version of draft-ietf-ace-oauth-authz 
in the beginning of next week when ID submission has reopened.

Regards
Göran



On 2021-03-04, 15:54, "Daniel Migault" 
mailto:mglt.i...@gmail.com>> wrote:


Hi all,
I know everyone is very busy by now, but I am wondering if you could 
provide your input so that we can think of closing this issue before the IETF 
110 - or at least as soon as possible. Our initial milestones were to send 
these doc in February ;-)

Yours,
Logan and Daniel
-- Forwarded message -
From: Daniel Migault mailto:mglt.i...@gmail.com>>
Date: Tue, Mar 2, 2021 at 11:09 PM
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
To: Olaf Bergmann mailto:bergm...@tzi.org>>
Cc: Göran Selander 
mailto:goran.selan...@ericsson.com>>, Olaf 
Bergmann mailto:bergm...@tzi.org>>, Russ Mundy 
mailto:mu...@tislabs.com>>, 
ace@ietf.org<mailto:ace@ietf.org> mailto:ace@ietf.org>>, Stefanie 
Gerdes mailto:ger...@tzi.de>>, Francesca Palombini 
mailto:francesca.palomb...@ericsson.com>>, 
Daniel Migault 
mailto:40ericsson@dmarc.ietf.org>>



Thanks for the feedbacks Olaf. So I understand why we need such flexibility 
on the client side. The main reason seems that the communication with the AS is 
seen as bootstrapping the communication between the client and the RS and as 
such we would like to keep them as independent as possible.
I see interoperability being achieved when a) client, RS, and AS 
implemented by independent vendors and b) all three follow the framework and 
the given profile is sufficient to make them work together. Currently the 
client - RS communication is well defined, but the client AS communication is 
left to a RECOMMENDATION.

RFC2119 defines RECOMMEND as follows:
SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.
The question becomes how RECOMMENDED is sufficient or not.




It seems to me the definition above makes it clear that the recommended 
protocol is expected to be supported, and AS or clients that are independently 
developed are expected to support 

Re: [Ace] Genart telechat review of draft-ietf-ace-oscore-profile-17

[Francesca Palombini]

Hi Elwyn,

Thank you very much for the in depth review! We have incorporated your changes 
in the newly submitted v-18 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but 
you can also see the specific changes in the github: 
https://github.com/ace-wg/ace-oscore-profile/commit/c98ea9c53994aaa85add5c4a3436a14935fa0471
 

Answers inline.

Thanks again,
Francesca

On 23/03/2021, 23:29, "Elwyn Davies via Datatracker"  wrote:

Reviewer: Elwyn Davies
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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-ace-oscore-profile-17
Reviewer: Elwyn Davies
Review Date: 2021-03-23
IETF LC End Date: 2020-07-20
IESG Telechat date: 2021-03-25

Summary:
Ready with nits.  A very great improvement on the previously reviewed 
version. 
Thanks.

FP: Thank you!

Major issues:
None

Minor issues:

Would it be useful to provide some advice on the length of salts and IDs to 
go
with the advice on length of nonces?  There is some in s3.3 of RFC 8613 but
some other reference might be helpful, maybe placed in s3.2.1. and/or s4.

FP: This draft does not have any other requirements on salts and IDs than RFC 
8613. The IDs need not be long, but unique. The salt need not even be unique. 
According to RFC 5869 Section 3.1 “HKDF is defined to operate with or without 
salt”. However, the use of salt adds to the strength of HKDF. “Ideally, the 
salt value is a random (or pseudorandom) string of the length HashLen.” But the 
salt going into HKDF is composed of the master salt and the nonces. It 
therefore suffices with nonces of length HashLen/2 generated by the peers as 
described in this draft, independent of salt.

Nits/editorial comments:

General: The RFC Editor conforms rigorously to American practice and allows
only the use of double quote marks (") in the text when marking strings as
quotations and such like.  The document makes extensive but not totally
consistent, use of single quotes to flag up field names and such like (e.g.,
'nonce1').  In practice these are unnecessary, but may be replaced by the 
RFC
Editor if left in place.  Personally. I think most of them can be removed. 
NB
this does not affect CBOR items such as h'1645.

FP: We have now removed all single quotes "'" and replaced them with the 
XML2RFC v3 supported . We will make sure to follow RFC Editor 
recommendations about this.

General: There are lots of usages of 'CBOR diagnostic notation without the 
tag
and value abbreviations'.  An abbreviation would reduce the verbiage.

FP: Fair point, we have added this to the terminology.

General: It is slightly confusing to have Nonce 1/N1/nonce1 and Nonce
2/N2/nonce2 used in the document.  Am I right in thinking Nonce 1 and N1 are
the same with nonce1  being the name of the JSON/CBOR parameter used to 
carry
the value?  A few words of clarrification would help.

FP: There is a difference between the three: Nonce 1 is the name of the field, 
N1 is the value, nonce1 is the parameter's label. If you have suggestion on 
where to add this, that would be helpful.

Abstract/s1:  It would be useful to introduce the name of the profile
(coap_oscore) up front.  It rather sneaks out in s3.

FP: Good point, added.

s1, para 2: Need to expand CBOR on first use.

FP: Usually yes, but because here it is used as the expansion of COSE, we used 
the RFC Editor abbreviation expansion, which keeps CBOR non-expanded.

s2, end of para 3: s/as well/instead/? or s/as well/alternatively/.

FP: Ok, replaced with alternatively.

s2, para 7 and s6, bullet 2: s/e.g. expiration./for example, expiration./

FP: Ok, fixed.

s3.1, para 3 and last para: s/reported/shown/

FP: Ok, fixed.

s3.1, Figure 2 and Figure 3: Appendix F.3 of draft-ietf-ace-oauth-authz 
reports
that req_aud was replaced by audence at version 19 of the document.

FP: Good catch! Fixed.

s3.2, second set of bullets:  Need to expand HMAC and HKDF on first use (not
well-known in RFC Editor list).  It would also be useful to put a pointer to
section 11.1 of RFC 8152 here to indicate the allowed HKDF algorithms.

FP: Agreed. We have added it to the terminology section (to expand it) and 
added a reference to it. Also added the pointer to COSE.

s3.2, 2nd para after 2nd set of bullets: s/The applications needs/The
application needs/

FP: Ok, fixed.

s3.2, 3rd para after 2nd set of bullets: s/parameeter/parameter/

FP: Fixed.

s3.2, 4th para after 2nd set of bullets: s/the use of CBOR web token/the 
use of
a 

Re: [Ace] Murray Kucherawy's No Objection on draft-ietf-ace-oscore-profile-17: (with COMMENT)

[Francesca Palombini]

Hi Murray!

Thank you very much for the review! We have incorporated your changes in the 
newly submitted v-18 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but 
you can also see the specific changes in the github commit: 
https://github.com/ace-wg/ace-oscore-profile/commit/01804050ccd6628bc0ee385e0f9a7a0e31d7513a
https://github.com/ace-wg/ace-oscore-profile/commit/5ed90a19d5e38140f254c13986325f5699ca6835
https://github.com/ace-wg/ace-oscore-profile/commit/fa517050f6f8209cc9f07073e91b761196973b12

Answers inline.

Thanks again,
Francesca

On 25/03/2021, 05:46, "Murray Kucherawy via Datatracker"  
wrote:

Murray Kucherawy has entered the following ballot position for
draft-ietf-ace-oscore-profile-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/



--
COMMENT:
--

I tried, but failed, to come up with a reason to DISCUSS this document just 
to
troll my new co-AD.

FP: Ah! Very satisfying to hear :D

As in one of the other ACE documents, the variable use of apostrophes and
quotes created mental dissonance.  Here, though, it's not just in the 
JSON-like
examples, but even in the prose.  It's consistent until about Section 4, and
then it begins to change.  The second-last paragraph of Section 4.2 even 
uses
both.

FP: Fair comment, we have now removed the use of single quotes.

Within Section 1.1, the text describes the draft variably as "this 
document",
"this specification", "the document", and "this memo".  That's weird.  And
"memo" appears again in Acknowledgements.

FP: Point taken, we now only refer to the draft as "This document"

In Section 6, you might want to clarify that the context is discarded when 
any
of the things in that list occur.  Or is it only when all of them occur?

FP: Indeed, when any of the things occur. Now clarified.

In Section 7, is "provisionings" a word?  Perhaps change "considerably more
token provisionings than expected" to "considerably more tokens provisioned
than would be expected".

FP: It might be a word, it might not, since in doubt we have now changed to 
your suggested phrasing. Thank you!



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

Re: [Ace] Zaheduzzaman Sarker's No Objection on draft-ietf-ace-oscore-profile-17: (with COMMENT)

[Francesca Palombini]

Hi Zahed,

Thank you very much for the review! We have incorporated your changes in the 
newly submitted v-18 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but 
you can also see the specific changes in the github: 
https://github.com/ace-wg/ace-oscore-profile/commit/e234968d5078e667a0646fba3e708729c39dcadd
 

Answers inline.

Thanks again,
Francesca


On 24/03/2021, 21:07, "iesg on behalf of Zaheduzzaman Sarker via Datatracker" 
 wrote:

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ace-oscore-profile-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/



--
COMMENT:
--

Thanks for this document.

I support Roman's discuss and have similar observations when it comes to
normative text usage (see Roman's discuss comments).

FP: Yes, we have now addressed his discuss.

Some nits below --

* Section 2:
  This
  profile RECOMMENDS the use of OSCORE between client and AS, to reduce
  the number of libraries the client has to support, but other
  protocols fulfilling the security requirements defined in section 5
  of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as
  well.

 [TLS, DTLS] reference is missing.

FP: Right, added.

* Section 3.2:
   Typo : s/parameeter/parameter

FP: Fixed.



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

Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-18.txt

[Francesca Palombini]

Hi ace wg, chairs, Ben,

We have submitted an update to the OSCORE profile that addresses all comments 
from the IESG, and have answered the ADs individually.

Thanks,
Francesca

On 14/04/2021, 18:33, "Ace on behalf of 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   : OSCORE Profile of the Authentication and 
Authorization for Constrained Environments Framework
Authors : Francesca Palombini
  Ludwig Seitz
  Göran Selander
  Martin Gunnarsson
Filename: draft-ietf-ace-oscore-profile-18.txt
Pages   : 34
Date: 2021-04-14

Abstract:
   This document specifies a profile for the Authentication and
   Authorization for Constrained Environments (ACE) framework.  It
   utilizes Object Security for Constrained RESTful Environments
   (OSCORE) to provide communication security and proof-of-possession
   for a key owned by the client and bound to an OAuth 2.0 access token.


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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-ace-oscore-profile-18.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-18


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] Roman Danyliw's Discuss on draft-ietf-ace-oscore-profile-17: (with DISCUSS and COMMENT)

[Francesca Palombini]

Hi Roman! 

Thank you very much for the review! We have incorporated your changes in the 
newly submitted v-18 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but 
you can also see the specific changes in the github commits:
https://github.com/ace-wg/ace-oscore-profile/commit/d64f5563d5be185cd7dcb6b8972dce33ae31c9c2
 
https://github.com/ace-wg/ace-oscore-profile/commit/8ad0db81cb391742887d5e1cae2cf33b0702836f
https://github.com/ace-wg/ace-oscore-profile/commit/a8caabb2ae5588a5923ac569a2fe85262031ed0c
 

Answers inline.

Thanks again,
Francesca

On 23/03/2021, 04:28, "Roman Danyliw via Datatracker"  wrote:

Roman Danyliw has entered the following ballot position for
draft-ietf-ace-oscore-profile-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/



--
DISCUSS:
--

(A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], 
the
name of the parameter in the C-to-AS communication is “ace_profile” (not
“profile”).  The “ace_profile” parameter is mistakenly referenced as 
“profile”
in the following place:

(a) Section 3.2.
   The AS can signal that the use of OSCORE is REQUIRED for a specific
   access token by including the "profile" parameter with the value
   "coap_oscore" in the access token response

FP: Good catch! Fixed 

--
COMMENT:
--

Thank you to Kathleen Moriarty for the SECDIR review.

** In addition to the normative text noted in the DISCUSS, the examples in
Figure 4 and Figure 7 also have the same typo (but that doesn’t rise to a
DISCUSS)

FP: Indeed, fixed.

** Section 7.  Per “Developers should avoid using multiple access tokens 
for a
same client”, is there a reason not to use a normative SHOULD here?  The 
DTLS
profile has nearly the identical words and uses a normative SHOULD?

Likewise should “This profile recommends that the that RS maintains a single
access token for each client” be “This profile RECOMMENDS”?

FP: Right, now using BCP14 SHOULD and RECOMMENDS as you suggest.

** Editorial nits
Section 3.2.  Typo. s/The applications needs/The application needs/

FP: Fixed.

Section 3.2.  Typo. s/parameeter/parameter/

FP: Fixed.

Section 4.  Typo. s/Note that the RS and client authenticates/Note that the 
RS
and client authenticate/

FP: Fixed.

Section 4.1.  Typo. s/The client may also chose/The client may also choose/

FP: Fixed.


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

Re: [Ace] Lars Eggert's No Objection on draft-ietf-ace-oscore-profile-17: (with COMMENT)

[Francesca Palombini]

Hi Lars,

Thank you very much for the review! We have incorporated your changes in the 
newly submitted v-18 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , 
including many good changes from the GenART review from Elwyn.

Answers inline.

Thanks again,
Francesca

On 25/03/2021, 12:29, "iesg on behalf of Lars Eggert via Datatracker" 
 wrote:

Lars Eggert has entered the following ballot position for
draft-ietf-ace-oscore-profile-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/



--
COMMENT:
--

All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to 
let me
know what you did with these suggestions.

FP: Well, letting you know anyway... :)

Paragraph 1, nit:
Elwyn Davies' Gen-ART review
(https://mailarchive.ietf.org/arch/msg/gen-art/Es7PhQvSnCixYRfEYs0RLqcLYC0/)
contains a nits that I wanted to make sure you were aware of.

FP: Thanks, fixed.

Section 3.2, paragraph 14, nit:
-the 'cnf' parameeter of the access token response.  If included, the
-   -
+the 'cnf' parameter of the access token response.  If included, the

FP: Fixed.


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

Re: [Ace] [Last-Call] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14

[Francesca Palombini]

Jean: thank you very much for your thoughtful review! Cigdem, thank you for 
addressing it, I do believe it improves the document.

Just one note: for the downref to informative documents (for those documents 
that were actually included in the text), please revert the change – RFC 6234 
and RFC 8032 were correctly referenced as normative, since they are mandatory 
to implement. MQTT standards are also correctly referenced normatively. Jean 
was only noting these appear as downrefs, but downrefs are not “mistakes”, they 
just require more attention – see https://www.rfc-editor.org/info/bcp97 for 
more information. Downrefs are usually Last Called to make sure the community 
is aware of them, except for those that have appeared as downref for many 
documents and don’t need to be Last Called explicitly anymore: 
https://datatracker.ietf.org/doc/downref/.

Thanks,
Francesca

From: last-call  on behalf of Cigdem Sengul 

Date: Tuesday, 8 March 2022 at 19:37
To: Jean Mahoney 
Cc: a...@ietf.org , draft-ietf-ace-mqtt-tls-profile@ietf.org 
, last-c...@ietf.org 
, Ace Wg 
Subject: Re: [Last-Call] Artart last call review of 
draft-ietf-ace-mqtt-tls-profile-14
Dear Jean,
Thank you for your review.
I implemented changes and prepared a pull request at: 
https://github.com/ace-wg/mqtt-tls-profile/pull/102

Below is a summary of how I revised the text according to your suggestions, and 
corrected references for this document (removing unused references due to 
changes of text etc.) I have still kept MQTT as normative, as the document is 
about MQTT, but is it expected to be informative when the reference is a 
non-RFC?

Kind regards,
--Cigdem

On Fri, 4 Mar 2022 at 21:40, Jean Mahoney via Datatracker 
mailto:nore...@ietf.org>> wrote:
Reviewer: Jean Mahoney
Review result: Ready with Issues

This document is ready but has minor issues with wording and references.

Minor issues:

Section 1: The subject seems to be missing in the following sentence.
Should "recommended" be normative?

Current:
   The Client-AS and RS-AS MAY also use protocols other
   than HTTP, e.g.  Constrained Application Protocol (CoAP) [RFC7252] or
   MQTT; it is recommended that TLS is used to secure these
   communication channels between Client-AS and RS-AS.

Perhaps (add "exchanges", split into two sentences):
   The Client-AS and RS-AS exchanges MAY also use protocols other
   than HTTP, e.g., Constrained Application Protocol (CoAP) [RFC7252] or
   MQTT. It is recommended that TLS is used to secure these
   communication channels between Client-AS and RS-AS.

[CS: Done.]


Section 2.2.4.2.2: I'm having difficulty parsing the following normative
statements. Does "MUST" also cover the Authentication Data (i.e., MUST be set
to "ace" and MUST contain Authentication Data)? If the Authentication Data MUST
NOT be empty, MUST it contain the 8-byte RS nonce or could it contain something
else?

Current:
   The AUTH packet to continue authentication includes the
   Authentication Method, which MUST be set to "ace" and Authentication
   Data.  The Authentication Data MUST NOT be empty and contains an
   8-byte RS nonce as a challenge for the Client (Figure 6).

[CS: Revised as:
The Broker continues authentication using an AUTH packet that contains the 
Authentication Method
and the Authentication Data. The Authentication Method MUST be set to "ace", 
and the Authentication Data MUST NOT be empty and contain
an 8-byte RS nonce as a challenge for the Client.
]


Section 4: I'm having difficulty parsing the following. Is it talking about
using a challenge from the current TLS session?

Current:
   To re-authenticate, the
   Client MUST NOT use Proof-of-Possession using a challenge from the
   TLS session during the same TLS session to avoid re-using the same
   challenge value from the TLS-Exporter.

[CS: Revised:
If re-authenticating during the current TLS session, the Client MUST NOT use 
the method
   described in Section 2.2.4.2.1, Proof-of-Possession using a challenge
   from the TLS session, to avoid re-using the same challenge value from
   the TLS-Exporter.
]

Section 6.1: Could more guidance or examples of necessary policies be provided
here?

Current:
   However, stored Session state can be discarded as a
   result of administrator policies, and Brokers SHOULD implement the
   necessary policies to limit misuse.

[CS: Revised as:
"However, stored Session state can be discarded as a result
of administrator action or policies (e.g. defining an automated
response based on storage capabilities), and Brokers SHOULD implement the 
necessary policies to limit
misuse."

Would this work?
]

References: idnits identifies the following issues. The three informative RFCs
are already listed in the downrefs registry, though

Re: [Ace] Francesca Palombini's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

[Francesca Palombini]

Hi Cigdem,

Thank you for the quick reply!
The two additional registrations for the parameters Toid and Tperm look good, 
although I have a couple of suggestions:

  1.  For Toid I would add a reference to Section 1.3 (and maybe capitalize 
Topic Filter, just to be nitpicking). I would also mention that this is ancoded 
ass a text string (or point to section 2.3).
  2.  For Tperm, I don’t think it is needed to create an additional registry, 
unless you foresee that there might be need to add new methods other than “pub” 
and “sub” in the future, in which case I agree with you that the IANA registry 
is the best choice. If you don’t, I would remove the new registry and just 
mention that the Tperm is a text string with value either “pub” or “sub”, and 
reference section 2.3.
I think that should cover it. Again, Carsten’s opinion is welcome as the 
creator of the registry (lacking the Designated expert that is not yet 
assigned).


Francesca

From: Cigdem Sengul 
Date: Thursday, 10 March 2022 at 12:57
To: Francesca Palombini 
Cc: The IESG , draft-ietf-ace-mqtt-tls-prof...@ietf.org 
, ace-cha...@ietf.org 
, Ace Wg , Daniel Migault 
, Carsten Bormann 
Subject: Re: Francesca Palombini's Discuss on 
draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)
Hello Francesca,

Thank you for your feedback. My response is below.

On Thu, 10 Mar 2022 at 10:03, Francesca Palombini via Datatracker 
mailto:nore...@ietf.org>> wrote:
Francesca Palombini has entered the following ballot position for
draft-ietf-ace-mqtt-tls-profile-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/



--
DISCUSS:
--

Updating my ballot after reviewing draft-ietf-ace-aif-06. Just want to make
sure we don't miss anything, please feel free to correct me if I missed the
mark here.

FP: https://datatracker.ietf.org/doc/html/draft-ietf-ace-aif-06#section-4
states:

default values are the values "URI-local-
   part" for Toid and "REST-method-set" for Tperm, as per Section 3 of
   the present specification.

   A specification that wants to use Generic AIF with different Toid
   and/or Tperm is expected to request these as media type parameters
   (Section 5.2) and register a corresponding Content-Format
   (Section 5.3).

FP: I wonder if this document should define a new media type parameter for
Tperm (as REST-method-set is not appropriate for "pub"/"sub" value) and
register a corresponding Content-Format as indicated in the paragraph above.
CC'ing Carsten for his opinion.

CS: Since we considered this for the Broker's consumption using MQTT, 
registration of a new media type looks like it was overlooked.
I assume you are raising this issue as the client may use the scope for token 
requests using application/ace+json(cbor) application/aif+json(cbor)
If that is the case, I suggest the following text for AIF and  MQTT Permissions 
registry (with Expert Review registration procedure) similar to 
https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ -



AIF



   For the media-types application/aif+cbor and application/aif+json

   defined in Section 5.1 of [I-D.ietf-ace-aif], IANA is requested to

   register the following entries for the two media-type parameters Toid

   and Tperm, in the respective sub-registry defined in Section 5.2 of

   [I-D.ietf-ace-aif] within the "MIME Media Type Sub-Parameter"

   registry group.



   *  Name: mqtt-topic-filter



   *  Description/Specification: topic filter used in MQTT



   *  Reference: [[This document]]



   *  Name: mqtt-permissions



   *  Description/Specification: permissions for MQTT client.



   *  Reference: [[This document]]



MQTT Permissions



   This document establishes the IANA "MQTT Permissions" registry.

   The registry has been created to use the "Expert Review" registration

   procedure [RFC8126].



   This registry includes the possible permissions of MQTT clients when 
communicating

   with an MQTT broker.



   The columns of this registry are:



   *  Name: A value that can be used in documents for easier

  comprehension, to identify a possible permissions of MQTT clients.



   *  Description: This field contains a brief description of the permission.



   *  Reference: This contains a pointer to the public specification for

  the permission.



   This registry will be initially populated by

Re: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-14.txt

[Francesca Palombini]

Hi,

I am not aware of any IPR related to this document.

Francesca

From: Ace  on behalf of Daniel Migault 

Date: Wednesday, 12 January 2022 at 15:05
To: Marco Tiloca 
Cc: ace@ietf.org 
Subject: Re: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-14.txt
Hi,

In case it has missed,  I am just following up with IPR disclosure.

Yours,
Daniel

On Wed, Dec 22, 2021 at 7:55 PM Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:
Hi,

In order to complete the shepherd I would like the co-author to confirm that 
any and all appropriate IPR disclosures required for full conformance with the 
provisions of BCP 78 and BCP 79 have already been filed.

Please have also a look at the nits
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ace-key-groupcomm-14.txt

There is a MAY NOT that causes an issue as well as unused references.

Yours,
Daniel

On Mon, Oct 25, 2021 at 12:48 PM Marco Tiloca 
mailto:40ri...@dmarc.ietf.org>> wrote:
Hello ACE,

This new version should have addressed all the WGLC comments from Göran
[1] and Cigdem [2], as well as further points from follow-up discussions
on the thread throughout the draft revision.

Thank you very much for the good comments!

Best,
/Marco

[1] https://mailarchive.ietf.org/arch/msg/ace/pr2gBhvqy9j8AfUdQVTZLwamXac/

[2] https://mailarchive.ietf.org/arch/msg/ace/gv_uRo2Y45jqOLJghVSbAARWky0/

On 2021-10-25 15:57, internet-dra...@ietf.org<mailto: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   : Key Provisioning for Group Communication using ACE
>  Authors : Francesca Palombini
>Marco Tiloca
>   Filename: draft-ietf-ace-key-groupcomm-14.txt
>   Pages   : 106
>   Date: 2021-10-25
>
> Abstract:
> This document defines how to use the Authentication and Authorization
> for Constrained Environments (ACE) framework to distribute keying
> material and configuration parameters for secure group communication.
> Candidate group members acting as Clients and authorized to join a
> group can do so by interacting with a Key Distribution Center (KDC)
> acting as Resource Server, from which they obtain the keying material
> to communicate with other group members.  While defining general
> message formats as well as the interface and operations available at
> the KDC, this document supports different approaches and protocols
> for secure group communication.  Therefore, details are delegated to
> separate application profiles of this document, as specialized
> instances that target a particular group communication approach and
> define how communications in the group are protected.  Compliance
> requirements for such application profiles are also specified.
>
>
> The IETF datatracker status page for this draft is:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2Fdata=04%7C01%7Cmarco.tiloca%40ri.se%7Ca638ee397ced4fc372ff08d997bf79b5%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637707672366321795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=MUGHcPBWXrsBtP%2BEJ0PdmTxTlrfQ9jb3IZCzVopwCB4%3Dreserved=0
>
> There is also an HTML version available at:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-ace-key-groupcomm-14.htmldata=04%7C01%7Cmarco.tiloca%40ri.se%7Ca638ee397ced4fc372ff08d997bf79b5%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637707672366321795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=y6LdDfymSDIs5cDuPgmhOciO%2BEahcrSXGvW3LfR98j8%3Dreserved=0
>
> A diff from the previous version is available at:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-14data=04%7C01%7Cmarco.tiloca%40ri.se%7Ca638ee397ced4fc372ff08d997bf79b5%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637707672366321795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kmEdmD6senkWyvdWMwx5OzdzOq0OavECCx4yKI0g4Ds%3Dreserved=0
>
>
> Internet-Drafts are also available by anonymous FTP at:
> https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2Fdata=04%7C01%7Cmarco.tiloca%40ri.se%7Ca638ee397ced4fc372ff08d997bf79b5%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637707672366321795%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=WKV