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

[Cigdem Sengul]

Hello ace,
In the new version, we have updated the following:
   *  More details on the scope format.
   *  More details in the encoding of the 'key' parameter in the Join
Response.
   *  More details on exchanges between group members and KDC.
   *  More details on the rekeying process and rekeying messages.
   *  Defined replay checks at the Subscriber.
   *  Improved examples.
   *  Improved security considerations.
   *  Revised IANA considerations.
   *  Aligned the list of profile requirements with
draft-ietf-ace-key-groupcomm.
   *  Clarifications and editorial improvements.

Kind regards,
--Cigdem

On Sun, 7 Jul 2024 at 22:24,  wrote:

> Internet-Draft draft-ietf-ace-pubsub-profile-10.txt is now available. It
> is a
> work item of the Authentication and Authorization for Constrained
> Environments
> (ACE) WG of the IETF.
>
>Title:   Publish-Subscribe Profile for Authentication and Authorization
> for Constrained Environments (ACE)
>Authors: Francesca Palombini
> Cigdem Sengul
> Marco Tiloca
>Name:draft-ietf-ace-pubsub-profile-10.txt
>Pages:   56
>Dates:   2024-07-07
>
> Abstract:
>
>This document defines an application profile of the Authentication
>and Authorization for Constrained Environments (ACE) framework, to
>enable secure group communication in the Publish-Subscribe (Pub-Sub)
>architecture for the Constrained Application Protocol (CoAP) [draft-
>ietf-core-coap-pubsub], where Publishers and Subscribers communicate
>through a Broker.  This profile relies on protocol-specific transport
>profiles of ACE to achieve communication security, server
>authentication, and proof-of-possession for a key owned by the Client
>and bound to an OAuth 2.0 access token.  This document specifies the
>provisioning and enforcement of authorization information for Clients
>to act as Publishers and/or Subscribers, as well as the provisioning
>of keying material and security parameters that Clients use for
>protecting their communications end-to-end through the Broker.
>
>Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]"
>with the RFC number of that document and delete this paragraph.
>
> The IETF datatracker status page for this Internet-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-10.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-pubsub-profile-10
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> ___
> Ace mailing list -- ace@ietf.org
> To unsubscribe send an email to ace-le...@ietf.org
>
___
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org

[Ace] Re: Agenda for ietf 120

[Cigdem Sengul]

Dear Loganaden,

We will need 10 minutes for the pub-sub update.
Kind regards,
--Cigdem

On Wed, 26 Jun 2024 at 19:02, Loganaden Velvindron 
wrote:

> Dear all,
>
> Please kindly send the items that you wish to discuss during the ietf 120
> meeting along with the time needed.
>
>
> Kind regards,
> Tim & logan
>
>
> ___
> Ace mailing list -- ace@ietf.org
> To unsubscribe send an email to ace-le...@ietf.org
>
___
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org

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

[Cigdem Sengul]

Hello ace,

I've reviewed the document and found it largely ready.

Below, I make some suggestions to improve clarity and list a few editorial
comments, hope it helps.
Kind regards,
--Cigdem


Section 2. Group Administration
"The AS MAY release Access Tokens to the Administrator for other purposes
than accessing admin resources of registered Group Managers"

=> Reading further into the document, it becomes clear later that "
Building on the above, the same single scope can include user scope entries
as well as admin scope entries"

i.e., tokens may express permissions for user resources). It would be good
to clarify this earlier.

Section 3. Format of Scope

=> The object identifier ("Toid") examples for wildcard patterns and
complex patterns would be useful.
=> Can the Create permission be paired with a "literal" Toid? So, the admin
has the right to create a specific config for a specific group name?

Figure 2:
Write  | 3 | Change group configurations

=>Instread of "Change", Update group configurations?

Section 3.1

"The Administrator may have established a secure communication association
with the Group Manager based on a first Access Token   T1, and then created
an OSCORE group G.  Following the
  invalidation of T1 (e.g., due to expiration) and the establishment of
a new secure communication association with the Group Manager based on a
new Access Token T2, the Administrator can seamlessly perform authorized
operations on the previously created group G."

The example is not clear to me. Why does the G having a wildcard or complex
pattern help in this case?

5.1.2

'group_title', with value either a human-readable description of the OSCORE
group encoded as a CBOR text string, or the CBOR simple value "null" (0xf6)
if no description is specified.

==>If this is group description, group_desc sounds more fitting than
group_title?

5.2
"A possible reason for the Group Manager to consider default values
different from those recommended in this section is to ensure that each of
those are consistent with what the Group Manager supports, e.g., in terms
of signature algorithm and format of authentication credentials used in the
OSCORE group."

Is this mainly saying, "The Group Manager MAY choose different default
values instead of those recommended in this section ... "


6.2 Retrieve a List of Group Configurations by Filters

It would be good to give an example with status filters as well. For
example, is it possible to use a complex pattern for group_name filter?

6.3 Create a New Group Configuration (and also 6.6.)

"Alternatively, the Administrator can perform the registration in
the Resource Directory on behalf of the Group Manager, acting
as  Commissioning Tool."

Why consider this option when

"Therefore, it is RECOMMENDED that registrations of links to
group-membership resources in the Resource Directory are made (and possibly
updated) directly by the Group Manager, rather than by the Administrator."


Editorial
Abstract
OLD:
A Group Manager is responsible to handle the joining of new group
  members, as well as to manage and distribute the group keying
   material.

NEW:
A Group Manager is responsible for handling the joining of new group
   members, as well as managing and distributing the group keying
   material.

OLD:
This document defines a RESTful admin interface at the
   Group Manager, that

NEW:
This document defines a RESTful admin interface at the
   Group Manager that

Introduction
OLD:
 When group communication for CoAP is protected with Group OSCORE,
   nodes are required to explicitly join the correct OSCORE group.

NEW:
When group communication for CoAP is protected with Group OSCORE,
   nodes are required to join the correct OSCORE group explicitly.

OLD:
e.g., based on
   the current application state or on pre-installed policies.

NEW:
e.g., based on
   the current application state or pre-installed policies.

TERMINOLOGY
OLD:
An OSCORE group is used as security group for
 one or many application groups.

NEW:
An OSCORE group is used as a security group for
 one or many application groups.

3.1
OLD:
When relying on wildcard patterns and complex patterns, the Administrator
and the AS do not need to know exact group names for
  requesting and issuing an Access Token, respectively (see
  Section 4).

NEW:
When relying on wildcard patterns and complex patterns, the Administrator
and the AS do not need to know the exact group names for
  requesting and issuing an Access Token, respectively (see
  Section 4).

4.1
OLD:
With respect to the main Administrator, such assistant Administrators
   are expected to have less permissions to perform administrative
   operations related to the OSCORE group at the Group Manager.

NEW:
With respect to the main Administrator, such assistant Administrators
   are expected to have fewer permissions to perform administrative
   operations related to the OSCORE group at the Group Manager.

OLD:  For
   example, they 

Re: [Ace] [IANA #1284520] expert review for draft-ietf-ace-key-groupcomm (ace)

[Cigdem Sengul]

Dear David,
Thank you for your patience. I have reviewed Section 11.4 of
draft-ietf-ace-key-groupcomm-17
and proposed registrations look good to me unless  Göran has a different
comment.
Kind regards,
--Cigdem

On Thu, 2 Nov 2023 at 21:35, David Dong via RT <
drafts-expert-review-comm...@iana.org> wrote:

> Hi Göran and Cigdem (cc: ace WG),
>
> Following up on this request again; as the designated experts for the
> OAuth Parameters CBOR Mappings registry, can you review the proposed
> registration in draft-ietf-ace-key-groupcomm-17 for us? Please see:
>
> https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
>
> The assigned due date is today, November 2nd.
>
> If this is OK, when the IESG approves the document for publication, we'll
> make the registration at:
>
> https://www.iana.org/assignments/ace/
>
> Unless you ask us to wait for the other reviewer, we’ll act on the first
> response we receive.
>
> With thanks,
>
> David Dong
> IANA Services Sr. Specialist
>
> On Thu Oct 26 16:01:25 2023, david.dong wrote:
> > Hi Göran and Cigdem (cc: ace WG),
> >
> > Following up on this request; as the designated experts for the OAuth
> > Parameters CBOR Mappings registry, can you review the proposed
> > registration in draft-ietf-ace-key-groupcomm-17 for us? Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
> >
> > The due date is November 2nd.
> >
> > If this is OK, when the IESG approves the document for publication,
> > we'll make the registration at:
> >
> > https://www.iana.org/assignments/ace/
> >
> > Unless you ask us to wait for the other reviewer, we’ll act on the
> > first response we receive.
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Sr. Specialist
> >
> > On Thu Oct 19 22:35:46 2023, david.dong wrote:
> > > Dear Göran Selander and Cigdem Sengul (cc: ace WG),
> > >
> > > As the designated experts for the OAuth Parameters CBOR Mappings
> > > registry, can you review the proposed registration in draft-ietf-ace-
> > > key-groupcomm-17 for us? Please see:
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
> > >
> > > The due date is November 2nd.
> > >
> > > If this is OK, when the IESG approves the document for publication,
> > > we'll make the registration at:
> > >
> > > https://www.iana.org/assignments/ace/
> > >
> > > Unless you ask us to wait for the other reviewer, we’ll act on the
> > > first response we receive.
> > >
> > > With thanks,
> > >
> > > David Dong
> > > IANA Services Sr. Specialist
>
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Draft ACE agenda for IETF 118

[Cigdem Sengul]

Dear Tim,

Pubsub-profile needs 5 minutes, and I will present online.

Kind regards,

--Cigdem


On Fri, 27 Oct 2023 at 16:50, Tim Hollebeek  wrote:

>
>
> Hello,
>
>
>
> I’m Tim Hollebeek, and I’ll be helping out as the new co-chair of ACE.
> Sorry for the delay in getting things organized, it took a while for Paul,
> Loganaden and I to get in touch and figure out how this transition is going
> to work, which is still in progress.  I will be in Prague and would
> encourage those of you there to reach out to me if you would like to chat.
> I’m still in the process of getting up to speed on many of these documents
> and discussions, and learning who the people involved are.
>
>
>
> We’ve worked together to put together the following draft agenda, and I’m
> very open to any comments, suggestions or corrections.  I am under no
> illusions that it is perfect, and am happy to work together with the group
> to make it better.  My responses might be a little slow for a week, though,
> as I’m currently on sabbatical and not checking my email or as thorougly as
> often as usual.
>
>
>
> I’ve omitted time allocations for now, but please be respectful of the
> time of participants and the other presenters.  I’m going to be keeping an
> eye on the clock in Prague and trying to keep things moving and on track so
> everyone has a chance to present their draft.
>
>
>
> ---BEGIN DRAFT AGENDA
>
> Administrivia
>
> -- chairs
>
>
>
> Pubsub-profile?
>
> -- wasn't on IETF 117 agenda, needed for 118 or no?
>
>
>
> draft-ietf-ace-edhoc-oscore-profile
>
> -- Göran Selander
>
>
>
> draft-ietf-ace-coap-est-oscore
>
> -- Mališa Vučinić
>
>
>
> draft-ietf-ace-oscore-gm-admin
>
> -- Marco Tiloca
>
>
>
> draft-tiloca-ace-group-oscore-profile (ADOPTION CALL PENDING)
>
> -- Rikard Hoglund
>
>
>
> draft-tiloca-ace-workflow-and-params (ADOPTION CALL PENDING)
>
> -- Marco Tiloca
>
>
>
> draft-finkhaeuser-caps-for-distributed-auth
>
> -- Jens Finkhauser
>
>
>
> AOB
>
> ---END DRAFT AGENDA
>
>
>
> For the chairs,
>
>
>
> -Tim
> ___
> 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-pubsub-profile-08.txt

[Cigdem Sengul]

Dear Ace,
The new draft has the following changes:
 Version -07 to -08

   *  Revised presentation of the scope format.

   *  Revised presentation of the Join Request-Response exchange.

   *  The 'cnonce' parameter must be present in the Join Request.

   *  The 'kid' of the group key is used as Group Identifier.

   *  Relaxed inclusion of the 'peer_roles' parameter.

   *  More detailed description of the encryption and signing
  operations.

   *  Defined construction of the AEAD nonce.

   *  Clarifications and editorial improvements.

Thanks, Marco!
--Cigdem

On Mon, 23 Oct 2023 at 21:34,  wrote:

> Internet-Draft draft-ietf-ace-pubsub-profile-08.txt is now available. It
> is a
> work item of the Authentication and Authorization for Constrained
> Environments
> (ACE) WG of the IETF.
>
>Title:   Publish-Subscribe Profile for Authentication and Authorization
> for Constrained Environments (ACE)
>Authors: Francesca Palombini
> Cigdem Sengul
> Marco Tiloca
>Name:draft-ietf-ace-pubsub-profile-08.txt
>Pages:   48
>Dates:   2023-10-23
>
> Abstract:
>
>This document defines an application profile of the Authentication
>and Authorization for Constrained Environments (ACE) framework, to
>enable secure group communication in the Publish-Subscribe (pub/sub)
>architecture for the Constrained Application Protocol (CoAP) [draft-
>ietf-core-coap-pubsub], where Publishers and Subscribers communicate
>through a Broker.  This profile relies on protocol-specific transport
>profiles of ACE to achieve communication security, server
>authentication, and proof-of-possession for a key owned by the Client
>and bound to an OAuth 2.0 Access Token.  This document specifies the
>provisioning and enforcement of authorization information for Clients
>to act as Publishers and/or Subscribers, as well as the provisioning
>of keying material and security parameters that Clients use for
>protecting their communications end-to-end through the Broker.
>
>Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]"
>with the RFC number of that document and delete this paragraph.
>
> The IETF datatracker status page for this Internet-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-08.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-pubsub-profile-08
>
> Internet-Drafts are also available by rsync at:
> rsync.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-pubsub-profile-07.txt

[Cigdem Sengul]

Dear Ace,
We made the following changes to the pub-sub draft with Marco:


   *  Clarified use of "application groups".

   *  Revised use of protocols and transport profiles with Broker and KDC.

   *  Revised presentation of authorization flow.

   *  Subscribers cannot be anonymous anymore.

*  Revised scope definition.

* Revised Join Response.

 * Revised COSE countersignature, COSE encrypt objects.

 * Clarified, revised, and made editorial improvements throughout.

Kind regards,
--Cigdem

On Wed, 13 Sept 2023 at 23:40,  wrote:

> Internet-Draft draft-ietf-ace-pubsub-profile-07.txt is now available. It
> is a
> work item of the Authentication and Authorization for Constrained
> Environments
> (ACE) WG of the IETF.
>
>Title:   Publish-Subscribe Profile for Authentication and Authorization
> for Constrained Environments (ACE)
>Authors: Francesca Palombini
> Cigdem Sengul
> Marco Tiloca
>Name:draft-ietf-ace-pubsub-profile-07.txt
>Pages:   43
>Dates:   2023-09-13
>
> Abstract:
>
>This document defines an application profile of the Authentication
>and Authorization for Constrained Environments (ACE) framework, to
>enable secure group communication in the Publish-Subscribe (pub/sub)
>architecture for the Constrained Application Protocol (CoAP) [draft-
>ietf-core-coap-pubsub], where Publishers and Subscribers communicate
>through a Broker.  This profile relies on protocol-specific transport
>profiles of ACE to achieve communication security, server
>authentication, and proof-of-possession for a key owned by the Client
>and bound to an OAuth 2.0 Access Token.  This document specifies the
>provisioning and enforcement of authorization information for Clients
>to act as Publishers and/or Subscribers, as well as the provisioning
>of keying material and security parameters that Clients use for
>protecting their communications end-to-end through the Broker.
>
>Note to RFC Editor: Please replace "[draft-ietf-core-coap-pubsub]"
>with the RFC number of that document and delete this paragraph.
>
> The IETF datatracker status page for this Internet-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-07.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-pubsub-profile-07
>
> Internet-Drafts are also available by rsync at:
> rsync.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-pubsub-profile-06.txt

[Cigdem Sengul]

Dear ACE,
With this update, we have aimed to make progress in the to-do presented in
the interim. More specifically:
 - Clarified Client workflow and describe KDC discovery as close as
possible to core pub-sub.
-   AIF-PUBSUB-GROUPCOMM Scope - added support for admin role for
future-proofing; added delete role
-  Clarified Cose_key returned in Join Response and AEAD nonce construction
based on a sender ID provided by the KDC (Partial IV is the message
sequence number, Base IV provided by the KDC).
-  Checked off most Finalise Groupcomm Required and Optional List with the
exception of the group rekeying further to be clarified.

Kind regards,
--Cigdem

On Mon, 13 Mar 2023 at 08:59,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Authentication and
> Authorization for Constrained Environments (ACE) WG of the IETF.
>
>Title   : Publish-Subscribe Profile for Authentication and
> Authorization for Constrained Environments (ACE)
>Authors : Francesca Palombini
>      Cigdem Sengul
>  Marco Tiloca
>Filename: draft-ietf-ace-pubsub-profile-06.txt
>Pages   : 37
>Date: 2023-03-13
>
> Abstract:
>This document defines an application profile for enabling secure
>group communication for a constrained Publish-Subscribe (pub/sub)
>scenario, where Publishers and Subscribers communicate through a
>broker, using the ACE framework.  This profile relies on transport
>layer or application layer security profiles of ACE to achieve
>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 document describes how to request and provision keying material
>for group communication, and protect the content of the pub/sub
>client message exchange, focusing mainly on the pub/sub scenarios
>using the Constrained Application Protocol (CoAP)
>[I-D.ietf-core-coap-pubsub].
>
> The IETF datatracker status page for this Internet-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-06.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-pubsub-profile-06
>
> Internet-Drafts are also available by rsync at rsync.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] Meeting in Yokhohama ?

[Cigdem Sengul]

Hello Daniel,
I may not be able to attend IETF 116 due to a clash with other commitments,
but if I can, it will have to be remote.
Kind regards,
--Cigdem

On Wed, 7 Dec 2022 at 14:57, Daniel Migault  wrote:

> Hi,
>
> We would like to consider meeting in the IETF 116 in Yokohama. To confirm
> the meeting request, we would like to get an idea of:
> 1-  who is planning to attend the session remotely or face to face as well
> as
> 2 - what should be discussed that cannot be discussed during interim
> meetings
>
> Yours,
>
> Daniel
>
>
>
> --
> Daniel Migault
> Ericsson
> ___
> 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-pubsub-profile-05.txt

[Cigdem Sengul]

Dear Ace,
As discussed in the previous interim, I've revised the document to more
closely align with the groupcomm specification, expanding the specification
to describe the KDC resources hosted and operations permitted. In addition,
MQTT-related discussion is  mostly removed, and the document mainly focuses
CoAP pub/sub,
There are still several ToDo items - more specifically, the authentication
credentials and group key definitions/examples to be fixed (aligning with
the more recent specifications different than what was originally proposed
for this document) and group rekeying mechanisms to be finalised.

Kind regards,
--Cigdem

On Fri, 16 Dec 2022 at 23:51,  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-05.txt
>   Pages   : 30
>   Date: 2022-12-16
>
> Abstract:
>This specification defines an application profile for authentication
>and authorization for Publishers and Subscribers in a constrained
>pub-sub scenario, using the ACE framework.  This profile relies on
>transport layer or application layer security to authorize the pub-
>sub clients to the broker.  Moreover, it describes the use of
>application layer security to protect the content of the pub-sub
>client message exchange through the broker.  The profile mainly
>focuses on the pub-sub scenarios using the Constrained Application
>Protocol (CoAP) [I-D.ietf-core-coap-pubsub].
>
>
> 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-05.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-pubsub-profile-05
>
>
> Internet-Drafts are also available by rsync at rsync.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] interim-2022-ace-01 interim approved

[Cigdem Sengul]

Hello Daniel,
I can give a verbal update on pub-sub without slides tomorrow but in short
I am revising the document to align with the latest key-groupcomm and with
the goal of closing as many issues as possible. There are some open points
about the cose object which are documented in the wg emails reviewing the
document and on github issues.

I will submit a new version soon but some todos will remain in the
document, which will need to be resolved with Francesca and I am not
knowledgeable about some earlier design decisions.
Kind regards,




On Thu, 8 Sep 2022 at 14:08, Daniel Migault  wrote:

> Hi,
>
> As of today, we do not have received any agenda item. Let us know by the
> end of the day if you are willing to present.
>
> As a reminder, here is  where we think we are with the various documents.
> Please take the necessary actions to ensure the documents make consequent
> progress.
> https://mailarchive.ietf.org/arch/msg/ace/4i2kmdJ7owsXfrhbse8UP1CSMhA/
>
> Yours,
> Daniel
>
>
> On Mon, Aug 29, 2022 at 8:57 AM Daniel Migault 
> wrote:
>
>> Hi,
>>
>> Please find the virtual meeting information. Let us know if you are
>> planning to present.
>>
>> Yours,
>> Daniel
>>
>> -- Forwarded message -
>> From: IETF Meeting Session Request Tool 
>> Date: Mon, Aug 29, 2022 at 8:53 AM
>> Subject: interim-2022-ace-01 interim approved
>> To: , 
>>
>>
>>
>> An interim meeting for ace has been approved or does not require
>> additional approval.
>> A message has been sent to the secretariat requesting the interim be
>> announced.
>>
>>
>> -
>> Working Group Name: Authentication and Authorization for Constrained
>> Environments
>> Area Name: Security Area
>> Session Requester: Daniel Migault
>>
>> Meeting Type: Virtual Meeting
>>
>> Session 1:
>>
>> Date: 2022-09-12
>> Start Time: 10:00 America/New_York
>> Duration: 01:00
>> Remote Participation Information:
>> https://meetings.conf.meetecho.com/interim/?short=24c81a1f-7240-4990-a8ae-8b46a94e8b1b
>> Agenda Note:
>>
>> -----
>>
>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>
>
> --
> Daniel Migault
> Ericsson
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
-- 

Dr Cigdem Sengul

Reader

ACM-W Communications Co-Chair
*E* cigdem.sen...@brunel.ac.uk

*Brunel University London*
Dept of Computer Science

Brunel University London, Uxbridge, UB8 3PH, United Kingdom
*T* +44(0)1895 274000
*www.brunel.ac.uk <http://www.brunel.ac.uk/>*
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-17.txt

[Cigdem Sengul]

Dear Ace,
This version contains the text revisions to the AIF registration, Carsten
kindly made, and 2 minor fixes for improving clarity and addressing
reviewer COMMENT.

Kind regards,
--Cigdem

On Wed, 23 Mar 2022 at 09:08,  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-17.txt
> Pages   : 45
> Date: 2022-03-23
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (Broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-17
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-17
>
>
> Internet-Drafts are also available by rsync at rsync.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] Murray Kucherawy's No Objection on draft-ietf-ace-mqtt-tls-profile-16: (with COMMENT)

[Cigdem Sengul]

Dear Murray,

Thank you. artart review comments were addressed in this pull request
.
I aimed to address your other comments in this commit
,
which was part of the pull request.
(All other commits have applied, I haven't realised this didn't take
effect.) I will re-apply.
Kind regards,
--Cigdem



On Tue, 22 Mar 2022 at 12:19, Murray Kucherawy via Datatracker <
nore...@ietf.org> wrote:

> Murray Kucherawy has entered the following ballot position for
> draft-ietf-ace-mqtt-tls-profile-16: 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/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/
>
>
>
> --
> COMMENT:
> --
>
> Thanks to Jean Mahoney for her ARTART review.  I encourage the authors to
> respond at least to what she identified as minor issues.
>
> Thanks for resolving my DISCUSS issue.
>
> The final SHOULD in Section 2.4.2 seems weak to me.  I recommend using a
> non-BCP 14 "should" instead.
>
>
>
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-16.txt

[Cigdem Sengul]

Dear Ace,
This version includes the fixes resulting from the IESG, artart, and genart
reviews. All DISCUSS and COMMENTS were addressed, including the
registration of Tperm and Toid required for MQTT AIF.
Kind regards,
--Cigdem

On Mon, 21 Mar 2022 at 22:19,  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-16.txt
> Pages   : 45
> Date: 2022-03-21
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (Broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-16
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-16
>
>
> Internet-Drafts are also available by rsync at rsync.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] Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

[Cigdem Sengul]

Dear all,

Thank you for your reviews.
I have compiled all the remaining fixes based on the received
DISCUSS/COMMENT inputs in this pull request
<https://github.com/ace-wg/mqtt-tls-profile/pull/106>.
All comments and suggestions were acted on. I have put the fixes proposed
for two DISCUSS below as well.

Murray:

--
DISCUSS:
--

This should be quick to resolve.  In Section 3.2:

   The Broker MUST NOT forward messages to unauthorized subscribers.
   There is no way to inform the Clients with invalid tokens that an
   authorization error has occurred other than sending a DISCONNECT
   packet.  Therefore, the Broker SHOULD send a DISCONNECT packet with
   the reason code '0x87 (Not authorized)'.

This seems like a contradiction.  How is that SHOULD not a MUST?

[CS]: The text is now revised to say:
The Broker MUST NOT forward messages to unauthorized subscribers.  To
   avoid silently dropping messages, the Broker MUST close the network
   connection and SHOULD inform the affected subscribers.  The only way
   to inform a client, in this case, would be sending a DISCONNECT
   packet.  Therefore, the Broker SHOULD send a DISCONNECT packet with
the reason code 0x87 (Not authorized) before closing the network
   connection to these clients.

>From Francesca:
--
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]: I have added a new AIF section as discussed registering Toid, and
Tperm with "pub" and "sub" values.
The specific commit here
<https://github.com/ace-wg/mqtt-tls-profile/pull/106/commits/7c17a3f017f42ad795fab277c7983b147eeb40fd>

Let me know if this pull request addresses your DISCUSS, and I will publish
a new ID.

Kind regards,
--Cigdem

On Thu, 10 Mar 2022 at 16:08, Cigdem Sengul  wrote:

> Dear Murray,
>
> Got it - I realise I wasn't clear with SHOULD  -  indeed the implementer
> has limited discretion on what can happen: send the DISCONNECT, close
> connection or drop the connection. I will discuss this with Ben but am
> happy to add the additional text about dropping the connection.
>
> Kind regards,
> --Cigdem
>
> On Thu, 10 Mar 2022 at 15:23, Murray S. Kucherawy 
> wrote:
>
>> Hi Cigdem,
>>
>> On Thu, Mar 10, 2022 at 12:54 AM Cigdem Sengul 
>> wrote:
>>
>>> Thank you for your review. Our thinking was as Ben explained.
>>> In the draft, we used MUST/MUST NOT for the behaviour that affected
>>> security, and SHOULD for desired behaviour.
>>>
>>
>> This doesn't match my understanding of how BCP 14 is supposed to be
>> used.  MUST describes something obligatory for either interoperability,
>> security, or operational reasons, and SHOULD is something where the
>> implementer has limited discretion; when using SHOULD (or SHOULD NOT), it's
>> desirable to include text describing when one might legitimately do
>> something other than what's being stated.
>>
>> In this particular case, what I'm reading is paraphrased as: "In this
>> situation, there's exactly one thing you can legitimately do within this
>> protocol, and you SHOULD do that."  This doesn't make sense to me.  What
>> Ben is saying is that there is a second option, which is to simply close
>> the connection.  If you want to leave this as a SHOULD, I suggest adding
>> text saying exactly that.
>>
>> Would the following revision make it more clear:
>>> "The Broker MUST NOT forward messages to unauthorized subscribers and
>>> SHOULD inform them of authorisation failure.
>>> The only way to inform the client, in this case, would be sending a
>>> DISCONNECT packet.
>>> Therefore, the Broker SHOULD send a DISCONNECT packet with 

Re: [Ace] Murray Kucherawy's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

[Cigdem Sengul]

Dear Murray,

Got it - I realise I wasn't clear with SHOULD  -  indeed the implementer
has limited discretion on what can happen: send the DISCONNECT, close
connection or drop the connection. I will discuss this with Ben but am
happy to add the additional text about dropping the connection.

Kind regards,
--Cigdem

On Thu, 10 Mar 2022 at 15:23, Murray S. Kucherawy 
wrote:

> Hi Cigdem,
>
> On Thu, Mar 10, 2022 at 12:54 AM Cigdem Sengul 
> wrote:
>
>> Thank you for your review. Our thinking was as Ben explained.
>> In the draft, we used MUST/MUST NOT for the behaviour that affected
>> security, and SHOULD for desired behaviour.
>>
>
> This doesn't match my understanding of how BCP 14 is supposed to be used.
> MUST describes something obligatory for either interoperability, security,
> or operational reasons, and SHOULD is something where the implementer has
> limited discretion; when using SHOULD (or SHOULD NOT), it's desirable to
> include text describing when one might legitimately do something other than
> what's being stated.
>
> In this particular case, what I'm reading is paraphrased as: "In this
> situation, there's exactly one thing you can legitimately do within this
> protocol, and you SHOULD do that."  This doesn't make sense to me.  What
> Ben is saying is that there is a second option, which is to simply close
> the connection.  If you want to leave this as a SHOULD, I suggest adding
> text saying exactly that.
>
> Would the following revision make it more clear:
>> "The Broker MUST NOT forward messages to unauthorized subscribers and
>> SHOULD inform them of authorisation failure.
>> The only way to inform the client, in this case, would be sending a
>> DISCONNECT packet.
>> Therefore, the Broker SHOULD send a DISCONNECT packet with the reason
>> code '0x87 (Not authorized)'. "
>>
>
> That's also less dissonant, yes.  This was just discussed with Ben on the
> IESG call and I'll let him guide you on which change is more aligned with
> what you're trying to do.
>
> -MSK
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Francesca Palombini's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

[Cigdem Sengul]

Hello Francesca,

Thank you. I welcome these suggestions - I do not foresee other permission
keywords looking at the MQTT vocabulary (control packets); happy to
"hard-code" "pub" and "sub".
If there aren't any other opinions, I will implement them this way.
There are a  few other minor clarifications I am waiting for feedback, and
with those clarified, I will be ready to publish a new ID.

Kind regards,
--Cigdem



On Thu, 10 Mar 2022 at 12:35, Francesca Palombini <
francesca.palomb...@ericsson.com> wrote:

> 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 <
> draft-ietf-ace-mqtt-tls-prof...@ietf.org>, ace-cha...@ietf.org <
> ace-cha...@ietf.org>, Ace Wg , Daniel Migault <
> daniel.miga...@ericsson.com>, 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 <
> 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 

Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)

[Cigdem Sengul]

Dear Roman,
Thank you for your comments.  I tried to respond to them inline below.
(I have made fixes here: https://github.com/ace-wg/mqtt-tls-profile/pull/104
)

On Tue, 8 Mar 2022 at 23:02, Roman Danyliw via Datatracker 
wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-ace-mqtt-tls-profile-15: 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/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/
>
>
>
> --
> COMMENT:
> --
>
> ** Section 2.
>
>If the Client is resource-constrained or does not support HTTPS, a
>separate Client Authorization Server may carry out the token request
>on behalf of the Client, and later, onboard the Client with the
>token.
>
> Appreciating that the CAS is out of scope, I’m trying to understand which
> of
> the (A) – (F) interactions are handled by the Client and which would be
> handled
> by the CAS.  Figure 1 is a ambiguous.  (A) and (B) seem like they would be
> covered by the CAS, but I’m assuming (C) and (D) are the Client after being
> provisioned with the access token (from A and B).  Is that correct?  If
> so, it
> would be helpful to clarify that in the text and/or diagram.
>

[That is correct. CAS was expected to be helpful for clients that are not
able to do the HTTPS.
We have a CAS definiton in 1.2 -

Client Authorization Server (CAS)
   An entity that prepares and endorses authentication and
   authorization data for a Client, and communicates using HTTPS
   to the AS.


In the figure, we tried to capture the two separately: (1) Client
Authorization interface,

and (2) MQTT Pub/Sub Interface.

Client may be able to do both (1) and (2), or rely on CAS for (1), and
is expected to be provisioned

with a otken for Pub/Sub Interface if aiming to publish/subscribe to
proteced topics.


We had the following text in the document:
" If the Client is resource-constrained or does not support HTTPS, a

   separate Client Authorization Server may carry out the token request
   on behalf of the Client, and later, onboard the Client with the
   token. "


Is revising it so that we point to the figure sufficient clarification?

" If the Client is resource-constrained or does not support HTTPS, a

   separate Client Authorization Server may carry out the token request
   on behalf of the Client (Figure 1 (A) and (B)), and later, onboard
the Client with the
   token.

]



> ** Section 3.3.
>As a response to the SUBSCRIBE packet, the Broker issues a SUBACK.
>For each Topic Filter, the SUBACK packet includes a return code
>matching the QoS level for the corresponding Topic Filter.  In the
>case of failure, the return code is 0x87, indicating that the Client
>is 'Not authorized'.  A reason code is returned for each Topic
>Filter.
>
> This may be a detail of MQTT.  Does the explicit use of “not authorized”
> vs.
> “not authorized/not found” leak the existence of a topic name to an
> off-path
> attacker?  It seems that with “not authorized” semantics, one could try to
> guess topic name with enumeration, say, try 1:
> “/topic/is-the-sensitive-project-called-A”, try 2:
> “/topic/is-the-sensitive-project-called-B”, etc.
>

[CS : I see your point. MQTT has also the following error code:

0x80

Unspecified error

The subscription is not accepted and the Server either does not wish to
reveal the reason or none of the other Reason Codes apply.

We can add: "The Broker MAY return 0x80 Unspecified error if they do not
want to leak the topic names to unauthorised clients."
Would that be OK?
]


> Editorial Nits
>
> ** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS
> communication/
>
[CS: This was changed to "The client-AS and RS-AS exchanges" based on
artart review.]

>
> ** Section 1.3.  Editorial.  Chose either the “65535” or “65,535”
> convention
> (comma or no comma).  “UTF-8 string” uses the former and “binary data”
> uses the
> latter
>
[CS: Fixed to 65535]

>
> ** Section 1.2. Editorial.  SUBACK.  Describe the who is the sender and
> receiver like in the other message types.
>
> OLD
> Subscribe acknowledgement.
>
> NEW
> Subscribe acknowledgement from the Broker to the Client.
>
[CS: Fixed]

>
> ** Section 2.  Editorial.
>The token request and
>response use the token endpoint at the AS, specified for HTTP-based
>interactions in Section 5.8 of the ACE framework
>[I-D.ietf-ace-oauth-authz].
>
> This reference should 

Re: [Ace] Francesca Palombini's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

[Cigdem Sengul]

Hello Francesca,

Thank you for your feedback. My response is below.

On Thu, 10 Mar 2022 at 10:03, Francesca Palombini via Datatracker <
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 the names "pub", "sub".

   The Reference column for all of these entries will be [[This
   document]].


Are there any other registries involved?
Thanks,


>
>
> --
> COMMENT:
> --
>
> Thank you for the work on this document
>
> Many thanks to Jean Mahoney for her ART ART review:
> https://mailarchive.ietf.org/arch/msg/art/REdbeKR0FBJ1CnVtKOUaJnaeONk/,
> and to
> the authors for addressing it.
>
> Only two minor comments easy to fix, see below.
>
> Francesca
>
> 1. -
>
> FP: Please replace references to RFC7230 with
> draft-ietf-httpbis-semantics-19
> which will obsolete it once published. Note that
> draft-ietf-httpbis-semantics-19 is already with the RFC Editor so will not
> delay publication of your document.
>
> 2. -
>
> Section 7.3
>
> FP: I believe this profile should be registered in the Standards track
> portion
> of the registry - please add a note about it so that IANA is aware,
> changing
> for example:
>
> OLD:
> *  CBOR Value: To be assigned by IANA
> NEW:
> *  CBOR Value: To be assigned by IANA in the (-256, 255) range
>
>
>
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Murray Kucherawy's Discuss on draft-ietf-ace-mqtt-tls-profile-15: (with DISCUSS and COMMENT)

[Cigdem Sengul]

Hello Murray,

Thank you for your review. Our thinking was as Ben explained.
In the draft, we used MUST/MUST NOT for the behaviour that affected
security, and SHOULD for desired behaviour.

Would the following revision make it more clear:
"The Broker MUST NOT forward messages to unauthorized subscribers and
SHOULD inform them of authorisation failure.
The only way to inform the client, in this case, would be sending a
DISCONNECT packet.
Therefore, the Broker SHOULD send a DISCONNECT packet with the reason code
'0x87 (Not authorized)'. "

Jean Mahoney's comments have been addressed in the following, and there is
one clarification left that we are working on.
https://github.com/ace-wg/mqtt-tls-profile/pull/102
https://github.com/ace-wg/mqtt-tls-profile/pull/102/commits/75ac0c0a86812f359471a63f6b481b0b80482b97

I thought I should respond to these comments fast and will fix your other
two comments asap.


Kind regards,
--Cigdem

On Thu, 10 Mar 2022 at 06:37, Benjamin Kaduk  wrote:

> On Wed, Mar 09, 2022 at 10:35:01PM -0800, Murray Kucherawy via Datatracker
> wrote:
> > Murray Kucherawy 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:
> > --
> >
> > This should be quick to resolve.  In Section 3.2:
> >
> >The Broker MUST NOT forward messages to unauthorized subscribers.
> >There is no way to inform the Clients with invalid tokens that an
> >authorization error has occurred other than sending a DISCONNECT
> >packet.  Therefore, the Broker SHOULD send a DISCONNECT packet with
> >the reason code '0x87 (Not authorized)'.
> >
> > This seems like a contradiction.  How is that SHOULD not a MUST?
>
> I suppose you could also be less informative and just drop the transport
> connection with no DISCONNECT (or simply hold it open while passing no
> traffic).
> I think that's what I had in mind when I reviewed this with the SHOULD.
>
> -Ben
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Lars Eggert's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)

[Cigdem Sengul]

Dear Lars,

Thank you very much for your comments - I especially appreciated the nudge
for inclusive language and tried to address them as best as I could.
I know it was stated that there was no need to inform changes, but let me
share the PR

 still.
Explanations of fixes/comments if left unchanged are also inline.
Kind regards,
--Cigdem

On Mon, 7 Mar 2022 at 09:31, Lars Eggert via Datatracker 
wrote:

> Lars Eggert has entered the following ballot position for
> draft-ietf-ace-mqtt-tls-profile-15: No Objection
>
>
>
> 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/
>
>
>
> --
> COMMENT:
> --
>
> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Term "master"; alternatives might be "active", "central", "initiator",
>"leader", "main", "orchestrator", "parent", "primary", "server".
>

[CS:  I would like to indeed avoid this work, but it appears as a result of
using "Extended Master Secret".
 Has this been replaced with an alternative?]

>
>  * Term "his"; alternatives might be "they", "them", "their".
>
[CS: The word appears in acknowledgements to thank specific people;
however, happy to change it to their pronouns,
if "his" doesn't apply.]

>
>  * Term "invalid"; alternatives might be "not valid", "unenforceable", "not
>binding", "inoperative", "illegitimate", "incorrect", "improper",
>"unacceptable", "inapplicable", "revoked", "rescinded".
>

[CS: Fixed except in two places where the word appears as part of a
standard MQTT error response.]

>
> Thanks to Theresa Enghardt for their General Area Review Team (Gen-ART)
> review
> (https://mailarchive.ietf.org/arch/msg/gen-art/-D0Fe7Px8IRU5yIFmngv6SR420c
> ).
>
>
> ---
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> Section 2.1. , paragraph 5, nit:
> >This document follows [RFC7800] for PoP semantics for JWTs (CWTs can
> >also be used).  The PoP token includes a 'cnf' parameter with a
>
> s/can/MAY/ ?
>
[CS: Fixed.]


>
> Section 2.2.2. , paragraph 4, nit:
> -DISCONNECT packet as explained below.
> +DISCONNECT packet, as explained below.
> + +
>

[CS: The problematic text no longer exists]

>
> Section 2. , paragraph 4, nit:
> > e RPK case is handled as described in in Section 3.2.1 of the DTLS
> profile [
> >^
> Possible typo: you repeated a word.
>
[CS: Fixed.]

>
> Section 2.2.1. , paragraph 2, nit:
> > lient MUST validate a public key from a X.509 certificate or an RPK from
> the
> >   ^
> Use "an" instead of "a" if the following word starts with a vowel sound,
> e.g.
> "an article", "an hour".
>
[CS: Looks correct, kept as is.]

>
> Section 2.2.1. , paragraph 7, nit:
> >  equal to 0, and the token is invalid or the claims cannot be obtained
> in the
> >  ^^^
> Use a comma before "or" if it connects two independent clauses (unless
> they are
> closely connected and short).
>
 [CS: Looks correct, kept as is.]

>
> Section 2.2.3. , paragraph 2, nit:
> > to an earlier proposal by Fremantle et al [fremantle14]. After sending
> the C
> > ^
> A period is misplaced or missing.
>
[CS: Looks correct, kept as is.]

>
> Section 2.2.4.2. , paragraph 3, nit:
> >  as shown in Figure 7 and includes the the 8-byte Client nonce, and the
> signa
> >^^^
> Possible typo: you repeated a word.
>
[CS: fixed]

>
> Section 2.2.5. , paragraph 3, nit:
> > ame or filter in question is either an an exact match to or a subset of
> at le
> > ^
> Possible typo: you repeated a word.
>
 [CS: The problematic text no longer exists]

>
> Section 2.4.1. , paragraph 3, nit:
> > est for topic "a/b/*", and has a token token permits "a/*", this is a
> valid s
> >  ^^^
> Possible typo: you repeated a word.
>
[CS: The problematic text no longer exists]

>
> Section 10.1. , paragraph 23, nit:
> >  broker. * 

Re: [Ace] [Last-Call] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14

[Cigdem Sengul]

Fixed back in the new commit. Thank you! I wasn't sure how to react to
downref comment.

On Wed, 9 Mar 2022 at 23:39, Benjamin Kaduk  wrote:

> On Wed, Mar 09, 2022 at 11:27:40PM +, Francesca Palombini wrote:
> >
> > 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/.
>
> Exactly so.  Thanks for the quick clarification, Francesca!
>
> -Ben
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14

[Cigdem Sengul]

Hello Jean,

Thank you for your feedback on the changes.
I have updated the pull request with a new commit:
https://github.com/ace-wg/mqtt-tls-profile/pull/102/commits/75ac0c0a86812f359471a63f6b481b0b80482b97

Responses to questions/comments are inline below.

On Wed, 9 Mar 2022 at 23:18, A. Jean Mahoney  wrote:

> Cigdem,
>
> Thank you for reply and for incorporating the feedback into a PR. I have
> few comments and questions below.
>
>
> > 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?
>
> [JM] I think that is okay. The document shepherd indicated in his
> writeup that he thinks the MQTT reference should be normative
> (
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/shepherdwriteup/).
>
>
> [CS: OK, will leave as is.]


>
> >
> > 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.
> > ]
>
> [JM] This is better, but the last half of the last sentence could be
> interpreted as saying "MUST NOT be empty and MUST NOT contain...".
> Perhaps it could just say "the Authentication Data MUST contain an
> 8-byte RS nonce..."?
>

[CS: True, revised as your suggestion.]


>
> >
> >
> > 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?
> > ]
>
> [JM] I like the added example. As someone unfamiliar with MQTT, I was
> wondering what "necessary policies" might look like. That is, if I were
> to build a Broker implementation, what sort of things SHOULD my
> implementation be doing here? An example or two might clarify.
>

[CS: The example regarding defining an automated response based on storage
capabilities come from the MQTT standard.
The standard itself does not define policies explicitly. I changed the
wording from "necessary policies" to "administrative policies" to avoid
misunderstanding. Such policies may include setting quotas on storage,
connection rates etc, but since they are not explained as such in the MQTT
standard, I would like to avoid specifying them here as well]

>
>
> >
> >-- Possible downref: Non-RFC (?) normative reference: ref.
> >   'MQTT-OASIS-Standard'
> >
> >-- Possible downref: Non-RFC (?) normative reference: ref.
> >   'MQTT-OASIS-Standard-v5'
> >
> >
> > [CS: OK for these two, I feel on the fence as the document is about MQTT.
> > Is the downref suggested because this is a Non-RFC and a standard coming
> > from OASIS]
>
> [JM] The idnits script calls out any normative reference that is not a
> Standards Track RFC. Documents from other standards bodies can be
> approved by the IESG to be listed in the Normative References section.
> The MQTT refs shouldn't be an issue. More info about downrefs can be
> found in RFC 8067.
>

[CS: Thanks, then I will keep things as they are.]

>
> >
> >
> >** Downref: Normative reference to an Informational RFC: RFC 6234
> >
> >
> > [CS: Moved to Informative references]
>
> [JM] RFC 6234 should be okay as a normative reference because it has
> been normatively referenced in other RFCs
> (https://datatracker.ietf.org/doc/rfc6234/referencedby/) and the
> following sentence says "mandatory to implement":
>
> HS256 (HMAC-SHA-256) [RFC6234] and Ed25519 [RFC8032] are mandatory
> to implement for the Broker.
>
[CS: OK, moved back to normative]

>
> >
> >
> >** Downref: Normative reference to an Informational RFC: RFC 7251
> >
> >

Re: [Ace] Artart last call review of draft-ietf-ace-mqtt-tls-profile-14

[Cigdem Sengul]

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 
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
> (https://datatracker.ietf.org/doc/downref).
>
>   == Unused Reference: 'I-D.ietf-ace-oauth-params' is defined on line 1499,
>  but no explicit reference was found in the text
>

[CS: This is fixed based on the revision for genart review, and the ID is
referenced.]


>
>   == Unused Reference: 'RFC7251' is defined on line 1563, but no explicit
>  reference was found in the text

[CS: Reference removed; added RFC 8442 for the PSK cipher reference]

>
>   == Unused Reference: 'RFC8422' is defined on line 1609, but no explicit
>  reference was found in the text
>

[CS: Now cited]

>
>   == Unused Reference: 'RFC8705' is defined on line 1625, but no explicit
>  reference was found in the text
>
[CS: Removed as does not apply to the current text]

>
>   -- Possible downref: Non-RFC (?) normative reference: ref.
>  'MQTT-OASIS-Standard'
>
>   -- Possible downref: Non-RFC (?) normative reference: ref.
>  'MQTT-OASIS-Standard-v5'
>

[CS: OK for these two, I feel on the fence as the document is about MQTT.
Is the downref suggested because this is a Non-RFC and a standard coming
from OASIS]


>
>   ** Downref: Normative reference to an Informational RFC: RFC 6234
>

[CS: Moved to Informative references]

>
>   ** Downref: Normative reference to an Informational RFC: RFC 7251
>

[CS: Reference 

Re: [Ace] Genart last call review of draft-ietf-ace-mqtt-tls-profile-15

[Cigdem Sengul]

Hello,
I've created a new pull request for the changes:
https://github.com/ace-wg/mqtt-tls-profile/pull/101
Explanations are below.

>
>
> > > [CS: Introduced a formal definition of Network Connection to
> > > MQTT-related terminology - as defined in MQTT standard.
> > > To the Will definition, added the situations when the connection is
> > > considered not to have closed normally.
> > > Question: Normal disconnection is DISCONNECT with reason code is 0x00,
> > > according to MQTT standard - is this definition also needed?"
> >
> > [TE] So "not closed normally" means any way to terminate the Network
> > Connection, other than DISCONNECT with reason code 0x00? If so, I think
> > this would be a good addition to the definition, either as its own
> > definition or added to the "Will" definition.
>
> I think that's right, but Cigdem knows MQTT better than me and she should
> confirm.
>
[CS: Yes, added the DISCONNECT packet definition. I also took the MQTT
standard text to specify more formally
situations for sending a Will, which included a definition for normal
disconnection. I reduced the Will-specific text in the
main document, as this definition now is comprehensive.]


>
> >
> > >
> > > Section 2.1
> > >
> > > [CS: Added for cnf:
>
> > >
> > > rs_cnf:
>
> >
> > [TE] These explanations already help, thanks! However, and this might
> > just be me, but I keep wondering what 'cnf' stands for, i.e., if it is
> > an acronym for something, and if it is, if it makes sense to expand the
> > acronym. But it might just be a string that comes from "somewhere",
> > which is fine with me, too. :)
>
> I think the lineage of "cnf" can be traced back to at least RFC 7800, so at
> this point it's probably a fairly well established part of the greater
> OAuth ecosystem.
>
> Which is not to say that we can't try to make the document more accessible
> to new readers, of course.  The ACE framework itself relies pretty heavily
> on proof of possession semantics for JWT/CWT tokens, so perhaps the
> implicit reliance on draft-ietf-ace-oauth-authz and its terminology would
> suffice.  Happy to hear further thoughts.
>

[CS: Added   --> 'cnf' (confirmation) claim in its first instance. We are
referencing the params document as well for both confirmation related
claims (cnf, rs_cnf). Would this be enough?]

Kind regards,
--Cigdem



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

Re: [Ace] Genart last call review of draft-ietf-ace-mqtt-tls-profile-15

[Cigdem Sengul]

Dear Theresa,
Thank you very much for the comments.

I have prepared a revised version, where the changes can be found in the
following pull request:
 https://github.com/ace-wg/mqtt-tls-profile/pull/99

If you are happy with these changes, I can submit a new ID.
I also explain the changes below, inline.

>
>
> Minor issues:
>
> Section 1:
>
> "The token MAY be a
>reference or JSON Web Token (JWT) [RFC7519]."
> What is a reference in this context?
>

[CS: Added: "opaque reference to authorization information"]



>
> Section 1.3:
>
> "Will
>If the network connection is not closed normally, […]"
> I suggest to make this a bit more specific:
> Does "the network connection" refer to a TCP connection, or a TLS session?
> Or
> does it refer to MQTT's notion of "connection"? Does "not closed normally"
> mean
> anything other than a FIN-ACK exchange to close a TCP connection? Or does
> it
> depend on the used transport protocol (however, in this document, it
> should all
> refer to TLS over TCP iiuc?) If the notion of a "network connection is not
> closed normally" is a well-defined concept in this context, please provide
> a
> reference if possible.
>

[CS: Introduced a formal definition of Network Connection to MQTT-related
terminology - as defined in MQTT standard.
To the Will definition, added the situations when the connection is
considered not to have closed normally.
Question: Normal disconnection is DISCONNECT with reason code is 0x00,
according to MQTT standard - is this definition also needed?"


>
> Section 2
>
> "Whatever protocol is
>used for C-AS and Broker-AS communications must provide mutual
>authentication, confidentiality protection, and integrity protection."
> Is this a MUST?
>

[CS: Changed to MUST].

>
> Section 2.1
>
> "The PoP token includes a 'cnf' parameter with a
>symmetric or asymmetric PoP key. "
> The 'cnf' (and 'rs_cnf' in Section 2.2.1) parameter is mentioned here and
> in
> some other places, but it is not obvious what it means and why it is
> special/important. I suggest to provide a brief explanation or reference.
>
> [CS: Added for cnf:
The AS includes a 'cnf' parameter to the PoP token,
   to declare that the Client possesses a particular key and RS can
   cryptographically confirm that the Client has possession of that key.
   The 'cnf' parameter is REQUIRED if a symmetric key is used, and MAY
   be present for asymmetric proof-of-possession keys, as described in
   [I-D.ietf-ace-oauth-params].

rs_cnf:
Otherwise, to authenticate the Broker, the Client MUST validate a public
key from a
   X.509 certificate or an RPK from the Broker against the 'rs_cnf'
parameter in the token response, which contains information about the
   public key used by the RS to authenticate if the token type is "pop"
   and asymmetric keys are used as defined in [I-D.ietf-ace-oauth-params].




> 2.2.2
> "If the QoS level is equal to 0, and the token is invalid or the
>claims cannot be obtained in the case of an introspected token, the
>Broker MUST send a DISCONNECT packet with the reason code '0x87 (Not
>authorized)'."
> Does this paragraph apply to all packets or is it specific to the PUBLISH
> packet (like the next paragraph)? I suggest to make this explicit.
>

[CS: Moved the last sentence of the previous paragraph to underline that we
are talking about the PUBLISH packet.
So, it is now:
Depending on the QoS level of the PUBLISH packet, the Broker returns
   the error response as a PUBACK, PUBREC, or DISCONNECT packet.  If the
   QoS level is equal to 0, 
]


>
> Section 2.2.4.1
>
> "Given that clients provide a token at each connection,"
> Does "at each connection" mean in each CONNECT packet, or something else?
> Please clarify.
>

[CS: Clarified as:
 "Given that the Broker MUST associate the Client with a valid token, a
Client will only send or receive messages to its authorized topics.."
(This is becuase the Broker may have saved a token for Client, and Client
may have not provided a Token in Connect, but passed the challenge/response
hence, proving that the stored token is for itself]
]

>
> Nits/editorial comments:
>
> Section 1:
>
> "In this profile, Clients and Servers
>(Brokers) use MQTT to exchange Application Messages.  The protocol
>relies on TLS for communication security between entities."
> Section 1.3 defines MQTT over TLS as MQTTS, and if I understand correctly,
> this
> document requires MQTT between Clients and Servers over TLS, effectively,
> making the document about MQTTS, and it does say "MQTTS" in some places.
> Short
> of substituting all or nearly all "MQTT" with "MQTTS", is it worth
> mentioning
> "MQTTS" once more here in the introduction?
>

[CS: Decided MQTTS is colloquial - as MQTT Standard doesn't refer to it.
So, removed its definition and fixed all instances of MQTTS as MQTT over
TLS]


>
> "MQTT v3.1.1 clients"
> Here, "clients" is lower case, while it is upper case in most other places
> in
> the doc. 

[Ace] ACE profiles registry range for mqtt_tls profile

[Cigdem Sengul]

Dear Ace,

We received an IANA question, quoted below, regarding the registration
range,
and will respond "-256 to 255 Standards Action" as the appropriate range.

Name: mqtt_tls
Description: Profile for delegating Client authentication and authorization
using MQTT for the Client and Broker (RS) interactions, and HTTP for the AS
interactions. TLS is used for confidentiality and integrity protection and
server authentication. Client authentication can be provided either via TLS
or using in-band proof-of-possession at the MQTT application layer.
CBOR Value: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

IANA Question --> Which range in the ACE Profiles registry should this
registration come from?

Kind regards,
--Cigdem
-- 

Dr Cigdem Sengul

Senior Lecturer

ACM-W Europe Communications Chair, and Secretary
*E* cigdem.sen...@brunel.ac.uk

*Brunel University London*
Dept of Computer Science

Brunel University London, Uxbridge, UB8 3PH, United Kingdom
*T* +44(0)1895 274000
*www.brunel.ac.uk <http://www.brunel.ac.uk/>*
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-15.txt

[Cigdem Sengul]

Dear Ace,
This new submission takes into account the final revision suggestions from
Ben, including clarifying the cypher suites.
Kind regards,
--Cigdem

On Tue, 1 Mar 2022 at 23:38,  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-15.txt
> Pages   : 43
> Date: 2022-03-01
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-15
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-15
>
>
> Internet-Drafts are also available by rsync at rsync.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] Last Call: (Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication and Authorization for Constrained Environments (ACE) Framework)

[Cigdem Sengul]

Thank you, Ben.
Kind regards,
--Cigdem

On Thu, 17 Feb 2022 at 23:11, Benjamin Kaduk  wrote:

> I started the last call so as to make the cutoff for the March 10th IESG
> telechat, but noticed a few things in the diff that can be tightened up.
> I will try to send a PR before directorate reviews start trickling in...
>
> Thanks for getting the new version up quickly!
>
> -Ben
>
> On Thu, Feb 17, 2022 at 03:07:40PM -0800, The IESG wrote:
> >
> > The IESG has received a request from the Authentication and
> Authorization for
> > Constrained Environments WG (ace) to consider the following document: -
> > 'Message Queuing Telemetry Transport (MQTT)-TLS profile of
> >Authentication and Authorization for Constrained Environments (ACE)
> >Framework'
> >as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> final
> > comments on this action. Please send substantive comments to the
> > last-c...@ietf.org mailing lists by 2022-03-03. Exceptionally, comments
> may
> > be sent to i...@ietf.org instead. In either case, please retain the
> beginning
> > of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >
> >This document specifies a profile for the ACE (Authentication and
> >Authorization for Constrained Environments) framework to enable
> >authorization in a Message Queuing Telemetry Transport (MQTT)-based
> >publish-subscribe messaging system.  Proof-of-possession keys, bound
> >to OAuth2.0 access tokens, are used to authenticate and authorize
> >MQTT Clients.  The protocol relies on TLS for confidentiality and
> >MQTT server (broker) authentication.
> >
> >
> >
> >
> > The file can be obtained via
> > https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
> >
> >
> >
> > No IPR declarations have been submitted directly on this I-D.
> >
> >
> >
> >
> >
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-14.txt

[Cigdem Sengul]

Dear Ace,
This version updates the document as required for the AD review, mainly
aligning the descriptions to DTLS-profile when TLS is used for client
authentication.

Kind regards,
--Cigdem

On Thu, 17 Feb 2022 at 09:29,  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-14.txt
> Pages   : 43
> Date: 2022-02-17
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-14
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-14
>
>
> Internet-Drafts are also available by rsync at rsync.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-pubsub-profile-04.txt

[Cigdem Sengul]

Dear Ace,
I've uploaded a new version of the pub-sub document before the document
expired on January 1, 2022.
This version partially addresses the review comments of Marco [August 30
and October 12] (Thanks, Marco!).

The new version makes the following changes:
1) Changes to using two authorization requests to AS. One request where the
audience is the broker and the other is the KDC. This approach was
considered more appropriate in IETF 111 discussion and discussion e-mails
with Marco to the group.
2) Change from COSE_Key used as a public key, support UCCS.
3) Various rewording suggestions captured in this Github issue:
https://github.com/ace-wg/pubsub-profile/issues/12
<https://github.com/ace-wg/pubsub-profile/issues/12>
4) Revised discussion around application group to security group mapping,
and MQTT text - discussion captured here:
https://github.com/ace-wg/pubsub-profile/issues/14

There are several open issues, some of which marked as ToDo in the
submitted draft (e.g., multiple publishers protecting topic content, better
alignment to the new KDC interface etc., which can be seen here:
https://github.com/ace-wg/pubsub-profile/issues.
<https://github.com/ace-wg/pubsub-profile/issues>
Therefore, a new version will be uploaded soon again to handle those.

Happy new year to all!

-Cigdem



On Wed, Dec 29, 2021 at 11:00 PM  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-04.txt
> Pages   : 23
> Date: 2021-12-29
>
> Abstract:
>This specification defines an application profile for authentication
>and authorization for Publishers and Subscribers in a constrained
>pub-sub scenario, using the ACE framework.  This profile relies on
>transport layer or application layer security to authorize the pub-
>sub clients to the broker.  Moreover, it describes the use of
>application layer security to protect the content of the pub-sub
>client message exchange through the broker.  The profile covers pub-
>sub scenarios using either the Constrained Application Protocol
>(CoAP) [I-D.ietf-core-coap-pubsub] or the Message Queue Telemetry
>Transport (MQTT) [MQTT-OASIS-Standard-v5] protocol.
>
>
> 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-04.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-pubsub-profile-04
>
>
> Internet-Drafts are also available by rsync at rsync.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] second AD evaluation of draft-ietf-ace-mqtt-tls-profile-13

[Cigdem Sengul]

Hello Ben,
Thank you for your Pull request. I have asked for clarifications in the
following.

On Tue, Dec 7, 2021 at 8:27 PM Benjamin Kaduk  wrote:

> Hi all,
>
> As promised, here are my comments on the -13.
>
>
> I put some text to this effect in my pull request
> (https://github.com/ace-wg/mqtt-tls-profile/pull/96), but technically
> RFC 7250 allows independent negotiation of the client using a RPK and
> the server using a RPK, but our text is written as if it's
> all-or-nothing.  We can probably just make that an assumption of how we
> work and not have to go into detail about how a mixed mode would work.
>
>
[CS:  Yes, that's the assumption made

"If the Client authentication uses TLS:Known(RPK/PSK), then the Broker is

   authenticated using the respective method.  Otherwise, to
   authenticate the Broker, the client MUST validate a public key from a
   X.509 certificate or an RPK from the Broker against the 'rs_cnf'
   parameter in the token response."


Thank you for the suggested text in the pull request.




> Section 1
>
> > Publish requests from the Clients to the Broker and from the Broker to
> > the Clients
>
> I'm not entirely sure how much we say about the second half specifically
> -- do we need to keep that in?
>

[CS: We do cover that in section 3.2 - the Broker needs to check all
subscribing clients to the topic are
still authorised.]

>
> Section 2.2.3.2
>
> The procedures we list here only make sense for TLS 1.3
> If we wanted to support TLS 1.2 with them we'd need to note that a PSK
> ciphersuite is needed and how to populate the PSK identity in the
> ClientKeyExchange, and reference RFC 4279.  I put some text in my PR
> that qualifies this scenario as being TLS 1.3-only on the basis that we
> don't need to go to so much effort to support TLS 1.2+PSK.
>
>

[Making ietf-ace-dtls-authorise normative, and explaining the extent that
profile
applies (now that there is a short extension draft for TLS use), could we
rely on the text for 3.3.2 psk identity field, and
the recommended cipher suite?]



> Section 2.2.4
>
> Figure 7 and its adjacent prose shows the client nonce as variable
> length (or at least, explicit length with no mention of being constant),
> but Figure 8 shows the client nonce as fixed length (8 bytes).
>
> [CS: True. Will revise. We went back and forth variable=length nonce vs
fixed length nonce in the group discussions.
It ended up being fixed-length nonce for the Broker challenge, and
variable-length for Client challenge.
I suggest to have both fixed or both variable?  The argument for 8 bytes
was that it was sufficient as it's a time-bound request/response]



> Section 2.3
>
> We say that the JWT scope value is a single value with internal
> structure as a JSON array, but I think we have to interpret that in the
> context of RFC 6749's definition of scope as a list of space-delimted
> case-sensitive strings.  That is, in the formal grammar, the "scope"
> parameter value is a single string, and any internal spaces in it are
> delimters between the individual scope values.  So, we need to make our
> JWT scope value fit into the expected shape, which in particular means
> we need to be encoded as a string with no internal spaces.  However,
> MQTT does allow spaces in topic names, so the naive formulation of
> encoding the JSON object as a string would artificially limit what
> topics we can authorize the use of.  If we stick with using the "scope"
> like this, we may find ourselves needing to do some percent- or base64-
> encoding of the JSON array to produce a usable scope value...but we
> could also consider something more drastic and switch to using the OAuth
> "Rich Authorization Requests"
> (https://datatracker.ietf.org/doc/draft-ietf-oauth-rar/) that defines a
> new "authorization_details" parameter that is like scope but allows a
> much richer structure.  My understanding is that, while use of
> structured "scope" like we propose is regularly observed in the wild,
> OAuth purists really don't like it, since it's not what scope was
> intended to be about.
>
> (Also, the example in Figure 10 does include spaces in it.)
>

[CS: That's right. I lean towards encoding JSON array base64.  It's because
I understand in RAR, we
need to format the "authorization_details" using the authorization data
elements defined in that draft.

I feel, with AIF-MQTT, we have the sufficient detail for MQTT
permissions on topic filters.]


> Section 5
>
> Apparently I didn't comment on it the first time I read this, but it's
> very interesting to say that the Broker "MUST continue publishing the
> retained messages **as long as the associated tokens are valid**"
> (emphasis mine).  That seems to imply a model where the authorization
> check happens at the Broker->consumer leg, in addition to (or instead
> of?) at the publisher->Broker leg.

To some extent the right behavior
> here depends on what one uses as the definition for "publishing"
> something, but this does set us up for a 

Re: [Ace] AD Evaluation of draft-ietf-ace-mqtt-tls-profile-12

[Cigdem Sengul]

Hello Ben,
No worries. It's been a very busy period for me as well.
My responses are below. Thank you, as always, for your feedback.

On Tue, Dec 7, 2021 at 8:14 PM Benjamin Kaduk  wrote:

> Hi Cigdem,
>
> Oof, has it really been two months since you sent this?  I am sorry to have
> let it linger for so long.
>
> I've gone through the published -13 and have a handful or two of comments
> left (which I will send separately), but let me just reply here to a few
> things first (inline).
>
> On Mon, Oct 18, 2021 at 03:23:12PM +0100, Cigdem Sengul wrote:
> > Hello Ben,
> > I thought I should comment on your original review to have the same order
> > you initially planned.
> > I went through all the comments, and our discussions of it.
> > The comparison with Editor's copy and github draft is here
> > <
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-mqtt-tls-profile.txt=https://ace-wg.github.io/mqtt-tls-profile/draft-ietf-ace-mqtt-tls-profile.txt
> >
> > .
> >
> > In summary, I made the following changes:
> > (1) Kepts dtls profile informative (going through it, I brought all that
> > applied to this draft but kept out the ones that didn't apply). For
> that, I
> > introduced new sections that explains how we support TLS - PSK and RPK
> for
> > client authentication (2.2.3.1 and 2.2.3.2). Aimed to clarify all
> > TLS-related stuff e.g. added recommended references for using TLS in
> > constrained environments, followed the cipher suite requirements from
> these
> > references.
>
> I think I see what you're trying to do here, and it makes sense in a
> certain way ... but if I go and compare side-by-side the text we have here
> and what's in the DTLS profile, the DTLS profile goes into a lot more
> detail.  In particular, the DTLS profile mentions some things that
> implementations need to do in order to avoid vulnerabilities, and I'm not
> sure that we want to go into so much detail in this document when it's
> already recorded elsewhere.  I'm willing to let the document advance to
> IETF LC and IESG review with this part as-is (but will not be surprised if
> other reviewers raise the topic), but just wanted to check if there's a
> particular reason to want the DTLS profile to not be a normative reference.
> I think I don't understand that part of things very well, so to me there's
> not much harm in making it a normative reference -- maybe I'm missing
> something!
>

[Cigdem: I wasn't sure if I could make DTLS profile normative when I was
using TLS, and then there were
a few MUSTs in the DTLS profile that I felt didn't apply. But, given there
is a new short draft that says the profile applies to TLS,
things are in a better place (
https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/).

However, I need input on the following issues before I revise to make DTLS
profile normative, and reorganise the
sections accordingly based on that change i.e., refer more to DTLS sections
in the newly introduced sections,
and shorten them.

The DTLS profile expectedly talks about CoAp, CBOR, COSE (some examples
below).
Also, token expiration is handled differently with MQTT.
Can those be revised for MQTT-TLS profile?
"If the "ace_profile" parameter is present, it is set to "coap_dtls".
"This specification uses CBOR web tokens to convey claims within an access
token issued by the server."
For PSK mode:
"The authorization server adds a "cnf" parameter to the access information
carrying a "COSE_Key" object that informs the client about the shared
secret that is to be used between the client and the resource server. If
the access token carries a symmetric key, the access
   token MUST be encrypted using a "COSE_Encrypt0" structure (see section
7.1 of [RFC8392])."
DTLS channel setup:
 "To do so, it MUST create a "COSE_Key" structure with the "kid" that was
conveyed in the "rs_cnf" claim in the token response from
   the authorization server and the key type "symmetric".
Token expiration:
"As specified in Section 5.10.3 of [I-D.ietf-ace-oauth-authz], the resource
server MUST notify the client with an error response with
   code 4.01 (Unauthorized) for any long running request before terminating
the association."
(The error response for MQTT would be different.)

Also, for PSK,
"If a resource server receives a ClientKeyExchange message that contains a
"psk_identity" with a length greater than zero, it MUST
 parse the contents of the "psk_identity" field as CBOR data structure"
I think this is defined differently in TLS with pre_shared_key extension
etc.
]
 [SNIP]

>
>
> > >
> > >o  "TLS:Anon-MQTT:ace":

Re: [Ace] AD Evaluation of draft-ietf-ace-mqtt-tls-profile-12

[Cigdem Sengul]

Hello Ben,
I thought I should comment on your original review to have the same order
you initially planned.
I went through all the comments, and our discussions of it.
The comparison with Editor's copy and github draft is here

.

In summary, I made the following changes:
(1) Kepts dtls profile informative (going through it, I brought all that
applied to this draft but kept out the ones that didn't apply). For that, I
introduced new sections that explains how we support TLS - PSK and RPK for
client authentication (2.2.3.1 and 2.2.3.2). Aimed to clarify all
TLS-related stuff e.g. added recommended references for using TLS in
constrained environments, followed the cipher suite requirements from these
references.
(2) Added more to the glossary about the MQTT data formats so that it is
clear the data is prefixed with a length field, or how variable length
fields
are computed.
(3) Fixed the MQTT CONNECT figures to show more details, and better
alignment of fields.
(4) Revised the document to explain the Clean Session better.
(5) Revised the document to explain how Will topics are verified to be
authorised, and how the Broker doesn't accept CONNECT if they are not.
(6) Added examples on scopes and wildcard matching for SUBSCRIBE.
(7) Added a section on 2.3 on token scope to explain the scope data
structure.

The detailed changes, and references to Github issues/commits are below.
I've SNIPped the ones that required no action or no
change based on our discussion e-mails.

I will submit a new version - should I wait for your perusal of the changes
(detailed also below)?

Kind regards,
--Cigdem

On Thu, Aug 5, 2021 at 11:39 PM Benjamin Kaduk  wrote:

> Hi all,
>
> Sorry to have taken so long to get back to this, and thank you for
> continuing to make updates in response to the changes in the framework and
> other profiles.
>
> In general, the protocol mechansisms defined here are in good shape;
> thank you!
>
> I made a github PR with some changes that seemed easier to phrase in the
> form of a patch than a prose comment:
> https://github.com/ace-wg/mqtt-tls-profile/pull/77


[Cigdem: Pulled and merged.]

>
>
> I did find a couple of significant issues that need to be addressed
> before IETF LC, but I think any needed changes will be pretty localized.
>
> Specifically, there's no requirement for ACE access tokens to be
> self-deliniating, so we can't actually programmatically tell whether
> there's content after the token in a CONNECT message; the mechanisms in
> Sections 2.2.4.1/2.2.4.2 seem to assume that we can do so for
> determining whether the CONNECT is just providing a token or also
> providing PoP over a TLS exporter value.  I think that this just means
> we need to have an explicit "token length" field (or similar).
>

[CS: This was discussed; no changes as the text already had a "token
length".]


> [SNIP]
>
> A few other general notes before the section-by-section notes:
>
> There is very little in this document about the HTTP-based interactions
> with the AS.  I think the intent is to defer to the core framework for
> that, but being a little more explicit about what is being pulled in and
> how would be helpful.
>
[CS: I assumed this comment was for the token and introspection endpoints.
Added some text to refer to the core document more explicitly.
commit 8a789e024b4576b06a9bccc6673b53ab6a709ab8



>
> If we're using TLS Exporters and allow TLS-not-1.3, we need to make some
> additional requirements on TLS usage in order for the exporter values to
> be safe.  Typically this takes the form of requiring the extended master
> secret extension along with guidance on what cipher suites to use; I
> guess RFC 7925 (rather than 7525) would be the default reference for
> other TLS usage.
>

[CS: Added a new section 2.2.3 Client Authentication over TLS  that makes
these recommendations.]

>
> This document seems to mostly use British English.  AFAIR, that's okay,
> but if it's inconsistent the RFC Editor will prefer American English.  I
> didn't attempt to check for this (though there are tools like
> https://github.com/larseggert/ietf-reviewtool that will do so).
>

[CS: haven't used this particular tool, but I believe inconsistencies are
now fixed.]

>
>
> Section 1
>
>their subscribers.  In the rest of the document the terms "RS", "MQTT
>Server" and "Broker" are used interchangeably.
>
> We will probably get a reviewer asking why we can't pick a single term
> and standardize on it.  However, I expect that there are places where we
> want to emphasize on one aspect or another of its behavior, so don't
> think we should actually do so.  Similarly for the places where we
> mention that CoAP can be used (but don't reference a concrete
> 

Re: [Ace] Review of draft-ietf-ace-pubsub-profile-03

[Cigdem Sengul]

Thanks Marco,
I think the first step is to go through groupcomm revisions, and see how
this profile uses/constrains it better (with group rekeying etc.)
We are in agreement about application vs security groups - although it
looks like we aren't from the text :) - I will give a few more examples,
but with two tokens for each audience (KDC, and Broker) some of the
confusions will disappear regarding scopes and what they mean.
Kind regards,
--Cigdem

On Tue, Oct 12, 2021 at 10:08 AM Marco Tiloca  wrote:

> Hi Cigdem!
>
> Please, see my replies inline, marked as "==>MT".
>
> Thanks,
> /Marco
>
> On 2021-10-11 18:28, Cigdem Sengul wrote:
>
> Hello Marco,
> Apologies for the late response - many thanks for the review.
> I think there will be some items to discuss further with Francesca, but I
> tried to make sure we have a plan for revisions as much as possible.
> Comments as usual uses [CS:] inline.
> Kind regards,
>
> On Mon, Aug 30, 2021 at 7:15 PM Marco Tiloca  wrote:
>
>> Hi all,
>>
>> Please, see below my review of version -03.
>>
>> Overall, I think this is on the right track and I do appreciate having
>> converged to a single AS :-)
>>
>> I hope the comments can help improving and progressing the document!
>>
>> Best,
>> /Marco
>>
> [CS: Many thanks, we appreciate it]
>
>>
>>
>>
>>
>> This review uses "KG" to refer to draft-ietf-ace-key-groupcomm-13 [KG],
>> and "KGO" to refer to draft-ietf-ace-key-groupcomm-oscore-11 [KGO].
>>
>> [KG]
>> https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63769539370672%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=iSm06pxr%2BrhtsQC287IG1n9646N9Veii8IwPILXAdSQ%3D=0>
>>
>> [KGO]
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-11
>> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-oscore-11=04%7C01%7Cmarco.tiloca%40ri.se%7C635d90eb0c7641b175e608d98cd4347f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63769539380626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=8Ap5YW95cHjOgFZVPhK9DODoq7KaSjVXFoTkIabUj2w%3D=0>
>>
>>
>> [General]
>>
>> * Please, replace references to RFC 8152 with references to
>> draft-ietf-cose-rfc8152bis-algs and I-draft-ietf-cose-rfc8152bis-struct.
>>
>> [CS: OK, will do]
>
>
>>
>> * This draft is basically using only the ace-group/GROUPNAME resource at
>> the KDC defined in KG, and only its POST handler for joining a group.
>> Will this draft describe/mention also how the rest of the KDC interface
>> is used by the pub-sub clients?
>>
>> [CS: I think we should definitely look into it; will go through all
> resources available, and will try to create
> a table of what MUST be used, what is RECOMMENDED to use, and what will
> not be used by the profile.]
>
>
> ==>MT
> Please consider the classification and profile guidelines now in Section
> 4.1 "Interface at the KDC" and Section 4.1.1 "Operations Supported by
> Clients" from the Editor's copy of ace-key-groupcomm.
>
> In particular, a profile can declare some resources/operations as not
> needed to be supported by the KDC. Also, operations from a Client point of
> view follows a more fine-grained classification, that can be made stricter
> or extended in profiles.
>
> These aspects are captured by mandatory-to-address profile requirements,
> some of which (and further related ones) are newly introduced following
> review comments to ace-key-groupcomm.
> <==
>
>
>
>
>>
>> [Abstract]
>>
>> * "This profile relies on transport layer or application layer security
>> to authorize the pub-sub clients to the broker".
>>
>> This is aligned with the currently existing transport profiles of
>> ACE (based on DTLS and OSCORE). However, do you actually want to limit
>> that security enforcement to those two layers?
>
>
>> More in general, I think this application profile can build on any
>> transport profile of ACE that the broker and the KDC are fine to use
>> with the pub-sub clients. This seems in fact the intention later in
>> Section 2 and Section 4.2, where some transport

Re: [Ace] Review of draft-ietf-ace-pubsub-profile-03

[Cigdem Sengul]

Hello Marco,
Apologies for the late response - many thanks for the review.
I think there will be some items to discuss further with Francesca, but I
tried to make sure we have a plan for revisions as much as possible.
Comments as usual uses [CS:] inline.
Kind regards,

On Mon, Aug 30, 2021 at 7:15 PM Marco Tiloca  wrote:

> Hi all,
>
> Please, see below my review of version -03.
>
> Overall, I think this is on the right track and I do appreciate having
> converged to a single AS :-)
>
> I hope the comments can help improving and progressing the document!
>
> Best,
> /Marco
>
[CS: Many thanks, we appreciate it]

>
>
>
>
> This review uses "KG" to refer to draft-ietf-ace-key-groupcomm-13 [KG],
> and "KGO" to refer to draft-ietf-ace-key-groupcomm-oscore-11 [KGO].
>
> [KG] https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-13
>
> [KGO]
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-11
>
>
> [General]
>
> * Please, replace references to RFC 8152 with references to
> draft-ietf-cose-rfc8152bis-algs and I-draft-ietf-cose-rfc8152bis-struct.
>
> [CS: OK, will do]


>
> * This draft is basically using only the ace-group/GROUPNAME resource at
> the KDC defined in KG, and only its POST handler for joining a group.
> Will this draft describe/mention also how the rest of the KDC interface
> is used by the pub-sub clients?
>
> [CS: I think we should definitely look into it; will go through all
resources available, and will try to create
a table of what MUST be used, what is RECOMMENDED to use, and what will not
be used by the profile.]



>
> [Abstract]
>
> * "This profile relies on transport layer or application layer security
> to authorize the pub-sub clients to the broker".
>
> This is aligned with the currently existing transport profiles of
> ACE (based on DTLS and OSCORE). However, do you actually want to limit
> that security enforcement to those two layers?


> More in general, I think this application profile can build on any
> transport profile of ACE that the broker and the KDC are fine to use
> with the pub-sub clients. This seems in fact the intention later in
> Section 2 and Section 4.2, where some transport profiles are mentioned
> as a non final set to choose from.


>
> * Proposed expansion of the last sentence:
>
> "... it describes the use of application layer security to protect
> the content that pub-sub clients exchange by communicating through the
> broker."
>

[CS:  So your suggestion is not to limit the coap pub-sub or mqtt, and how
they are secured
but be more generic?]

>
>
> * While it is mentioned later in Section 1, I think that the abstract
> should already mention that this profile covers both CoAP and MQTT.
>

[CS: OK, will do]

>
>
[Section 1]
>
> * "This document defines a way to authorize pub-sub clients using the
> ACE framework ...".
>
>  Please, clarify what they are authorized to do. Conceptually, it
> should be about joining a security group that uses certain key material
> and is associated to one or more topics (application groups).
> Practically, this should mean being authorized to getting access to the
> broker and to obtaining the key material for protecting the topic
> content exchanged through the broker.
>
> [CS: OK. how the clients get authorisation to talk to the Broker is
actually covered in other profiles (e.g., MQTT-TLS profile)
This one describes how they are authorised to get the keying material to
protect the payload of their communications from the
Broker.]



>
> * "... for protecting the communication between them".
>
> I would emphasize that it is about protecting the content, exhanged
> by communicating through the broker (see also the related comment above
> for the Abstract).
>

[CS: Yes]


> * After "(CoAP)", please add a reference to RFC 7252.
>
>
[CS: OK]


>
> [Section 2]
>
> * "Note that both publishers and subscribers use the same profiles."
>
> I suggest to expand as follows: "Note that both publishers and
> subscribers use the same pub-sub communication protocol and the same
> transport profile of ACE in their interaction with the broker. The same
> profile of ACE is also used in the interaction with the KDC."
>
> [CS: OK]


>
> * Caption of Figure 1: s/Authorization Servers/Authorization Server
>
[CS: Will fix]


>
>
> * "... so that RS can authorize the Clients ..."
>
> Well, the AS is the one authorizing the Clients. I think you mean
> "... so that RS can assert the Clients to be authorized ..."
>
> [CS: yes, that's too much of a short cut, will fix.]


>
> * I suggest to move the following points out of the last paragraph, and
> instead have them after "... to as Client in short."
>
> - The broker acts as ACE RS.
> - The broker corresponds to the Dispatcher in KG.
>
> [CS: OK]


>
> * The last sentences can be expanded for clarity, e.g.: "... the Broker
> MAY accept subscriptions from unauthorised Subscribers. In this case, a
> Subscriber client can skip setting 

Re: [Ace] Tuesday 2021-09-14 14:00 UTC

[Cigdem Sengul]

Hello Daniel,
I have a conflict for this meeting tomorrow - I will do my best
to join, but I will not be able to present any updates from the IETF
meeting.
My summary update is: I have received AD-review for the MQTT-TLS profile,
and received a pub-sub review from Marco. I am working towards addressing
both, prioritising the MQTT-TLS profile to make sure that it can progress.

Kind regards,
--Cigdem

On Tue, Sep 14, 2021 at 4:02 AM Daniel Migault  wrote:

> Hi,
>
> This is just a heads-up on tomorrow's meeting, so far I only see the
> groupcomm slides;-)
>
> Yours,
> Daniel
>
> On Mon, Aug 30, 2021 at 9:39 AM Daniel Migault 
> wrote:
>
>> Hi,
>>
>> Please note that we do have an interim meeting on September 14. A
>> potential agenda could be:
>>
>> ## Agenda
>> * Note Well,  agenda bashing
>>   * minute taker, blue sheet
>> * Agenda Bashing
>> * WGLC
>>   * key-groupcomm
>>   * cmpv2-coap-transport
>>   * wg-coap-eap
>> * Ongoing Work
>>   * pubsub-profile
>>   * gm-admin
>>   * groupcomm-oscore
>>
>> Feel free to propose any additional topic here:
>> https://notes.ietf.org/notes-ietf-interim-2021-ace-12-ace
>> and upload you material here:
>> https://datatracker.ietf.org/meeting/interim-2021-ace-12/session/ace
>>
>> Yours,
>> Logan and Daniel
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>
>
> --
> Daniel Migault
> Ericsson
> ___
> 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 Evaluation of draft-ietf-ace-mqtt-tls-profile-12

[Cigdem Sengul]

Hello Ben,


> Hopefully you have not gotten too far along on the few items where I reply
> and say that your proposed change may not be needed; I had hoped to write
> this message several days ago.  (That said, there really are only a few
> such places; the bulk of your proposals look good.)
>

No worries at all. I have been swamped and this time it served a good
purpose that I could not start
immediately addressing the issues raised. :) Hope to do so soon.

I am glad we have cleared out some misunderstandings regarding
token lengths, and MQTT operation.  Majority of required changes are clear
now,
I will have a more detailed e-mail showing how your review comments were
addressed.
Below, there are a few where I ask for some further clarifications, or
express my agreement, if I haven't done so already.

>
>
> >   The Broker MUST support "TLS:Anon-MQTT:ace".  To support Clients with
> > >different capabilities, the Broker MAY provide multiple client
> > >authentication options, e.g. support "TLS:Known(RPK)-MQTT:none" and
> > >"TLS:Anon-MQTT:None", to enable RPK-based client authentication, but
> > >fall back to "TLS:Anon-MQTT:ace" if the Client does not send a
> client
> > >certificate (i.e. it sends an empty Certificate message) during the
> > >TLS handshake.
> > >
> > > [Just a potential nit about the wording: "fall back" implies some
> > > ordering requirements, but IIRC use of RPK requires sending the token
> to
> > > authz-info before starting the new TLS connection, which doesn't quite
> > > match the steps as ordered in this description.]
> > >
> >
> > [CS: True that is not well-written. That was added because to
> potentially handle the Brokers having optional
> > client authentication for TLS. So, client authentication in TLS doesn't
> work, the broker would expect a
> > token in CONNECT; But it doesn't look needed as we do have a MUST for a
> token to be provided
> > for TLS-level client authentication. ]
>
> I think that makes sense to not require the broker to support TLS-level
> client authentication, yes.
>

[CS: OK. So, this should be rewritten not to say fall back?
Such as:
The Broker MUST support TLS:Anon,MQTT:ace.  To support Clients with
 different capabilities, the Broker MAY provide multiple client
authentication options, e.g. support TLS:Known(RPK) MQTT:none and
TLS:Anon,MQTT:None, to enable RPK-based client authentication, but
 if the Client does not send a client certificate (i.e. it sends an empty
Certificate message) during the
TLS handshake, the Broker MAY look for a token in MQTT CONNECT, using the
TLS:Anon,MQTT:ace
combination.
]


>
> >Note that, according to the MQTT standard, the Broker uses the Client
> > >identifier to identify the session state.  In the case of a Client
> > >identifier collision, a client may take over another client's
> > >session.  [...]
> > >
> > > Just to confirm: the ACE token is not used to provide authorization to
> > > use a given client identifer; the client identifier is just used as an
> > > unauthenticated identifier?  We might consider calling that out
> > > explicitly.
> > >
> >
> > [OK. Yes, the MQTT client id is considered different than the Client
> > Identifier that may be in the token.]
>
> They are clearly different identifiers, yes.  I was trying to ask about
> something slightly different, though.  One might imagine treating MQTT
> Client Identifiers as resources in their own right, and having the AS grant
> authorization to use them.  In that case the Client Identifier could be
> encoded in the token and the broker could reject attempts to use a client
> identifier that were not accompanied by a token authorizing use of that
> identifier.  However, such an architecture seems to have some layering
> issues and could be messy to implement, so I was assuming that we were not
> proposing to do so.
>

[CS: No, indeed, we have not considered client-identifiers as a resource. I
think it is an interesting proposal,
but may have further issues with client id collisions, which MQTT handles
best-effort.
Collision-free IDs would be desired but hard to achieve, when tokens given
out by multiple ASes, I assume. ]


>
> >a CONNACK with the appropriate response code.  The client cannot
> > >reauthenticate using this method during the same session ( see
> > >Section 4).
> > >
> > > Depending on what "session" means, this restriction may be too strict.
> > > We should probably be more clear about what "session" means...if it's
> > > the MQTT session, I think it's okay to use this method when
> > > re-connecting to take over the session.
> > >
> >
> > [CS: This is the MQTT session - I believe we discussed this before, and
> the
> > agreement was that this should not be allowed.
> > The reasoning was the client was not necessarily proving anything new
> with
> > the challenge from TLS-Exporter already used.]
>
> I agree that re-using the same challenge value from a TLS-Exporter is
> problematic for 

Re: [Ace] AD Evaluation of draft-ietf-ace-mqtt-tls-profile-12

[Cigdem Sengul]

Hello Ben,
Thank you very much for the review, and I will look into the pull request
as soon as possible.
Below I've gone over your comments and categorised them   as "Discussion"
if I had questions/clarifications/comments, and "Will Do" for the rest.

Discussion:


> Specifically, there's no requirement for ACE access tokens to be
> self-deliniating, so we can't actually programmatically tell whether
> there's content after the token in a CONNECT message; the mechanisms in
> Sections 2.2.4.1/2.2.4.2 seem to assume that we can do so for
> determining whether the CONNECT is just providing a token or also
> providing PoP over a TLS exporter value.  I think that this just means
> we need to have an explicit "token length" field (or similar).
>

[CS: Those sections do make use of an explicitly token length field Both
figures 4 and 5 show a token length in the Authentication Data.
2.2.4.1 - "For this option, the Authentication Data MUST contain the
two-byte
   integer token length, the token, and the keyed message digest (MAC)
   or the Client signature (as shown in Figure 4)."
Am I misunderstanding something?
]

>
> There are also a few places where we seem to be putting requirements on
> Broker behavior that are in direct conflict with normative requirements
> of the MQTT specification.  We can't override the external spec, so
> we'll need to check and reword in any places where there are conflicts.
> (I'm not an expert on MQTT and only read the spec as part of doing this
> review, so it's entirely possible that I'm misinterpreting the MQTT spec
> in some or all of these locations.)
>

[CS: Noted, I will respond to them where you have raised them specifically.]


> A few other general notes before the section-by-section notes:
>
> There is very little in this document about the HTTP-based interactions
> with the AS.  I think the intent is to defer to the core framework for
> that, but being a little more explicit about what is being pulled in and
> how would be helpful.
>

[CS: OK. Does this mean refer/cite the relevant sections in the core
framework?]

Section 1

   their subscribers.  In the rest of the document the terms "RS", "MQTT
   Server" and "Broker" are used interchangeably.

We will probably get a reviewer asking why we can't pick a single term
and standardize on it.  However, I expect that there are places where we
want to emphasize on one aspect or another of its behavior, so don't
think we should actually do so.  Similarly for the places where we
mention that CoAP can be used (but don't reference a concrete
specification).

[CS: This was brought up before. In practice, MQTT Broker or Broker is
widely used, MQTT Server is in MQTT spec, and the
RS is the additional functionality we are putting on the broker with this
spec. I am happy to keep to one if interchangeable use is an issue -
possibly select "MQTT Server" then. ]

Section 2.2.1

The way we name these authentication options with specific (quoted)
strings suggest that they will be used as a protocol element.  But
where?  Is the literal string "Known(RPK/PSK)" used in both cases (vs.
having distinct strings for RPK and PSK)?

Also, the hyphen character tends to more often be used as a joiner than
a separator, so it's easy to misread this as a triple of "TLS",
"Anon-MQTT", "None"/etc..  (I originally was going to ask why these all
had a "TLS" prefix...)  It might be better to use a semicolon or comma
instead of hyphen.

[CS: No they are not protocol elements. These were all the cases that we
came up with Jim thinking about the different possibilities for pushing the
token (Client may push the token before/during TLS session set-up; or
client may defer it to MQTT connect. ). I am open to suggestions to present
them better. I guess removing the "" would help? or any other suggestions
on naming?

 o  "TLS:Anon-MQTT:None": This option is used only for the topics that
  do not require authorization, including the "authz-info" topic.

Are there topics other than "authz-info" that don't require
authorization?  We might need to add some heding language to the earlier
statement that "Client and the Broker MUST perform mutual
authentication" if so.

[CS: Yes, actually we should think that the Broker may be hosting both
public and private topics, and hence, it may accept unauthorised clients if
that's the case. ]

   It is RECOMMENDED that the Client implements "TLS:Anon-MQTT:ace" as a
   first choice when working with protected topics.  However, depending
   on the Client capability, Client MAY implement "TLS:Known(RPK/PSK)-
   MQTT:none", and consequently "TLS:Anon-MQTT:None" to submit its token
   to "authz-info".

It's good that we provide guidance on which of the authentication
schemes are preferred (since we offer both ACE-layer and TLS-layer
schemes).  However, we will surely be asked to defend why there are two
possible ways of doing it instead of just one, and this text doesn't
really do a good job of that.  What might cause a need to 

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

[Cigdem Sengul]

Hello Ace,

In this version, we have made the modifications proposed in the IETF 110:
-  moved from architecture with AS1 and AS2 to a single AS and a KDC.
- introduced Subscriber client authorisation in addition to Publisher
client.
- updated token scope to match groupcomm
We have also introduced descriptions for the MQTT case.

Kind regards,
--Cigdem

On Wed, Jun 30, 2021 at 3:51 PM  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-03.txt
> Pages   : 21
> Date: 2021-06-30
>
> Abstract:
>This specification defines an application profile for authentication
>and authorization for publishers and subscribers in a constrained
>pub-sub scenario, using the ACE framework.  This profile relies on
>transport layer or application layer security to authorize the pub-
>sub clients to the broker.  Moreover, it describes application layer
>security for publisher-subscriber communication going through the
>broker.
>
>
> 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-03.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-pubsub-profile-03
>
>
> 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-mqtt-tls-profile-12.txt

[Cigdem Sengul]

Hello,
This new version is as discussed in the interim for registering the
ace+json media type.
Changes include:
- Reorganisation of Section 7 so that different IANA registrations are
separated.
- Minor fixes to references to the different sections of the ACE Framework
(which was out of date).

Kind regards,
--Cigdem

On Tue, May 11, 2021 at 11:55 PM  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-12.txt
> Pages   : 35
> Date: 2021-05-11
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-12
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-12
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] ACE WG - ace+json media type in Draft MQTT-TLS profile of ACE

[Cigdem Sengul]

Hello,

The ACE MQTT TLS profile makes the following ace+json application media
type registration
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-12#section-7.2>.
Could you please review it?
I am also including the excerpt from the draft below.
Kind regards,
--Cigdem

7.2 
<https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-12#section-7.2>.
Media Type Registration

This document registers the 'application/ace+json' media type for
   messages of the protocols defined in this document carrying
   parameters encoded in JSON.

   o  Type name: application

   o  Subtype name:ace+json

   o  Required parameters: none

   o  Optional parameters: none

   o  Encoding considerations: Encoding considerations are identical
to those specified for the 'application/json' media type.

   o  Security considerations: Section 8 of [this document]

   o  Interoperability considerations: none

   o  Published specification: [this document]

   o  Applications that use this media type:This media type is
intended for authorization server-client and authorization
server-resource server communication as part of the ACE framework
using JSON encoding as specified in [this document].

   o  Fragment identifier considerations:none

   o  Additional information:

  *  Deprecated alias names for this type:none

  *  Magic number(s):none

  *  File extension(s):none

  *  Macintosh file type code(s):none

   o  Person & email address to contact for further information:
Cigdem Sengul (csen...@acm.org)

   o  Intended usage: COMMON

   o  Restrictions on usage:none

   o  Author: Cigdem Sengul (csen...@acm.org)

   o  Change controller: IETF

   o  Provisional registration? (standards tree only): no


-- 

Dr Cigdem Sengul

Senior Lecturer

ACM-W Europe Communications Chair, and Secretary
*E* cigdem.sen...@brunel.ac.uk

*Brunel University London*
Dept of Computer Science

Brunel University London, Uxbridge, UB8 3PH, United Kingdom
*T* +44(0)1895 274000
*www.brunel.ac.uk <http://www.brunel.ac.uk/>*
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication

[Cigdem Sengul]

Hello Daniel,
I should clarify: I did not mean it was not compliant - it was more asking
whether anybody objects to registering ace+json when the framework talks
about a different method.
Kind regards,
--Cigdem

On Wed, Apr 14, 2021 at 1:50 PM Daniel Migault 
wrote:

> Hi,
>
> I am certainly missing something, but it is unclear to me why
> "application/ace+json" does not comply to "application/x-www-form-urlencoded".
> In other words, what would the update of the mqtt draft consist of to be
> aligned with the framework. I also have the impression that the use of
> "application/x-www-form-urlencoded" is a MAY and that the framework does
> not specify MUST. In general I am tempted to think it is better to be
> aligned with but It would probably need to understand better the issue and
> I am encouraging the WG to state rapidly their thoughts so we can move the
> draft forward.
>
> Regarding the second point, yes, the draft that introduces ace+json should
> register it.
>
> Yours,
> Daniel
> --
> *From:* Ace  on behalf of Cigdem Sengul <
> cigdem.sen...@gmail.com>
> *Sent:* Wednesday, April 14, 2021 4:58 AM
> *To:* Daniel Migault ; Ace Wg 
> *Subject:* Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS -
> AS communication
>
> Hello Daniel,
>
> One thing I didn't have a chance to ask yesterday in the interim was about
> the registration of the 'ace+json' application type.
> Francesca brought this up as the MQTT profile describes the HTTPS
> interactions differently than the core draft  which says " When HTTP is
> used as a transport then the client makes a request to the token endpoint
> by sending the parameters using the "application/
> x-www-form-urlencoded" format with a character encoding of UTF-8 in the
> HTTP request entity-body, as defined in section 3.2 of [RFC6749]."
>
> As I discussed with Francesca, we had discussions on the mailing list with
> Jim using ace+json as well. I recalled the view that the draft that
> introduces it should register it - I want to check if this is the general
> agreement, or you (or the group) has a different view
> - (1) registering this new type, or (2) MQTT draft is modified to
> comply with framework description
> - do we still agree that (1) it should be the  MQTT profile
> registering it or (2) it should be done elsewhere?
>
> Kind regards,
> --Cigdem
>
> On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault 
> wrote:
>
> Thanks for the update, that works for me.
>
> Yours,
> Daniel
>
> On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul 
> wrote:
>
> Hello Daniel,
> I propose the following change to clarify the TLS use - if you are happy
> with it, I will update the document:
>
> To provide communication confidentiality and RS authentication to MQTT
> clients, TLS
>
>is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
>
>the same assumptions as Section 4 of the ACE framework
>
>[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>
>the AS and setting up keying material.  While the Client-Broker
>
>exchanges are only over MQTT, the required Client-AS and RS-AS
>
>interactions are described for HTTPS-based communication [RFC7230],
>
>using 'application/ace+json' content type, and unless otherwise
>
>specified, using JSON encoding. 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 the communication channels between
> Client-AS and RS-AS."
>
> Since it is in this paragraph, one thing that Francesca brought up to do
> is to register the 'application/ace+json' content type.
> Kind regards,
> --Cigdem
>
> On Fri, Mar 5, 2021 at 9:11 PM Daniel Migault  40ericsson@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> Now that the authz document is being consolidated, I do have some minor
> concerns regarding the recommendations mentioned in the profile documents,
> that might require an additional update.
>
> The update to the authz document indicates more more clearly than before
> that profiles need to provide some recommendations for the RS – AS
> communication.
>
>
>
> “””
>
> Profiles MUST  specify for introspection a communication security protocol
> RECOMMENDED to be used between RS and AS that provides the features
> required above. “””
>
>
>
> It seems to me the MQTT profile text makes it pretty clear that TLS is
> recommended for all communications but I am wondering if additional
> clarification would be beneficial –

Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication

[Cigdem Sengul]

Hello Daniel,

One thing I didn't have a chance to ask yesterday in the interim was about
the registration of the 'ace+json' application type.
Francesca brought this up as the MQTT profile describes the HTTPS
interactions differently than the core draft  which says " When HTTP is
used as a transport then the client makes a request to the token endpoint
by sending the parameters using the "application/
x-www-form-urlencoded" format with a character encoding of UTF-8 in the
HTTP request entity-body, as defined in section 3.2 of [RFC6749]."

As I discussed with Francesca, we had discussions on the mailing list with
Jim using ace+json as well. I recalled the view that the draft that
introduces it should register it - I want to check if this is the general
agreement, or you (or the group) has a different view
- (1) registering this new type, or (2) MQTT draft is modified to
comply with framework description
- do we still agree that (1) it should be the  MQTT profile registering
it or (2) it should be done elsewhere?

Kind regards,
--Cigdem

On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault  wrote:

> Thanks for the update, that works for me.
>
> Yours,
> Daniel
>
> On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul 
> wrote:
>
>> Hello Daniel,
>> I propose the following change to clarify the TLS use - if you are happy
>> with it, I will update the document:
>>
>> To provide communication confidentiality and RS authentication to MQTT
>> clients, TLS
>>
>>is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
>>
>>the same assumptions as Section 4 of the ACE framework
>>
>>[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>>
>>the AS and setting up keying material.  While the Client-Broker
>>
>>exchanges are only over MQTT, the required Client-AS and RS-AS
>>
>>interactions are described for HTTPS-based communication [RFC7230],
>>
>>using 'application/ace+json' content type, and unless otherwise
>>
>>specified, using JSON encoding. 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 the communication channels between
>> Client-AS and RS-AS."
>>
>> Since it is in this paragraph, one thing that Francesca brought up to do
>> is to register the 'application/ace+json' content type.
>> Kind regards,
>> --Cigdem
>>
>> On Fri, Mar 5, 2021 at 9:11 PM Daniel Migault > 40ericsson@dmarc.ietf.org> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Now that the authz document is being consolidated, I do have some minor
>>> concerns regarding the recommendations mentioned in the profile documents,
>>> that might require an additional update.
>>>
>>> The update to the authz document indicates more more clearly than before
>>> that profiles need to provide some recommendations for the RS – AS
>>> communication.
>>>
>>>
>>>
>>> “””
>>>
>>> Profiles MUST  specify for introspection a communication security
>>> protocol RECOMMENDED to be used between RS and AS that provides the
>>> features required above. “””
>>>
>>>
>>>
>>> It seems to me the MQTT profile text makes it pretty clear that TLS is
>>> recommended for all communications but I am wondering if additional
>>> clarification would be beneficial – see below. That said I agree this is a
>>> very minor point in this case that could be handled by the RFC editor.
>>>
>>> For the OSCORE or DTLS profiles, unless I am missing the RS – AS
>>> recommendations in the documents , it seems to me it has been omitted and
>>> needs to be added -- see below.
>>>
>>>
>>>
>>>
>>>
>>> Yours,
>>>
>>> Daniel
>>>
>>>
>>>
>>> ## MQTT - draft-ietf-ace-mqtt-tls-profile-10
>>>
>>>
>>>
>>> “””
>>>
>>>To provide communication confidentiality and RS authentication, TLS
>>>
>>>is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
>>>
>>>the same assumptions as Section 4 of the ACE framework
>>>
>>>[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>>>
>>>the AS and setting up keying material.  While the Client-Broker
>>>
>>>exchanges are only over MQTT, the required Client-AS and RS-A

Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication

[Cigdem Sengul]

Hello Daniel,
I propose the following change to clarify the TLS use - if you are happy
with it, I will update the document:

To provide communication confidentiality and RS authentication to MQTT
clients, TLS

   is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes

   the same assumptions as Section 4 of the ACE framework

   [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with

   the AS and setting up keying material.  While the Client-Broker

   exchanges are only over MQTT, the required Client-AS and RS-AS

   interactions are described for HTTPS-based communication [RFC7230],

   using 'application/ace+json' content type, and unless otherwise

   specified, using JSON encoding. 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 the communication channels between Client-AS
and RS-AS."

Since it is in this paragraph, one thing that Francesca brought up to do is
to register the 'application/ace+json' content type.
Kind regards,
--Cigdem

On Fri, Mar 5, 2021 at 9:11 PM Daniel Migault  wrote:

> Hi,
>
>
>
> Now that the authz document is being consolidated, I do have some minor
> concerns regarding the recommendations mentioned in the profile documents,
> that might require an additional update.
>
> The update to the authz document indicates more more clearly than before
> that profiles need to provide some recommendations for the RS – AS
> communication.
>
>
>
> “””
>
> Profiles MUST  specify for introspection a communication security protocol
> RECOMMENDED to be used between RS and AS that provides the features
> required above. “””
>
>
>
> It seems to me the MQTT profile text makes it pretty clear that TLS is
> recommended for all communications but I am wondering if additional
> clarification would be beneficial – see below. That said I agree this is a
> very minor point in this case that could be handled by the RFC editor.
>
> For the OSCORE or DTLS profiles, unless I am missing the RS – AS
> recommendations in the documents , it seems to me it has been omitted and
> needs to be added -- see below.
>
>
>
>
>
> Yours,
>
> Daniel
>
>
>
> ## MQTT - draft-ietf-ace-mqtt-tls-profile-10
>
>
>
> “””
>
>To provide communication confidentiality and RS authentication, TLS
>
>is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
>
>the same assumptions as Section 4 of the ACE framework
>
>[I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>
>the AS and setting up keying material.  While the Client-Broker
>
>exchanges are only over MQTT, the required Client-AS and RS-AS
>
>interactions are described for HTTPS-based communication [RFC7230],
>
>using 'application/ace+json' content type, and unless otherwise
>
>specified, using JSON encoding.
>
> “””
>
>
>
> I am wondering if that would not be more appropriated to specify in the
> first line RS and AS authentication or simply authentication.
>
>
>
>
>
>
>
>
>
>- OSCORE draft-ietf-ace-oscore-profile-16
>
> “””
>
> 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.
>
> “””
>
>
>
>
>- DTLS draft-ietf-ace-dtls-authorize-15
>
>
>
> “””
>
> It is RECOMMENDED that the client
>
>uses DTLS with the same keying material to secure the communication
>
>with the authorization server, proving possession of the key as part
>
>of the token request.  Other mechanisms for proving possession of the
>
>key may be defined in the future.
>
> “””
>
>
> ___
> 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 Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Cigdem Sengul]

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

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

[Cigdem Sengul]

Thank you, Francesca,

Now I've added an mqtt branch to github, adding some references, and
clarifications, but a number of comments as well.
If I sum things up from the MQTT perspective (with the way the draft is
currently written):
A publishing client can get a token from AS1 to publish to MQTT broker
(there is mention of HTTP,  but do MQTT clients need to speak CoAP to
AS1/AS2?).
Both types of clients (Publisher/Subscriber) get tokens from AS2, and use
it towards the AS2-KDC to get the latest keys.
MQTT broker authorises CONNECTs for Publisher tokens from AS1, it doesn't
expect anything for subscribe-related permissions (unless subscribers are
authorised). (There is not distinction Publisher/Subscriber for MQTT -
client can provide a token with some publish permissions during connect,
and then does PUBLISH/SUBSCRIBE messages).
Broker does the mqtt-tls-profile checks for PUBLISH messages. It doesn't do
any checks on SUBSCRIBE messages and when its forwarding published messages
to subscribers, This is because subscribers are authorised as long as they
can decrypt messages.
One thing we may add is that the MQTT broker does not support retained
messages (as keying material may have changed for new clients, and it would
be basically sending jibberish to them).

Since the clients initiate a connection to the broker with CONNECT and
maintain it as they send PUBLISH SUBSCRIBE messages, I think all of the
above can be described in a single section for MQTT in the draft. So,
should we reorganise the draft so that CoAP PubSub is in one section, and
MQTT PubSub is in one section (rather than 4. Publisher: 4.1 CoAP publisher
- 4.2 MQTT publisher / 5. Subscriber: 5.1 CoAP Subscriber / 5.2 MQTT
Subscriber etc.)

Finally,  I think the things that need to be more clear:
* The current work division of AS1 and AS2 - for some reason, I relate more
to the case of AS1 being the AS, and AS2 being the KDC, AS1  handing out
tokens to talk to KDC and the broker.
To me it makes it easier to handle policy changes and revocations in both
ASes (as defined as out of scope in the draft).   I am sure I am missing
something with regards to why AS2 needs to be both an AS and KDC.

* For MQTT the scope format is AIF-MQTT; the case where the scope includes
permissions to multiple topics with wildcards, these wildcards may expand
to a number of topics handled by different keys. This part would need to be
explained better for MQTT.

* Maybe it is useful to define formally what a group is. Is it clients
holding the same set of keys, and so, each time a new client comes, the
group needs to be re-keyed.
In case of wildcards in MQTT, if Client1 has keys to publish to a/b/* and
Client 2 has subscriptions to a/b/* and Client 3 to a/b/topic1:
Client 1-Client2-Client3 is one group for a/b/topic, and Client 1 and
Client 2 is a second group for the rest.
It would be good to discuss if such things are only a problem for MQTT or
needs to be generally discussed.



Best wishes,
--Cigdem


On Sun, Jan 3, 2021 at 10:38 PM Francesca Palombini  wrote:

> 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" <
> ace-boun...@ietf.org 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-iet

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-09.txt

[Cigdem Sengul]

Hello Ace,

This is the latest version, which I believe would address all the ones
Daniel listed
in his e-mail around spacing and references.

@Daniel, apologies for taking so long.


Kind regards,
--Cigdem


On Thu, Dec 17, 2020 at 10:49 PM  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-09.txt
> Pages   : 33
> Date: 2020-12-17
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-09
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-09
>
>
> 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-mqtt-tls-profile-08.txt

[Cigdem Sengul]

Hello Ace,
This version addresses the WGLC reviews received on the mailing list. Thank
you Daniel, Francesca and Marco for your extensive reviews and discussion
on the mailing list.

A summary of changes from Version 07 to 08:

   o  Fixed several nits, typos based on WG reviews.

   o  Added missing references.

   o  Added the definition for Property defined by MQTT, and Client
  Authorisation Server.

   o  Added artwork to show Authorisation Data format for various PoP-
  related message exchange.

   o  Removed all MQTT-related must/should/may.

   o  Made AS discovery optional.

   o  Clarified what the client and server must implement for the client
  authentication; cleaned up TLS 1.3 related language.

Kind regards,
--Cigdem

On Mon, Nov 2, 2020 at 12:42 AM  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
> Filename: draft-ietf-ace-mqtt-tls-profile-08.txt
> Pages   : 33
> Date: 2020-11-01
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in a Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-08
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-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/
>
>
> ___
> 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 review of draft-ietf-ace-mqtt-tls-profile-07

[Cigdem Sengul]

Hello,
Yes, I interpreted it as it can provide null value if it wants to. And,
since it is listed as one of the parameters to add, I assumed it would,
otherwise, put the profile value.
In any case, it is not a huge problem from my side to remove it from the
mqtt draft.
Kind regards,
--Cigdem

On Thu, Sep 24, 2020 at 3:05 PM Francesca Palombini <
francesca.palomb...@ericsson.com> wrote:

> 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" <
> 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 
> *Date: *Sunday, 20 September 2020 at 23:02
> *To: *Francesca Palombini 
> *Cc: *Ace Wg , “draft-ietf-ace-mqtt-tls-prof...@ietf.org” <
> 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.palomb...@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 nex

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

[Cigdem Sengul]

Hello Daniel,

My responses are as follows:


> Just one clarification. TLS 1.3 provides two ways to authenticate the
> client. One way is sending a certificaterequest during the TLS handshake
> and another way is to send it after the handshake occurs. The ability to
> support the first authentication is not advertised by the TLS client. The
> ability to support the second is advertised with the post_handshake_auth
> extension. I just wanted to make sure we agreed there are two ways.
> 
>

[Cigdem: Yes, I agree. In both cases, what I read is: "If the client does
not send any certificates (i.e., it sends an empty
   Certificate message), the server MAY at its discretion either
   continue the handshake without client authentication or abort the
   handshake with a "certificate_required" alert."
I suggest continue the handshake and fallback to MQTT Connect
authentication for the RPK case.
]



> [Cigdem : Yes, actually, this is what I described above. Due to absence of
>> a certificate, I suggest it can fall back to CONNECT]
>>
>>
> 
> You are correct. What might need to be specified is that the server MUST
> support the two ways to authenticate the client. It MUST try during the
> handshake and if the client as not provided the sufficient credentials and
> the client has the post_handshake_auth, it MUST send one after the
> hanshake. The reason I think that maybe more text is needed is that I have
> the impression  a  minimal TLS server implementation may not necessary
> support both authentications. This would prevent  the use of an TLS
> implementation that only supports post_authentication for example.
> Similarly, I am wondering if the MQTT client does not have similar
> requirements regarding the support of TLS authentication as well as the
> CONNECT or if it may support only one. I tend to think that the client may
> only support only one way.
>
> To sum up, I am just trying to evaluate how to prevent a situation where
> the client will not be abel to authenticate itself to the server.
> 
>

[Cigdem: I think what I would prefer is that: the MQTT client will support
one way (one of PSK, or RPK, or over MQTT Connect then).
The server MAY support multiple ways.
Given we recommend the MQTT Connect for client authentication, the server
MUST implement that.
(That's why if RPK fails, MQTT connect can be fallback.)

If we agree, I will revise the document.
]

Kind regards,
--Cigdem
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Cigdem Sengul]

Dear Daniel,

Thank you very much for the responses. Mine are inline as well.
Kind regards,
--Cigdem



On Mon, Sep 21, 2020 at 4:06 PM Daniel Migault  wrote:

> Hi Cigdem,
>
> Please find my quick answer. Note these answers/comments are based on your
> response and what I remember from the document. That should be sufficient
> to clear most of them. I preferred to post the response earlier.
>
> Yours,
> Daniel
>
> On Sat, Sep 19, 2020 at 11:05 AM Cigdem Sengul 
> wrote:
>
>>
>>>
>>> 2.2.  Client Connection Request to the Broker (C)
>>>
>>> 2.2.1.  Client-Server Authentication over TLS and MQTT
>>>
>>>
>>>It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.
>>>
>>>The Broker MUST be authenticated during the TLS handshake.  If the
>>>Client authentication uses TLS:Known(RPK/PSK), then the Broker is
>>>authenticated using the respective method.  Otherwise, to
>>>authenticate the Broker, the client MUST validate a public key from a
>>>  X.509 certificate or an RPK from the Broker against the 'rs_cnf'
>>>parameter in the token response.  The AS MAY include the thumbprint
>>>of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined
>>>in [I-D.ietf-cose-x509]).  In this case, the client MUST validate the
>>>RS certificate against this thumbprint.
>>>
>>> 
>>>
>>> I am considering two main ways to
>>> authenticate the client
>>> TLS:Anon-MQTT:ace and
>>> TLS:Known(RPK/PSK)-MQTT:none. If a
>>> server supports both it is unclear
>>> to me how he can distinguish one
>>> method of authentication versus the
>>> other.
>>>
>>> TLS:Known(PSK)-MQTT:none If the TLS
>>> client provides a psk_identity, the
>>> TLS server may take this as an
>>> indication and lookup in the
>>> authz-info to see if there is a
>>> matching identity. This would
>>> assume that that kid is mentioned
>>> in the PoP.
>>>
>>> TLS:Known(RPSK)-MQTT:none If the
>>> client provides a
>>> post_handshake_auth, this may be
>>> taken as a hint that the client is
>>> associated to a RPSK. The Broker
>>> may instead chose to send a
>>> CertificateRequest, and upon
>>> receiving the Certificate message
>>> verify there is a matching RPK.  If
>>> the client does not provide the
>>> post_handshake_auth, it is unclear
>>> to me how the broker may
>>> distinguish a
>>> TLS:Known(RPSK)-MQTT:none from a
>>> TLS:Anon-MQTT:ace.
>>>
>>> In case there is no matching RPK, I
>>> am wondering if the broker falls
>>> back in a expected
>>> TLS:Anon-MQTT:ace.
>>>
>>> I might be missing something, but
>>> it seems that the authentication
>>> method is pre-agreed. Maybe some
>>> text may be added here.
>>>
>>> 
>>>
>>
>> [Cigdem: Yes, I assumed the flow you mentioned:
>> If the client is using PSK to authenticate then, I assume Client Hello
>> includes pre_shared_key (as described in RFC 8446: 2.2.  Resumption and
>> Pre-Shared Key (PSK)).
>> For clients that want to do RPK,  I assumed they will do  
>> "post_handshake_auth"
>> and the server will do a CertificateRequest, but if the client declines
>> or fails to authenticate, will expect authentication over MQTT:ace.
>>
> 
> Unless I am missing something in TLS 1.3 or in ACE. The client can
> authenticate with a Post Handshake Client Authentication or during the TLS
> base handshake (appendix E.1.2). In the second case ,  I do not see any
> specific extensions that the client provides to indicate it supports the
> client authentication during the handshake. It seems the server logic that
> decides to send a CertificateRequest
> 
>

[Cigdem: TLS 1.3:
""When the client has sent the “post_handshake_auth” extension (see Section
4.2.6), a server MAY request client authentication
at any time after the handshake has completed by sending a
CertificateRequest message. The client MUST respond with the
appropriate Authentication messages (see Section 4.4). If the client
chooses to authenticate, it MUST send Certificate,
CertificateVerify, and Finished. If it declines, it MUST send a Certificate
message containing no certificates followed by
Finished."

So, my understanding the client may not authenticate during
post_handshake_auth. Cllient authentication over TLS can be configured
optional at the server, and the server can tolerate an empty c

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

[Cigdem Sengul]

Hello Marco,
Responses inline.

>
> [CS: This is because the Authentication Data explained under 2.2.4  is
> binary data.  The
>binary data in MQTT is represented by a two-byte integer length, which
> indicates the number of data bytes, followed by that number of
>bytes.
> So, we have the total length of the entire Authentication Data,
> Token length + token  + (total length - token length) of MAC data.
> I hope this is more clear.
>
> Do you think I should repeat what binary data is at the subsections rather
> than explaining in 2.2.4?
> ]
>
>
> ==>MT
> So the Authentication Data includes some  binary data,
> possibly followed by some extra data (here a MAC/Signature). Correct?
>
I think it's worth clarifying this when introducing the Authentication
> Data, and say what is part of the binary data here in Section 2.2.4.1.
> <==
>
>
[CS:  I think I may introduce ASCII art to explain this.
The content of Authentication Data for 2.2.4.1 is: Token length (2B)
+token+Mac computed over the content from the TLS exporter.
i.e, it is inclusive of the MAC. T

Actually, Authentication Data is defined before the subsections 2.2.4.1 and
2.2.4.2, under 2.2.4, because it is common to both subsections, just its
content varies. The text says:
"The Authentication Method is followed by the Authentication Data,
   which has a property identifier 22 (0x16) and is binary data.  The
   binary data in MQTT is represented by a two-byte integer length,
   which indicates the number of data bytes, followed by that number of
   bytes."

Then, the subsection explains what is in the Authentication Data content
(ie. binary data part) and may include additional length fields.
I think this is where the confusion stems from - the multiple length
fields.
]

>
>
>> [Section 2.2.4.2]
>>
>> * Shouldn't the Authentication Data in the AUTH message from the server
>> start with a 2-byte server nonce length?
>>
> [CS: the client is calculating a MAC over its nonce and server nonce and
> sending it back, with the information of its nonce.
> I assumed the RS would remember its nonce length]
>
>
> ==>MT
> I was referring to the AUTH packet from the server, including its RS
> challenge.
>
> The message is still including Authentication Data, and in any other case
> this seems to start with a 2-byte length field, as also described in
> Section 2.2.4.
>
> If that length field is actually optional, I can see it might be omitted
> here, since the client is supposed to get always an 8-byte nonce from the
> server.
> <==
>
> [CS: That was the reason - the spec defined the nonce as 8-byte. And as it
did not make its size optional, the Authentication Data does not include
the nonce size.
]


>
> [CS: Has my previous explanation clarified this?
>
> client_nonce length + nonce
> (the size of AUTH DATA - client_nonce_length)  of MAC  of
> (client_nonce+server nonce)
>
>
> ==>MT
> Yes, I think similar clarifications would help here in Section 2.2.4.2.
> <==
>
___
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

[Cigdem Sengul]

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 <
francesca.palomb...@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.".
]


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

--
>
>  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 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.
>
>
[CS: My response is the same as above. Since the core document capitalised
REQUIRED, I kept MUST.]


> --
>
> "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)
>
> [CS: It is overhead as any token validation done in TLS is overwritten by
what ever token is provided in ace.
Will add a sentence around that.
https://github.com/ace-wg/mqtt-tls-profile/issues/70
]



> --
>
>  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.
>
> [CS: I am not sure I understand the comment. The other methods are
described, but  TLS:Anon-MQTT:ace is recommended.
You suggest I reverse the order, and start with recommended version?]


> --
>
>  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)?
>
[CS: Yes, if it does not want to support session continuation, it always
starts clean session.
If necessary was added due to providing potentially support for better QoS,
but it may be other reasons. So, instead of prescribing a reason, I opted
for "If necessary", where the need is determined by the Broker provider.
]

--
>
>  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.
>
> [CS: QoS level is defined in MQTT terminology in Section 1.3. " QoS level
   The level of assurance for the delivery of an Application
   Message.  The QoS level can be 0-2, where "0" indicates "At
   most once delivery", "1" "At least once delivery", and "2"
   "Exactly once delivery"."
]


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

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

[Cigdem Sengul]

Hello Marco,
Thank you for the review. My responses are inline.
Kind regards,
--Cigdem

>
>
>
> [General]
>
> * Refer the AIF adopted draft rather than the individual submission.
>
> * Some references are included twice side by side, e.g. RFC 4949 and RFC
> 7800.
>

>
[Section 1]
>
> * Add an inline reference to RFC 8446 for TLS 1.3. I think it's good
> adding also references to CoAP and CBOR(-bis).
>
>
>
  [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65
, will be fixed in
the next submission]



> [Section 2.2.1]
>
> * In the paragraph on "TLS:Known(RPK/PSK)-MQTT:none", the last two
> sentences can clarify that they apply to TLS 1.2. As to the analogous
> alternative provision of the token in PSK mode for TLS 1.3, that can point
> to "identity" in the "identities" entry of "Pre-Shared Key" ClientHello
> Extension.
>
>
[CS: I think it is better to change the wording to match what is defined
for TLS 1.3, as it is the recommended version.
Created new issues at https://github.com/ace-wg/mqtt-tls-profile/issues/69
 Will fix. ]


>
> [Section 2.2.4.1]
>
> * Section 2.2.4 said that the two-byte integer length indicates the amount
> of following bytes within Authentication Data. However this section refers
> to the two-byte length as only the token length, i.e. it does not seem to
> cover also the MAC/Signature (whose length might be assumed from the used
> algorithm), even though that's still part of Authentication Data. Could you
> please confirm or clarify?
>

[CS: This is because the Authentication Data explained under 2.2.4  is
binary data.  The
   binary data in MQTT is represented by a two-byte integer length, which
indicates the number of data bytes, followed by that number of
   bytes.
So, we have the total length of the entire Authentication Data,
Token length + token  + (total length - token length) of MAC data.
I hope this is more clear.

Do you think I should repeat what binary data is at the subsections rather
than explaining in 2.2.4?
]


> * It's worth making it explicit that the PoP key is used to compute the
> MAC or the client signature.
>

> * s/and, the server/and the server
>
> * Remove the final closed parenthesis.
>
[CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65
, will be fixed in
the next submission]


> [Section 2.2.4.2]
>
> * Shouldn't the Authentication Data in the AUTH message from the server
> start with a 2-byte server nonce length?
>
[CS: the client is calculating a MAC over its nonce and server nonce and
sending it back, with the information of its nonce.
I assumed the RS would remember its nonce length]


>
> * Like for the AUTH message from the client, see the comment above for
> Section 2.2.4.1 about what the 2-byte length covers (i.e., here too I would
> have expected it to cover also the MAC/signature, not just the nonce).
>

[CS: Has my previous explanation clarified this?

client_nonce length + nonce
(the size of AUTH DATA - client_nonce_length)  of MAC  of
(client_nonce+server nonce)


> * Like for the comment above for Section 2.2.4.1, it's worth making it
> explicit that the PoP key is used to compute the MAC or the client
> signature.
>
>
> [Section 2.2.5]
>
> * s/RS MUST verify/the RS MUST verify
>
> * Please, add references for HS256 and Ed25519.
>
>
> [Section 3]
>
> * s/to all topic3/to all 'topic3'
>

>
[Section 6.1]
>
> * s/as a UTF-8/is a UTF-8
>

  [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65
, will be fixed in
the next submission]


>
> 
>
>
> On 2020-09-01 22:54, Daniel Migault wrote:
>
> Hi,
>
> This email starts a 2 weeks Working Group Last Call for
> draft-ietf-ace-mqtt-tls-profile. Please review the document available
> here [1] and provide your feed backs by September 15 2020.
>
> Yours,
> Jim and Daniel
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
>
> --
> Daniel Migault
> Ericsson
>
> ___
> Ace mailing listAce@ietf.orghttps://www.ietf.org/mailman/listinfo/ace
>
>
> --
> 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 501https://www.ri.se
>
> ___
> 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-mqtt-tls-profile

[Cigdem Sengul]

Hello,
Thank you, Daniel, Marco and Francesca for your reviews. Much appreciated.
I will start by responding to Daniel first.
Comments/Responses are inline.



> A) Are there existing implementations of the protocol?
>

[ Cigdem: This is still as I've explained in the previous IETF meeting:
 Implementation using the HiveMQ CE is a Java-based open source MQTT broker
that fully supports MQTT 3.x and MQTT 5.
https://github.com/michaelg9/HiveACEclient


The Mosquitto prototype was only v3.1.1:
https://github.com/ciseng/ace-mqtt-mosquitto
]


> B) Has each author confirmed that any and all appropriate IPR disclosures
> required for full conformance with the provisions of BCP 78 and BCP 79 have
> already been filed
>

 [Cigdem: I will check with the others again, but do not expect issues.]

>
> C)  Miscellaneous warnings: ( from the nits button on the datatracker)
>
>
[Cigdem: Opened the issue, will fix in the next submission:
https://github.com/ace-wg/mqtt-tls-profile/issues/65


>
> D) The IANA section needs to be completed and you MAY start sending a
> request for the expor
> ted label. (See more details inline).
> I also suggest you check with the IANA everything is fine.
>

[ Cigdem: OK]



> 2.  Authorizing Connection Requests
>
>If the Client is resource-constrained, a Client Authorisation Server
>may carry out the token request on behalf of the Client, and later,
>onboard the Client with the token.
> 
> I understand the Client
> Authorization Server as a proxy.
> If that is not a well known term, I
> am wondering if we need to have a
> specific designation ? The current
> designation might be confusing with
> the AS, is not represented in the
> figure and as far as I understand
> is more related to a client than to
> a server.  Client Authorization
> Server Interface or Client
> Authorization Server Client  ?
>
> I am fine leaving it at is in any
> case.
>
> 
>

[ Cigdem: When first writing this draft, I've taken the Client
Authorization Server concept, from the now-expired actors
document. https://tools.ietf.org/html/draft-ietf-ace-actors-07


However, I could not find out what the workgroup replaced it with, if it
did.



> 2.1.  Client Token Request to the Authorization Server (AS)
>
>The first step in the protocol flow (Figure 1 (A)) is the token
>acquisition by the Client from the AS.  The Client and the AS MUST
>perform mutual authentication.  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'.  The media format is 'application/ace+json'.
>The AS uses JSON in the payload of its responses to both to the
>Client and the RS.
>
> 
>
> This is perhaps my reading, but I
> do expect however to bring a
> contradiction to 5.6.1. This does
> not seems the case here. I
> understand that the ace_profile
> MUST be set to mqtt_tls.
>
> I am wondering if s/however ...
> /with the profile set to mqtt_tls.
> is not sufficient.
>
> This is not a strong push from my
> side either.
>
> There is a nit "to both to"
> 
>

[Cigdem: Will change: "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'. "

to:  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] with the profile
   parameter to 'mqtt_tls'.

Can remove "both to"
https://github.com/ace-wg/mqtt-tls-profile/issues/65

]


>
>If the AS successfully verifies the access token request and
>authorizes the Client for the indicated audience (i.e.  RS) and
>scopes (i.e. publish/subscribe permissions over topics), the AS
>issues an access token (Figure 1 (B)).  The response includes the
>parameters described in Section 5.6.2 of the ACE framework
>[I-D.ietf-ace-oauth-authz].  The returned token is a Proof-of-
>Possession (PoP) token by default.  This document follows RFC 7800
>[RFC7800] for PoP semantics for JWTs.  The PoP token includes a 'cnf'
>parameter with a symmetric or asymmetric PoP key.  Note that the
>
> 
>
> I am wondering if the PoP token
> should not be the access token
> instead ?  I would rather expect
> the 'cnf' to contain the PoP, but I
> must admit I am not too familiar
> with terminology or usage so I
> might be wrong.
>
> 
>

[Cigdem:  I used the two interchangeably because the ACE framework document
says:
" When this specification uses the term "access token" it is assumed to be a
  PoP access token token unless specifically stated otherwise."

Btw, there is a typo in the ACE framework document: token appears twice in

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

[Cigdem Sengul]

Dear Ace,
As discussed in the last IETF meeting, I've submitted a new version that
hopefully addresses the issues raised in the meeting and Jim's latest
review:
In Section 2.2.3, added the constraint on which packets the Client can
send, and the server can process after CONNECT before CONNACK. In Section
2.2.3, clarified that session state is identified by Client Identifier, and
listed its content.
In Section 2.2.3, clarified the issue of Client Identifier
collision when the broker supports session continuation.
  Corrected the buggy scope example in Section
3.1.

Regards,
--Cigdem

On Tue, Aug 25, 2020 at 11:25 PM  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   : Message Queuing Telemetry Transport (MQTT)-TLS
> profile of Authentication and Authorization for Constrained Environments
> (ACE) Framework
>     Authors : Cigdem Sengul
>   Anthony Kirby
>   Paul Fremantle
> Filename: draft-ietf-ace-mqtt-tls-profile-07.txt
> Pages   : 31
> Date: 2020-08-25
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in an Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-07
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-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] Review of draft-ietf-ace-mqtt-tls-profile-06

[Cigdem Sengul]

Hello Jim,

I understand that it's an optimization to improve message delay. I wonder
also if a client then can do CONNECT - PUBLISH - DISCONNECT before
receiving a CONNACK as a best-effort publish? assuming CONNECT succeeds...
Should we just not cater to those cases?

What about stating in 2.2.6.1 - after "the Broker MUST
   send a CONNACK message to the Client." (or maybe somewhere higher up):

-> The client MUST NOT send any packets other than DISCONNECT or an AUTH in
response to the broker AUTH's message until it has received a CONNACK.
-> The server MUST NOT process any packets other than DISCONNECT or an AUTH
in response to its AUTH message before it has sent a CONNACK.

--Cigdem









On Mon, Aug 17, 2020 at 7:16 PM Jim Schaad  wrote:

>
>
>
>
> *From:* Cigdem Sengul 
> *Sent:* Monday, August 17, 2020 10:45 AM
> *To:* Jim Schaad 
> *Cc:* draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06
>
>
>
>
>
>
>
> I've got that from MQTT v5 spec:
>
> If a Client sets an Authentication Method in the CONNECT, the Client MUST
> NOT send any packets other than AUTH or DISCONNECT packets until it has
> received a CONNACK packet [MQTT-3.1.2-30].
>
>  and:
>
> If the Server rejects the CONNECT, it MUST NOT process any data sent by
> the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].
>
>
>
> [JLS] I read this as the following would not do the publish
>
> CONNECT à
>
> PUBLISH à
>
> ß AUTH
>
> AUTH à
>
> ß CONNACK fail
>
> The PUBLISH can be received but is not processed unless the CONNACK is
> going to be a success.
>
> [/JLS]
>
>
>
> [CS] I think this sequence should not happen, as Client MUST NOT send
> PUBLISH before CONNACK.
>
> I did not know what brokers do if they receive PUBLISH (and still
> processing a CONNECT) - drop or buffer until process. I quickly browsed
> mosquitto src.
>
> It looks like the broker sets a context flag to mark the session active
> after CONNECT is processed and accepted.
>
> If this flag is not set when processing publish,  it goes to an error
> state and doesn't look like it keeps the packet.
>
>
>
> [JLS] No, Clients are allowed to send further MQTT Control Packets
> immediately after sending a CONNECT packet; Clients need not wait for a
> CONNACK packet to arrive from the Server. – this is the preceding two
> sentences to requirement MQTT-3.1.4-6.  I would agree that this is going to
> be server specific.  The following paragraph suggests that clients SHOULD
> wait for the CONNACK but it is non-normative.  I think that I would write
> my client code to wait.  I would have to work really hard to figure out
> what my code base would do for this as I know it does queue packets for
> later processing but I am not sure what it would do for this case.
>
>
>
>
>
> [CS] Ok, this is confusing.  I assumed that sentence regarding clients
> about not having to wait was when no Authentication Method set.
>
> Because there is: If a Client sets an Authentication Method in the
> CONNECT, the Client MUST NOT send any packets other than AUTH or DISCONNECT
> packets until it has received a CONNACK packet [MQTT-3.1.2-30].
>
>  In the profile, we do set an authentication method in connect to "ace".
>
>
>
> [JLS] Looks like there might be some conflicting statements here.  I don’t
> know the best way to resolve it.
>
> Jim
>
>
>
>
>
> --Cigdem
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Cigdem Sengul]

>
>
> I've got that from MQTT v5 spec:
>
> If a Client sets an Authentication Method in the CONNECT, the Client MUST
> NOT send any packets other than AUTH or DISCONNECT packets until it has
> received a CONNACK packet [MQTT-3.1.2-30].
>
>  and:
>
> If the Server rejects the CONNECT, it MUST NOT process any data sent by
> the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].
>
>
>
> [JLS] I read this as the following would not do the publish
>
> CONNECT à
>
> PUBLISH à
>
> ß AUTH
>
> AUTH à
>
> ß CONNACK fail
>
> The PUBLISH can be received but is not processed unless the CONNACK is
> going to be a success.
>
> [/JLS]
>
>
>
> [CS] I think this sequence should not happen, as Client MUST NOT send
> PUBLISH before CONNACK.
>
> I did not know what brokers do if they receive PUBLISH (and still
> processing a CONNECT) - drop or buffer until process. I quickly browsed
> mosquitto src.
>
> It looks like the broker sets a context flag to mark the session active
> after CONNECT is processed and accepted.
>
> If this flag is not set when processing publish,  it goes to an error
> state and doesn't look like it keeps the packet.
>
>
>
> [JLS] No, Clients are allowed to send further MQTT Control Packets
> immediately after sending a CONNECT packet; Clients need not wait for a
> CONNACK packet to arrive from the Server. – this is the preceding two
> sentences to requirement MQTT-3.1.4-6.  I would agree that this is going to
> be server specific.  The following paragraph suggests that clients SHOULD
> wait for the CONNACK but it is non-normative.  I think that I would write
> my client code to wait.  I would have to work really hard to figure out
> what my code base would do for this as I know it does queue packets for
> later processing but I am not sure what it would do for this case.
>
>
>
[CS] Ok, this is confusing.  I assumed that sentence regarding clients
about not having to wait was when no Authentication Method set.
Because there is: If a Client sets an Authentication Method in the CONNECT,
the Client MUST NOT send any packets other than AUTH or DISCONNECT packets
until it has received a CONNACK packet [MQTT-3.1.2-30].
 In the profile, we do set an authentication method in connect to "ace".

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

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Cigdem Sengul]

Hello Jim,
Responses inside.


>
>
>
> On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad 
> wrote:
>
> Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
> session number/  - I think it should be stated that the session number is
> provided, which is what the state is associated with.
>
>
>
> To the best of my knowledge, and from what I read from the MQTT v5 spec:
>
> The ClientID MUST be used by Clients and by Servers to identify state that
> they hold relating to this MQTT Session between the Client and the Server..
>
> I do not think the server uses anything other than the Client ID to look
> up the state.
>
> [JLS] I got the name wrong, the need for the identifier remains.
>
[CS] I see - I realise I did a shortcut to say MQTT broker keep session
state.
Actually, I think I should give examples of session state as I need to
explain what could be problematic by identifying state only with client-id
as discussed in the last IETF meeting.
(i.e.,

The Session State in the Client consists of:

· QoS 1 and QoS 2 messages which have been sent to the Server, but
have not been completely acknowledged.

· QoS 2 messages which have been received from the Server, but have
not been completely acknowledged.



The Session State in the Server consists of:

· The existence of a Session, even if the rest of the Session State
is empty.

· The Clients subscriptions, including any Subscription Identifiers.

· QoS 1 and QoS 2 messages which have been sent to the Client, but
have not been completely acknowledged.

· QoS 1 and QoS 2 messages pending transmission to the Client and
OPTIONALLY QoS 0 messages pending transmission to the Client.

· QoS 2 messages which have been received from the Client, but have
not been completely acknowledged.The Will Message and the Will Delay
Interval

· If the Session is currently not connected, the time at which the
Session will end and Session State will be discarded.

)



>
> Section 2.2.4 - Last sentence.  There is a difference between the connect
> and re-auth flows in that the first and last messages are going to be AUTH
> '25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
> Might just want to say a similar flow and point forward.
>
> Will clarify that this is only for CONNECT as it is under section 2- 
> Authorizing
> Connection Requests.
>
> Will direct to section 4 for re-authentication.
>
>
>
> Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
> different in MQTT v5.0, the Broker is allowed to process AUTH packets even
> if the Broker rejects the CONNECT)."  I think that if the broker rejects
> the
> connect it must CONNACK and disconnect.
>
>
>
> I've got that from MQTT v5 spec:
>
> If a Client sets an Authentication Method in the CONNECT, the Client MUST
> NOT send any packets other than AUTH or DISCONNECT packets until it has
> received a CONNACK packet [MQTT-3.1.2-30].
>
>  and:
>
> If the Server rejects the CONNECT, it MUST NOT process any data sent by
> the Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].
>
>
>
> [JLS] I read this as the following would not do the publish
>
> CONNECT à
>
> PUBLISH à
>
> ß AUTH
>
> AUTH à
>
> ß CONNACK fail
>
> The PUBLISH can be received but is not processed unless the CONNACK is
> going to be a success.
>
> [/JLS]
>

[CS] I think this sequence should not happen, as Client MUST NOT send
PUBLISH before CONNACK.
I did not know what brokers do if they receive PUBLISH (and still
processing a CONNECT) - drop or buffer until process. I quickly browsed
mosquitto src.
It looks like the broker sets a context flag to mark the session active
after CONNECT is processed and accepted.
If this flag is not set when processing publish,  it goes to an error state
and doesn't look like it keeps the packet.


>
>
> So, the spec allows clients to send AUTH after CONNECT before CONNACK, and
> servers to process AUTH after CONNECT (before CONNACK I suppose).
>
>
>
> I agree the wording may  be confusing:
>
> What I want to say is that: the servers in our profile do not process
> anything after CONNECT before CONNACK.
>
> So, the AUTH flow is strictly initiated by the server during the
> connection handshake.
>
> After that, the client may do AUTH first, for re-authentication.
>
> [JLS] Given that a client may only send an AUTH in response to an AUTH, I
> don’t know how much this is needed.
>
>
>
> [JLS]  I think if you just delete the aside (in parens) then it says what
> needs to be said and is not confusing.
>
>
>
[CS] OK, agreed, less is more in this case. Will delete the parentheses
text.

>
>
>
> Section 3.1 - Missed a case of "publish_+/topic3"
>
> Yes, in previous version, example was for publish only for topic3.
>
> I thought I should give a pub/sub, pub only, and sub only examples.
>
> Is that OK?
>
>
>
> Yes, I was just pointing out that this was using the old syntax.  Nothing

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-06

[Cigdem Sengul]

Hello Jim,
Responses inside.

On Sat, Aug 15, 2020 at 10:50 PM Jim Schaad  wrote:

> Section 2.2.3 - /Clean Start to 0/Clean Start to 0, specify the previous
> session number/  - I think it should be stated that the session number is
> provided, which is what the state is associated with.
>
>
To the best of my knowledge, and from what I read from the MQTT v5 spec:
The ClientID MUST be used by Clients and by Servers to identify state that
they hold relating to this MQTT Session between the Client and the Server.
I do not think the server uses anything other than the Client ID to look up
the state.


> Section 2.2.4 - Last sentence.  There is a difference between the connect
> and re-auth flows in that the first and last messages are going to be AUTH
> '25', AUTH '0' not CONNECT/CONNACK.  Everything else does stay the same. -
> Might just want to say a similar flow and point forward.
>
> Will clarify that this is only for CONNECT as it is under section 2- 
> Authorizing
Connection Requests.
Will direct to section 4 for re-authentication.


> Section 2.2.6.1 - I am not sure where you got this from: "Note that this is
> different in MQTT v5.0, the Broker is allowed to process AUTH packets even
> if the Broker rejects the CONNECT)."  I think that if the broker rejects
> the
> connect it must CONNACK and disconnect.
>

I've got that from MQTT v5 spec:

If a Client sets an Authentication Method in the CONNECT, the Client MUST
NOT send any packets other than AUTH or DISCONNECT packets until it has
received a CONNACK packet [MQTT-3.1.2-30].

 and:
If the Server rejects the CONNECT, it MUST NOT process any data sent by the
Client after the CONNECT packet except AUTH packets [MQTT-3.1.4-6].

So, the spec allows clients to send AUTH after CONNECT before CONNACK, and
servers to process AUTH after CONNECT (before CONNACK I suppose).

I agree the wording may  be confusing:
What I want to say is that: the servers in our profile do not process
anything after CONNECT before CONNACK.
So, the AUTH flow is strictly initiated by the server during the connection
handshake.
After that, the client may do AUTH first, for re-authentication.


> Section 3.1 - Missed a case of "publish_+/topic3"
>
Yes, in previous version, example was for publish only for topic3.
I thought I should give a pub/sub, pub only, and sub only examples.
Is that OK?

Thanks,
--Cigdem



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

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-06.txt

[Cigdem Sengul]

Hello,

I've submitted a new version in preparation for the next meeting.
This version implements the change from the originally proposed scope
format to AIF.
There are 1-2 issues outstanding (regarding session continuation), which
will be discussed in the WG meeting.

Thanks,
--Cigdem

On Mon, Jul 13, 2020 at 9:18 AM  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   : MQTT-TLS profile of ACE
>     Authors : Cigdem Sengul
>   Anthony Kirby
>   Paul Fremantle
> Filename: draft-ietf-ace-mqtt-tls-profile-06.txt
> Pages   : 30
> Date: 2020-07-13
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in an Message Queuing Telemetry Transport (MQTT)-based
>publish-subscribe messaging system.  Proof-of-possession keys, bound
>to OAuth2.0 access tokens, are used to authenticate and authorize
>MQTT Clients.  The protocol relies on TLS for confidentiality and
>MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-06
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-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

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

[Cigdem Sengul]

This looks what I expected from the MQTT point of view. Thanks, Jim.
I will look into adding the change to the profile document now.
Kind regards,
--Cigdem


On Tue, Jun 23, 2020 at 4:48 PM Jim Schaad  wrote:

>
>
> > -Original Message-
> > From: Ace  On Behalf Of Francesca Palombini
> > Sent: Tuesday, June 23, 2020 6:45 AM
> > To: Carsten Bormann ; Ace Wg 
> > Cc: Marco Tiloca 
> > Subject: Re: [Ace] AIF as discussed today (Re: I-D Action:
> draft-bormann-core-
> > ace-aif-08.txt)
> >
> > 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.
>
> This follows what I would expect, for MQTT I would see
>
> AIF-MQTT = AIF_Generic
> filter = tstr
> permissions = [ +permission ]
> permission = "publish" / "subscribe"
>
> For the group comm draft, I think that
>
> AIF-GROUP-COM = AIF_Generic
> path = tstr  ; group name
> permissions = uint . bits methods
> methods = &(
> requester = 1,
>responder = 2,
>monitor = 3,
>verifier = 4
> )
>
> This does require a registry if we ever expect this to grow.
>
> > 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"  > boun...@ietf.org on behalf of c...@tzi.org> 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 

Re: [Ace] FW: Review draft-ietf-ace-mqtt-tls-profile-05

[Cigdem Sengul]

Hello Jim,

Thank you for the comments. Responses inline.
Changes in this commit


On Mon, Jun 8, 2020 at 11:49 PM Jim Schaad  wrote:

> Let's see if I can get the mailing list right this time
>
> -Original Message-
> From: Jim Schaad 
> Sent: Monday, June 8, 2020 3:02 PM
> To: 'draft-ietf-ace-mqtt-tls-prof...@ietf.org'
> 
> Cc: 'c...@ietf.org' 
> Subject: Review draft-ietf-ace-mqtt-tls-profile-05
>
> * Style Issue. "Abbreviations should be expanded in document title and upon
> first use in the document.  Full expansion of the text should be followed
> by
> the abbreviation in parentheses."  Some items such as TLS are considered to
> be known by everybody and thus do not need to be expanded.
> https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both
> "known" and "unknown" abbreviations.  (Yes this means you are going to have
> a really long title.)  (I might argue that  OASIS should be listed as well
> known.)
>

[CS] Fixed (All style issues are in
https://github.com/ace-wg/mqtt-tls-profile/issues/53)

>
> * Section 1 - para 1 - Sentence two has a plurality mismatch between client
> and server.  I think in this case server (and broker) should be pluralized.
>
> [CS] Fixed.


> * Section 1.3 - Broker - s/publishes/publish/  The set of pluralized items
> seems to be too large by one.
>

[CS] Fixed

>
> * Section 1.3 - I think we ought to define Session given that we no longer
> require that Clean Session be used.
>

 [CS] Added
https://github.com/ace-wg/mqtt-tls-profile/issues/55

>
> * Section 1.3 - I do not believe that CONNACK is always the first packet
> from the broker to a client.  An AUTH message may be the first one.
>
> [CS] Removed that sentence.


> * Section 2.1 - para 3 s/the public key used by the RS/the public key to be
> used by the RS/
>

[CS] Fixed.

>
> * Section 2.1 - I think (but am not sure) that we may need to do some
> registrations around the use of thumbprints in a confirmation claim.  If I
> forget, please remind me to track this down.
>

[CS] Opened Github issue so that I do not forget.
https://github.com/ace-wg/mqtt-tls-profile/issues/54

>
> * Section 2.2.2 - para #1 - s/using client authentication/using server
> authentication/  If we are doing MQTT as the default then the server not
> the
> client is authenticated here.  You may not want to have lost the
> potentially
> here.
>

[CS] What I meant here was this: Given that the client pushed the token
using authz-info,
we expect it to use authenticate itself over TLS next time it connects
(otherwise it would have carried the token in the MQTT connect). I will fix
it as using client authentication over TLS (i.e, TLS:Known(RPK/PSK)-MQTT:none)
but wanted to check first if I missed your meaning.
https://github.com/ace-wg/mqtt-tls-profile/issues/56


> * Section 2.2.3 - I think that the client state MUST include the token and
> either the same token is supplied or a token with the same key is supplied
> in order to match with an existing state.
>

I used a MAY because:
1) MQTT originally identifies resuming client with only client id.
2) The client MUST still provide a token when reconnecting and continuing a
session, and the broker MUST perform a validation.

If the broker additionally keeps the former token then it can identify the
client better.

However, the client may have gotten a new token, as it may know its token
has expired, or it just expanded its permissions between sessions.
Also, the CONNECT message does not specify how clients can push a
historical and a new token.

It may be seen as an issue that the broker authorises the current session
(not the continuation of the session) and uses the MQTT way to access the
session state by only the Client ID.
A problem may be that client A uses client_id1, disconnects and then client
B connects with client_id1, both using session continuation.
Then, the risk is client A's subscribed topics may be delivered to client B
because client B's token has the same set of permissions.
I think this is acceptable as client B's token already covers those topics
(although it may mean QoS issues for client A).

https://github.com/ace-wg/mqtt-tls-profile/issues/57

>
> * Section 6.2 - I think it makes sense to put in a note that between the
> fact that the server will disconnect on almost any error and is not
> required
> to keep session state between connections, clients need to make a greater
> effort to ensure that tokens remain valid and they do not attempt to
> publish
> to topics that they do not have permissions for.


[CS] Added.
https://github.com/ace-wg/mqtt-tls-profile/issues/58


>
> * Section 8 - The storage of tokens long term can be restricted to only
> current valid ones if an immediate validation of the token is done.  This
> means that the RS spends time doing the validation, but does not need to
> consume memory.
>

[CS] Just want to confirm; when you say storage 

Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-05.txt

[Cigdem Sengul]

Dear Ace,

I've submitted a v5 of the MQTT profile making the following updates as
discussed in the April interim (the changes should be able to close all the
remaining 6 issues in the github repo). After Jim and Carsten's e-mails,
I've been thinking also how to add support for AIF in the draft.

List of changes:
* Clarified that MQTT v5.0 Brokers may implement username/password option
for transporting the ACE token only for MQTT v.3.1.1 clients. This option
is not recommended for MQTT v.5.0 clients.
* Changed Clean Session requirement both for MQTT v.5.0 and v.3.1.1. The
Broker SHOULD NOT, instead of MUST NOT, continue sessions.
   Clarified expected behaviour if session continuation is supported. Added
to the Security Considerations the potential misuse of session
continuation.
*  Added that client re-authentication is accepted only for the
challenge/response PoP.
 * Also important for misuse of re-authentication messages, clarified that
the Broker should not accept any other packets from Client after CONNECT
and before sending CONNACK.

Other including some minor changes:
* Added Ed25519 as mandatory to implement
*  Fixed the Authentication Data to include token length for the
Challenge/Response PoP.
*  Added that Authorisation Server Discovery is triggered if a token is
invalid and not only missing.
* Did some reorganisation in Section 2 so that "Unauthorised Request:
Authorisation Server Discovery"  is presented under Section 2.6 as part of
the broker's response to the client.
  *Fixed Figure 2 to remove the "empty" word from the CONNECT format.

Thanks,
--Cigdem


On Thu, May 28, 2020 at 9:42 PM  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   : MQTT-TLS profile of ACE
> Authors : Cigdem Sengul
>   Anthony Kirby
>   Paul Fremantle
> Filename: draft-ietf-ace-mqtt-tls-profile-05.txt
> Pages   : 29
> Date: 2020-05-28
>
> Abstract:
>This document specifies a profile for the ACE (Authentication and
>Authorization for Constrained Environments) framework to enable
>authorization in an MQTT-based publish-subscribe messaging system.
>Proof-of-possession keys, bound to OAuth2.0 access tokens, are used
>to authenticate and authorize MQTT Clients.  The protocol relies on
>TLS for confidentiality and MQTT server (broker) authentication.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-05
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-05
>
>
> 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] Comments on the MQTT draft

[Cigdem Sengul]

>
>
> [CS] Yes. We opted for not keeping any state because that indeed had too
> many problematic issues. One was, as I already mentioned, extra state kept
> for a time determined by the client (session expiry) - which we thought
> would cause trouble. There are some non-normative text in MQTT spec about
> how the server storage limits or admin policies can overwrite client-set
> expiry.
>
> The other issue is that the broker checks existing session with the (MQTT)
> Client Identifier. This info is not burned into the token (note that this
> client id is different than ACE client id used for e.g., authenticating to
> AS)
>
> So, I feel that is problematic as well...
>
> So, there is a security-qos trade-off.
>
>
>
> [JLS]  I was planning to put a pointer to the token into my session state
> so that it could be checked.  However, as I stated in the original.  This
> needs to be justified one way or the other in the document.
>
>
>

[CS]  I added some text to the v04 of the document to explain the reasons
behind having clean session.
However, I am wondering whether MUST is too strong, and whether to opt for
SHOULD, and make other SHOULDs on broker behaviour i.e.,
1) Session state includes information of the token used in the session.
2) There is a MAX session expiry set by the broker admin policy allowing
capping what the client puts for session expiry.
3)  The client still submits a token in every CONNECT - the broker checks
if the token matches the current token (may or may not introspect in case
of a token match); if new token, validate token, replace the session token.
4)  Session state is updated: Subscription Identifiers, that are part of
the session state, validated if new permissions. (Although it will do this
anyway when publishing a packet to the subscriber. )
 Pending messages are re-evaluated based on permissions.

>
>
>
> 4.  I keep going back and forth on a recommendation that we channel bind in
> the challenge response case.  I don't have the knowledge to be able to do a
> formal proof, but I think that all of necessary conditions are going to be
> met without it.  However, having the binding included would most likely
> make
> the proofs that much easier.
>
>
>
> [CS] I am confused about this as well. Because, as we discussed in the
> interim meeting, the exporter-based
>
> flow only works at the connection time, and not for reauthentication (that
> is why we kept the challenge/response flow).
>
> I am aiming to submit the v04 - but I will probably need to submit v05 to
> clarify all this.
>
>
>
> [JLS]]  You can do the exporter at any time.  I was thinking in terms of
> signing the triple of  value>
>
>
>
[CS] I seem to recall a reauthentication discussion in the interim, but
now, thinking again do not see why that was an issue.

 Thanks,
-Cigdem
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Cigdem Sengul]

Hello Hannes,

I will summarise below what I understood and clarify where I got confused
(which I tried to in the interim meeting)
 and then would need the group feedback for the next steps.

I became aware that the key distribution may be an issue after the
e-mail thread: "Transporting different types of cnf objects - CBOR vs JSON"
that spanned June-Oct, 2019, in the ace mailing list, where you wrote:
"We have standardized the transport of this additional information in ACE for
use with CoAP but for HTTP we decided to do the work on OAuth, where it got
stuck because the IoT-interested people are not there and the Web folks
want something else."

Then, I was under the impression that I would need to wait for the
draft-ietf-oauth-pop-key-distribution
<https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07>.
(Even though the prototype implementation I used worked with HTTP/JSON
equivalent for COAP/CBOR in draft-ietf-ace-oauth-authz )

That's why is responded to this email thread saying I am aware of the
issue.
After Jim's email, I understood that the issue may be resolved.

For the MQTT-TLS profile, the following is needed:
1) To be able to use HTTP to talk to AS for /token and /introspect
interfaces. I was aware that this was supported now
in draft-ietf-ace-oauth-authz:
"If the RS is online, validation can be handed over to the AS using
token introspection (see messages D and E) over HTTP or CoAP".
In 5.6 Token endpoint: "The endpoint may, however, be exposed over
HTTPS as in classical OAuth or even other transports."

2) mqtt_tls draft introduces the ace+json media type, as  Jim wrote: "I
would argue that the first draft using such a media type would be the
right place
to specify it. " in the thread "Transporting different types of cnf objects
- CBOR vs JSON".

3)  What I wasn't aware, and realised after Jim's email was that
draft-ietf-ace-oauth-params, which defines the cnf and rs_cnf
parameters say, supports JSON:
"Note that although all examples are shown in CBOR [RFC7049],
JSON [RFC8259] MAY be used as an alternative for HTTP-based
   communications, as specified in [I-D.ietf-ace-oauth-authz]."

I may be missing something but what is left for MQTT-TLS profile to define
when  draft-ietf-ace-oauth-authz  +   draft-ietf-ace-oauth-params put
together?


Kind regards,
--Cigdem








On Mon, Mar 9, 2020 at 8:01 PM Hannes Tschofenig 
wrote:

> Hi Cigdem,
>
>
>
> Following the OAuth virtual interim meeting call today I wonder whether it
> makes sense to describe how the key transport with the PoP token using the
> communication between the client and the authorization server over the HTTP
> interface works.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* Hannes Tschofenig
> *Sent:* Friday, February 28, 2020 11:08 AM
> *To:* Cigdem Sengul 
> *Cc:* ace@ietf.org
> *Subject:* RE: [Ace] draft-ietf-ace-mqtt-tls-profile-03
>
>
>
>- I plan to join. I  have been aware of the issue, but could not
>follow how it was planned to be resolved.
>- I was looking at this: draft-ietf-oauth-pop-key-distribution
>
>
>
> Yes, that’s what the group wanted to do. Now, new ideas showed up on the
> radar that are incompatible with that approach that offer a much tighter
> integration with HTTP signing.
>
>
>
> Ciao
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Fwd: New Version Notification for draft-ietf-ace-mqtt-tls-profile-04.txt

[Cigdem Sengul]

Hello,

As discussed in the interim, I've submitted a v04.
There are a few things, which may still merit a v05, but we did the
following updates on v04. The changes include:

   -  Linked the terms Broker and MQTT server more at the introduction of
the document.
   - Clarified support for MQTTv3.1.1 and removed phrases that might be
considered as MQTTv5 is backward compatible with MQTTv3.1.1
- Corrected the Informative and Normative references.
- For AS discovery, clarified the CONNECT message omits the
Authentication Data field.
- Specified the User Property MUST be set to "ace_as_hint" for AS
Request Creation Hints.
 - Added that MQTT v5 brokers MAY also implement reduced interactions
described for MQTTv3.1.1.
 - Added to Section 3.1, in case of an authorisation failure and QoS
level 0, the RS sends a DISCONNECT with reason code '0x87 (Not authorized)'.
  - Added a pointer to section 4.7 of MQTTv5 spec for more information
on topic names and filters.
  - Added HS256 and RS256 are mandatory to implement depending on the
choice of symmetric or asymmetric validation.
  - Added MQTT to the TLS exporter label to make it application
specific: 'EXPORTER-ACE-MQTT-Sign-Challenge'.
  -  Added a format for Authentication Data so that length values
prefix the token (or client nonce) when Authentication Data contains more
than one piece of information.
   - Clarified clients still connect over TLS (server-side) for the
authz-info flow.

Thanks,
--Cigdem

-- Forwarded message -
From: 
Date: Mon, Mar 9, 2020 at 2:39 PM
Subject: New Version Notification for draft-ietf-ace-mqtt-tls-profile-04.txt
To: Anthony Kirby , Cigdem Sengul ,
Paul Fremantle 



A new version of I-D, draft-ietf-ace-mqtt-tls-profile-04.txt
has been successfully submitted by Cigdem Sengul and posted to the
IETF repository.

Name:   draft-ietf-ace-mqtt-tls-profile
Revision:   04
Title:  MQTT-TLS profile of ACE
Document date:  2020-03-09
Group:  ace
Pages:  28
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-tls-profile-04.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
Htmlized:
https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-04
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-04

Abstract:
   This document specifies a profile for the ACE (Authentication and
   Authorization for Constrained Environments) framework to enable
   authorization in an MQTT-based publish-subscribe messaging system.
   Proof-of-possession keys, bound to OAuth2.0 access tokens, are used
   to authenticate and authorize MQTT Clients.  The protocol relies on
   TLS for confidentiality and MQTT server (broker) authentication.




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 on the MQTT draft

[Cigdem Sengul]

Hello Jim,
Comments inline.


Yes, I can see this can be problematic but this was to avoid the broker
> keeping state for clients that are no more authorised to receive those
> messages. The session state can include actual messages if QoS>=1, so maybe
> high overhead.
>
>
> The Session Expiry is also set by the client:
>
>
> [JLS] All of that makes a great deal of sense to me.   What if a session
> expires when a token expires independent of the client’s request for a long
> session expiry interval.  After all, if the token is the identity then if
> the token expires you can no longer prove you are the same person and thus
> can have the same session back.   You probably need some weasel text about
> allowing for an expired session to get a new token if it is kept open
> perhaps, but I have not looked exactly when a connection would be forced
> closed due to token expiration yet.
>
>
>
[CS] Yes. We opted for not keeping any state because that indeed had too
many problematic issues. One was, as I already mentioned, extra state kept
for a time determined by the client (session expiry) - which we thought
would cause trouble. There are some non-normative text in MQTT spec about
how the server storage limits or admin policies can overwrite client-set
expiry.
The other issue is that the broker checks existing session with the (MQTT)
Client Identifier. This info is not burned into the token (note that this
client id is different than ACE client id used for e.g., authenticating to
AS)
So, I feel that is problematic as well...
So, there is a security-qos trade-off.


>
>
>
> 4.  I keep going back and forth on a recommendation that we channel bind in
> the challenge response case.  I don't have the knowledge to be able to do a
> formal proof, but I think that all of necessary conditions are going to be
> met without it.  However, having the binding included would most likely
> make
> the proofs that much easier.
>
>
[CS] I am confused about this as well. Because, as we discussed in the
interim meeting, the exporter-based
flow only works at the connection time, and not for reauthentication (that
is why we kept the challenge/response flow).
I am aiming to submit the v04 - but I will probably need to submit v05 to
clarify all this.

 Thanks,
-Cigdem

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

Re: [Ace] Comments on the MQTT draft

[Cigdem Sengul]

Hello Jim,

Comments inline.

On Sun, Mar 8, 2020 at 7:04 PM Jim Schaad  wrote:

> 1.  I want to verify that the following is the desired statement:  There is
> a strong preference that TLS not use PSK for authentication.  This follows
> from the recommendation to use TLS:Anon-MQTT:ace for the authentication
> option.  I have no problems with this statement, I just want to be sure
> that
> the group as a whole is ok with this position.   I found that I implemented
> the SHOULD NOT option for PSK to start with, but that is because I was
> trying to be completist not because I think the position is wrong.
>

To tell the truth, I've put the RECOMMENDED as I believed it was expected
that I provide a recommendation.
Otherwise, any of the methods are OK (with some exceptions for anon:anon,
and over authenticating/authorising with the last mode).


>
> 2.  While implementing I found that there did not appear to be a mandatory
> to implement validation algorithm, one needs to be specified.
>

Do you mean mandatory-to-implement certificate validation policy?


>
> 3.  After reading the log of bugs which have been showing up on the MQTT
> code base that I have been using, I think there needs to be text put into
> the document to deal with the clean session requirement that this profile
> is
> enforcing.  I am seeing a lot of people who are relying on the fact they
> are
> not reconnecting with clean session to get QoS information back from the
> server in the event of unexpected disconnects.
>

Yes, I can see this can be problematic but this was to avoid the broker
keeping state for clients that are no more authorised to receive those
messages. The session state can include actual messages if QoS>=1, so maybe
high overhead.

Session State in the Server consists of:

· The existence of a Session, even if the rest of the Session State
is empty.

· The Clients subscriptions, including any Subscription Identifiers.

· QoS 1 and QoS 2 messages which have been sent to the Client, but
have not been completely acknowledged.

· QoS 1 and QoS 2 messages pending transmission to the Client and
OPTIONALLY QoS 0 messages pending transmission to the Client.


The Session Expiry is also set by the client:

When a client connects with a long Session Expiry Interval, it is
requesting that the Server maintain its MQTT session state after it
disconnects for an extended period. Clients should only connect with a long
Session Expiry Interval if they intend to reconnect to the Server at some
later point in time. When a client has determined that it has no further
use for the Session it should disconnect with a Session Expiry Interval set
to 0.



>
> 4.  I keep going back and forth on a recommendation that we channel bind in
> the challenge response case.  I don't have the knowledge to be able to do a
> formal proof, but I think that all of necessary conditions are going to be
> met without it.  However, having the binding included would most likely
> make
> the proofs that much easier.




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

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

[Cigdem Sengul]

Hello Hannes,

Thank you very much for your comments. My responses are inside.

>
> From the text you cited regarding MQTT v5 it is not backwards compatible
> to version 3.1.1. The exact impact of working between two devices of
> different versions has not been described in the spec either. The follow
> sentence in your introduction can easily give readers the impression that
> the two versions are backwards compatible. Here is the sentence:
>
> " It is expected that MQTT
>deployments will retain backward compatibility for MQTT v3.1.1
>clients, and therefore, this document also describes a reduced set of
>protocol interactions for MQTT v3.1.1 - the OASIS Standard
>[MQTT-OASIS-Standard].
> "


> Maybe you want to change the wording a little bit.  I think the reason why
> you want to describe a solution for v3.1.1 is that this is the widely
> deployed version.
>
>

I see where I am creating confusion. I should distinguish better that I
expect solution providers to still support MQTT v3.1 clients by
implementing both MQTT v5 and MQTT v3.1.1 servers, as you said because
3.1.1 is widely deployed. I was not meaning spec backward compatibility.



> Regarding the broker term: It is probably a matter of taste but I would
> refer to the terms used in the spec and would not replicate the terminology
> from the OASIS MQTT specs in the draft.

Someone who implements the draft will have to become familiar with MQTT
> anyway. But that’s just me. For example, I often see people using the term
> “certificate authorities (CA)” in their write-ups. RFC 5280 defines and
> uses the term “certification authority (CA)". While the two sound and look
> similar only one is actually correct.
>

OK, you suggest we use MQTT server. I expect broker is more widely-used in
practice, and it is not a misspelling of another term either. I would want
to keep it, but I would like to see if others prefer MQTT server rather.


>
> I noticed you have put a normative dependency on
> [I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary
> because it is not a requirement to implement the spec.

You could use it on top of it -- or you could use something else as well. I
> would move it to the informative part.  The added benefit of doing that is
> that you do not block your spec till that draft becomes RFC.

  True. Will fix.


> On the other hand, RFC 6749, RFC 7800, and
> I-D.ietf-ace-cwt-proof-of-possession cannot be informative references when
> you use PoP tokens in your solution.
>
> Yes, indeed. Will fix.


> You might be interesting to hear that there is currently no way to obtain
> the keys for a PoP token over HTTP, which your solution requires. The
> virtual interim meeting in the OAuth group should probably be of interest
> to you.
>

I plan to join. I  have been aware of the issue, but could not follow how
it was planned to be resolved.
I was looking at this: draft-ietf-oauth-pop-key-distribution

Thanks again,
--Cigdem


>
> From: Cigdem Sengul 
> Sent: Tuesday, February 25, 2020 3:10 PM
> To: Hannes Tschofenig 
> Cc: ace@ietf.org
> Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03
>
> Hello Hannes,
>
> We used  broker as it is a widely accepted term in the MQTT Community for
> "server" e.g.,
> majority of the provider would list also a broker implementation to refer
> to their server implementation.
>
> With respect to whether 3.1,1 clients talking to v5, there may be some
> issues. This is what the spec says:
>
> Non-normative Comment
> If the Server distributes Application Messages to Clients at different
> protocol levels (such as MQTT V3.1.1) which do not support properties or
> other features provided by this specification, some information in the
> Application Message can be lost, and applications which depend on this
> information might not work correctly.
>
> The spec also defines a protocol version error message:
> If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and
> the Server does not want to accept the CONNECT packet, the Server MAY send
> a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and
> then MUST close the Network Connection
>
> So, whether a broker provides dual support would depend on the provider.
> E.g., the Mosquitto broker supports the different protocol versions.
>
> Thanks,
> --Cigdem
>
> On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig  hannes.tschofe...@arm.com> wrote:
> Hi Cigdem, Hi Anthony, Hi Paul,
>
> Why are you using the term MQTT broker? My understanding of the MQTT spec
> is that there are only clients and servers - nothing more.
>
> Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT
> v3.1.1 client talk t

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

[Cigdem Sengul]

Hello Hannes,

We used  broker as it is a widely accepted term in the MQTT Community for
"server" e.g.,
majority of the provider would list also a broker implementation to refer
to their server implementation.

With respect to whether 3.1,1 clients talking to v5, there may be some
issues. This is what the spec says:


*Non-normative Comment*

If the Server distributes Application Messages to Clients at different
protocol levels (such as MQTT V3.1.1) which do not support properties or
other features provided by this specification, some information in the
Application Message can be lost, and applications which depend on this
information might not work correctly.


The spec also defines a protocol version error message:

If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and the
Server does not want to accept the CONNECT packet, the Server MAY send a
CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and
then MUST close the Network Connection

So, whether a broker provides dual support would depend on the provider.
E.g., the Mosquitto broker supports the different protocol versions.

Thanks,
--Cigdem

On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Cigdem, Hi Anthony, Hi Paul,
>
> Why are you using the term MQTT broker? My understanding of the MQTT spec
> is that there are only clients and servers - nothing more.
>
> Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT
> v3.1.1 client talk to a MQTT v5 client via a server that supports both
> v3.1.1 and v5?
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> ___
> 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-mqtt-tls-profile-03

[Cigdem Sengul]

ed to derive the key used to the signature or
> MAC.
> Instead this key is in the access token.  If I am correct, the use of MAC
> or
> signature is defined by the PoP symmetric or asymmetric. Correct ? I
> believe
> the text could be clearer.  
>

Yes, correct. Added to the github issue to make this text clearer:
https://github.com/ace-wg/mqtt-tls-profile/issues/41


>
> 2.2.4.2.  Proof-of-Possession via Broker-generated Challenge/Response
>
>For this option, the RS follows a Broker-generated challenge/response
>protocol.  The success case is illustrated in Figure 4.  If the
>Authentication Data only includes the token, the RS MUST respond with
>an AUTH packet, with the Authenticate Reason Code set to '0x18
>(Continue Authentication)'.  This packet 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 nonce as
>a challenge for the Client.  The Client responds to this with an AUTH
>packet with a reason code '0x18 (Continue Authentication)'.
>Similarly, the Client packet sets the Authentication Method to 'ace'.
>The Authentication Data in the Client's response contains a client-
>generated 8-byte nonce, and the signature or MAC computed over the RS
>nonce concatenated with the client nonce.  Next, the token is
>validated as described in Section 2.2.5.
>
>
> I do not see exporters being involved, and if that is correct there
> is no
> channel binding. As DTLS is mandatory, wouldn't it be possible to add the
> exporter to the nonces. This may also be used to increases the randomness
> of
> the nonces
>
>
[CS] I have to admit, I have gone back and forth about this.
Some implementers have commented not to have  TLS exporter support...




> [...]
>
> 3.1.  PUBLISH Messages from the Publisher Client to the Broker
>
>On receiving the PUBLISH message, the Broker MUST use the type of
>message (i.e., PUBLISH) and the Topic name in the message header to
>match against the scope string in the cached token or its
>introspection result.  Following the example above, a client sending
>a PUBLISH message to 'a/topic3' would be allowed to publish, as the
>scope includes the string 'publish_+/topic3'.
>
>If the Client is allowed to publish to the topic, the RS must publish
>
> While "must" may not be necessary, if used, it could be
> normative.
>

[CS] I tried to keep MQTT musts as "must" and  this profile's musts as
MUST.
Wouldn't that be acceptable?


>
> 3.2.  PUBLISH Messages from the Broker to the Subscriber Clients
>
>To forward PUBLISH messages to the subscribing Clients, the Broker
>identifies all the subscribers that have valid matching topic
>subscriptions (i.e., the tokens are valid, and token scopes allow a
>subscription to the particular topic).  The Broker sends a PUBLISH
>message with the Topic name to all the valid subscribers.
>
>RS MUST stop forwarding messages to the unauthorized subscribers.
>
> I do not think they should have started. I am wondering if
> s/stop/NOT/
> would not be better.
>

[CS] Fixed.


>
> 4.  Token Expiration and Reauthentication
>
>
>To re-authenticate, the Client sends an AUTH packet with reason code
>'0x19 (Re-authentication)'.  The Client MUST set the Authentication
>Method as 'ace' and transport the new token in the Authentication
>Data.  The Client and the RS go through the same steps for proof of
>possession validation as described in Section 2.2.  The Client SHOULD
>use the same method used for the first connection request.
>
> I am wondering if there are good reasons for SHOULD. I would say that
> using multiple authentication method with different level of trust SHOULD
> be
> avoided. 
>

[CS] I am not sure any more if that sentence is necessary

Thanks for your review again,
--Cigdem



>
> On Fri, Jan 17, 2020 at 9:40 PM Jim Schaad  wrote:
>
>>
>>
>>
>>
>> *From:* Cigdem Sengul 
>> *Sent:* Tuesday, January 14, 2020 8:25 AM
>> *To:* Jim Schaad 
>> *Cc:* draft-ietf-ace-mqtt-tls-prof...@ietf.org; Ace Wg 
>> *Subject:* Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03
>>
>>
>>
>> Thank you for this review, Jim.
>>
>> Responses inline.
>>
>>
>>
>> On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad 
>> wrote:
>>
>>
>>
>>
>> 2.2.2 - I am unclear under what circumstances you could end put with a
>> token
>> which does not parse when processing a PUBLISH message.  If the token
>> cannot
>> be parsed at connection time, that I

Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Cigdem Sengul]

Hello Jim,

>
>
>
> When topic subscriptions are protected, the Broker can choose to do two
> things:
>
> 1) Allow the subscription but internally subscribe the clients to
> sport/basketball and sport/tennis only.
>
> or
>
> 2) Reject the subscription and the client needs to ask for subscriptions
> that are a subset or equal to their permission strings. So the client
> specifically needs to ask for publish_sport/tennis and
> publish_sport/basketball matching its scope strings. But then scope
> parameter cannot be optional and must be included in the AS response.
>
> or
>
> 3) Allow the subscription, when a new level is added, check the
> permissions of all active subscribers, send DISCONNECT if the current
> permissions do not apply to the new hierarchy.
>
>
>
> 1 would need to be again signalled to the client, 2 might be too
> restrictive, and 3 may introduce a processing load if things are changing
> all the time (which I do not expect).
>
> Leaning towards 3...  Any thoughts?
>
>
>
> [JLS]  My first thought was to run and hide.  I think you have the scope
> strings setup wrong, they all should be “subscribe_” not “publish_” as a
> client is never going to ask to publish with a wildcard (MQTT-3.3.2-2).
>   I would far prefer that the answer be 2 rather than 1 and I think that 3
> is right out.
>

Gosh... Don't know why I switched to publish... Sorry for any pain caused!


>
>
> For 3 you are saying we are going to subscribe you, and then potentially
> disconnect you at a later time for something you never heard about.  I
> don’t really care about 1, only because there is no way to communicate this
> information back to the client that one is changing the set of
> subscriptions that was requested.
>

Ah, I see your interpretation- I saw the subscription request for
subscribe_topic/+  and subscribe_topic/# as a request from the subscriber
saying "send me anything under x" (depending on +/# restrictions). So, they
may not know all the matching subtopics anyway.

If the permissions are including the wildcards and cover the request, no
problem.  But, if they don't but the combination of a subset of permissions
do at the current state (i.e., subscribe_sport/basketball +
subscribe_sport/tennis = subscribe_sport/+), I wondered whether the RS may
want to accept this request. However, if it registers this subscription as
subscribe_sport/+, it is not future proof for any changes to that level and
client would be lacking the appropriate permissions - which should lead to
a disconnect.


>
>
> I am not sure what you are requesting in terms of returning the scope
> parameter.  The current OAuth specification states that if the
> Authorization server returns a token that contains a different scope that
> the one requested by the client, then it is required to return the modified
> scope to the client.  Is that what you are looking for.
>

Thanks, I was not sure that was a MUST, and I should have read the RFC more
carefully. (Possibly I got confused with another spec out of IETF, where
the client may not have the final info on the scope.)

Then 2 would definitely work and is much simpler. I was thinking it may be
restricting. But, it's best to avoid the complexity of additional checks on
combinations of permissions to see if the request can be satisfied.

Thanks for your feedback.
--Cigdem



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

Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Cigdem Sengul]

Hello,


It gets interesting when the scope is more restricted than the subscription
request.

For instance, the scope is sport/+

But subscription is sport/#


Should this be refused? Obviously the subscriber is attempting to subscribe
to more than it has permission for. But does the broker still allow the
subscription but reduce it to "sport/+"?

>
>
> [JLS] Given that this is not defined in the base MQTT specification, most
> clients would not expect this if the ACE is grafted on the side of the
> program.  I would therefore say this is a “not authorized” and go on.
>
>
>

[CS] Agreed. Another issue that we should say something about is the case
when multiple permission strings aggregated together gives enough
permission to the subscription request, based on the _current_ topic
hierarchy.
Example:
Scope strings in the token were: publish_sport/tennis
publish_sport/basketball
and then the client asks for publish_sport/+

If tennis and basketball are the only topics under sport, then this is a
valid request.
But, if the topic hierarchy is changes during the connection time (adds
sport/baseball) then subscriber gets PUBLISH messages for something they
should not.
When topic subscriptions are not protected, the broker would send anything
at the single level for sport/+ and would not worry about the new additions
after the subscription.

When topic subscriptions are protected, the Broker can choose to do two
things:
1) Allow the subscription but internally subscribe the clients to
sport/basketball and sport/tennis only.
or
2) Reject the subscription and the client needs to ask for subscriptions
that are a subset or equal to their permission strings. So the client
specifically needs to ask for publish_sport/tennis and
publish_sport/basketball matching its scope strings. But then scope
parameter cannot be optional and must be included in the AS response.
or
3) Allow the subscription, when a new level is added, check the permissions
of all active subscribers, send DISCONNECT if the current permissions do
not apply to the new hierarchy.

1 would need to be again signalled to the client, 2 might be too
restrictive, and 3 may introduce a processing load if things are changing
all the time (which I do not expect).
Leaning towards 3...  Any thoughts?

--Cigdem






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

Re: [Ace] Review of draft-ietf-ace-mqtt-tls-profile-03

[Cigdem Sengul]

Thank you for this review, Jim.
Responses inline.

On Wed, Jan 1, 2020 at 10:33 PM Jim Schaad  wrote:

>
> 2.2.2 - para 1, the last sentence seems to imply that the first connection
> to publish to authz-info is not being done over a TLS connection.  But the
> sentence before that states that a TLS connection MUST be used for this.
> Perhaps s/and is expected to try reconnecting over TLS./and reconnects,
> potentially using client authentication with TLS./
>

[CS] Yes, that part reads confusing.
The aim was to say client authentication is not done over TLS, but
connection can be over TLS.
What it should be saying:
Client can use either mqtt or mqtts to connect to the broker, but does only
server validation, to push the token.
After pushing the token, it is expected to do TLS:Known(RPK/PSK)-MQTT:none.
(Although for PSK the token can be in psk_identity).
Issue created:  https://github.com/ace-wg/mqtt-tls-profile/issues/37


> 2.2.2 - I am unclear under what circumstances you could end put with a
> token
> which does not parse when processing a PUBLISH message.  If the token
> cannot
> be parsed at connection time, that I can understand.  However having parsed
> the token then it does not make sense that the token becomes not parsable
> at
> the time of publishing.  Am I missing something?
>

[CS] There is a misunderstanding. The PUBLISH message refers to the actual
PUBLISH message to the "authz-info" topic which contains the token i.e.,
this may not parse to a token. (The PUBLISH message is not for other
messages that are permissioned in the token.)
The client connects (without much security), publishes the token to the
public "authz-info" topic, which only the broker can read.
Then, disconnects, and tries to connect with ace security.

Since MQTT v5 can return error messages in response to PUBLISH messages,
here, this is used to signal to the publisher that there is something wrong
with its token.

Added: https://github.com/ace-wg/mqtt-tls-profile/issues/38


>
> 2.2.2 - The last paragraph is causing me confusion.  Is this supposed to be
> referencing the RS or the AS?  If it is the AS, then I don't see how there
> could be any confusion.  Please expand this so it is clearer.
>

[CS] This is a typo - it should be RS.
 https://github.com/ace-wg/mqtt-tls-profile/issues/39


> 2.2.4 - I am having a problem with trying to parse the content of the AUTH
> property.  I have no problems with 2.2.4.3 because this is a zero length
> sequence of bytes.  However for 2.2.4.1 and 2.2.4.2 there is a token
> (possibly binary with no length prefix) followed by an optional binary
> cryptographic value.  For introspection, I would need to figure out the
> length of the token before I could make a guess at the length of the
> cryptographic value.  However given that there is no divider this does not
> seem possible.  This may also become a problem for the response from the
> client in the event that there is a change from an 8-byte nonce to a
> variable length one.
>

[CS] Not specified a  format, because I  thought we discarded the idea of
using the variable-length nonce based on the meeting in Singapore.
What would you suggest - introduce a specific format to accommodate
variable length?
length_of_token+binary data for token+(the rest is cryptographic value)?
 https://github.com/ace-wg/mqtt-tls-profile/issues/40


> 2.2.4.1 - In my view it is not the secret, but the content that is being
> obtained from the TLS exporter.  That is one is signing (or MACing) the
> exporter value not using that value to compute a MAC on something else.
> While it is true that only the two parties know that value, exposure to a
> third party does not lead to a compromise.
>

[CS] I see - so reword "secret" to "content".
Or do you have a suggestion for wording?
https://github.com/ace-wg/mqtt-tls-profile/issues/41

>
> 2.2.4.3 - I am not sure if the text is supposed to require an empty
> authentication data field or to allow for the authentication data field to
> be absent as well.
>

[CS] I checked whether it would be a protocol error to have only
Authentication Method in MQTT, and it is not.
Then it is best to omit authentication data field.
Will correct the text that the document allows the CONNECT message to have
an Authentication Method set to 'ace' and allows to omit the Authentication
Data field.
https://github.com/ace-wg/mqtt-tls-profile/issues/42


>
> 3 - It might be worth while to put a pointer to section 4.7 of the MQTT V5
> spec here so that there is an indication of what the different wild card
> characters do.  I had to pop over there to make sure that I could figure it
> out.
>

[CS] Will do.
https://github.com/ace-wg/mqtt-tls-profile/issues/43


> 3.1 - Should you state that for a QoS of 0, the client should close the
> connection w/ an '0x87' in the event of an authorization failure?  I think
> that this is supposed to happen but you have left it open.
>

[CS]
Yes, I must have cut some text out. QoS of 0, the client is 

Re: [Ace] draft-ietf-ace-mqtt-tls-profile - Validating a subscription is in scope

[Cigdem Sengul]

Hello Jim,

Topic filter and permission filter matching is something that I would like
to have a better resolution as well.
Responses inline.
On Mon, Jan 13, 2020 at 1:38 AM Jim Schaad  wrote:

> I have run across an interesting question for doing validation of
> subscriptions that I would like to get an opinion on.
>
> When doing a publish, there is not an issue.  One simply takes the set of
> values in the scope field as topic filters and checks the publication topic
> against the set of permissible publication topic filters in the scope.


[CS] Yes.


>
> When doing a subscribe, there are four distinct cases that can arise:
> 1.  The subscription is for a single topic and either is or is not
> successfully matched against the scope topic filter.
>

[CS] Yes.


> 2.  The subscription is for a topic filter and it is identical to the scope
> topic filter.
>

[CS] Yes.

> 3.  Both are topic filters and are not the same.  Is one supposed to do
> some
> type of subset matching on the two filters or does one always say that this
> is not a match.  This is not addressed in the MQTT document and I am not
> sure where it would be addressed.   As an example:
>
> Scope value is subscribe_sport/#
> Subscription topic is sport/tennis/#
>
> The second is clearly a subset of the first and thus it would seem logical
> to include it, but it gets more complicated if one instead asks for
>
> Subscription topic is sport/+
>
> In this case the two wild cards are not the same value.
>

We were thinking using a subset matching to check whether the token would
permit the subscription request.
For your example, a subscription request
"sport/+" would cover all the single-levels under "sport" - including
"sport/" but not "sport" .
So if the scope is "subscribe_sport/#" which covers all multi-levels under
"sport" (including "sport", the subscription request should still succeed.
(i.e., the subscriber has a larger set of permissions than the request)

Now when the broker receives a publication with "sport/tennis" then it
should pass this message on to the subscriber.
When it receives a publication "sport/tennis/player1" then it should not.
This would be normal broker behaviour as well (without using ace).

It gets interesting when the scope is more restricted than the subscription
request.
For instance, the scope is sport/+
But subscription is sport/#

Should this be refused? Obviously the subscriber is attempting to subscribe
to more than it has permission for. But does the broker still allow the
subscription but reduce it to "sport/+"?
Currently would opt for the former, because the second option may be hard
to signal to the subscriber - the SUBACK reason string together with the
user property field may be used for such feedback to the subscriber but
would need to be defined properly.

--Cigdem

>
> 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] Fwd: New Version Notification for draft-ietf-ace-mqtt-tls-profile-03.txt

[Cigdem Sengul]

Hello,

I've submitted a new version to update my e-mail address, as my affiliation
is going to change in the next year.

The v03 does have other changes, as I outlined in my previous email, which
still needs to be discussed.

The main changes are:
 Version 02 to 03:
 1) Added the option of Broker certificate thumbprint in the 'rs_cnf' sent
to the Client.
 2) Clarified the use of a random nonce from the TLS Exporter for PoP,
added to the IANA requirements that the label should be registered.
 3) Added a client nonce, when Challenge/Response Authentication is used
between Client and Broker.
 4) Clarified the use of the "authz-info" topic and the error response if
token validation fails.
 5) Added clarification on wildcard use in scopes for publish/subscribe
permissions
 6) Reorganised sections so that token authorisation for publish/subscribe
messages are better placed.
7) Clarified protection of Application Message payload as out of scope, and
cited draft-palombini-ace-coap-pubsub-profile for a potential solution

Thanks,
--Cigdem

-- Forwarded message -
From: 
Date: Fri, Dec 20, 2019 at 1:47 PM
Subject: New Version Notification for draft-ietf-ace-mqtt-tls-profile-03.txt
To: Paul Fremantle , Cigdem Sengul <
csen...@acm.org>, Anthony Kirby 



A new version of I-D, draft-ietf-ace-mqtt-tls-profile-03.txt
has been successfully submitted by Cigdem Sengul and posted to the
IETF repository.

Name:   draft-ietf-ace-mqtt-tls-profile
Revision:   03
Title:  MQTT-TLS profile of ACE
Document date:  2019-12-20
Group:  ace
Pages:  27
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-tls-profile-03.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
Htmlized:
https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-03

Abstract:
   This document specifies a profile for the ACE (Authentication and
   Authorization for Constrained Environments) framework to enable
   authorization in an MQTT-based publish-subscribe messaging system.
   Proof-of-possession keys, bound to OAuth2.0 access tokens, are used
   to authenticate and authorize MQTT Clients.  The protocol relies on
   TLS for confidentiality and server authentication.




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] Review for draft-palombini-ace-coap-pubsub-profile

[Cigdem Sengul]

Hello Ben,
Response below.

>  >
> >
>
> > CS: I see that I wasn't clear in my thinking before and mixed up things.
> I
> > was trying to understand how groups map to topics and the topic
> hierarchy;
> > and how group maintenance scales with the increasing number of topics,
> > publisher and subscribers. Said another way, who creates groups, and
> > creates/updates keys for these groups to be maintained in the KDC?
> >
> > I agree topic hierarchies require more thought. Here is my second attempt
> > at explaining my thinking, which is by no means complete:
> > In MQTT, it is possible to publish to all levels in a topic hierarchy
> e.g.,
> > if you have sport/tennis/player1/rankings, it is possible to publish to
> the
> > sport, sport/tennis, sport/player1, sport/player1/rankings...
> > One option is to have as many keys as the nodes on the hierarchy
> > independent of actual publishers and subscribers to them.  (Assuming this
> > hierarchy is pre-built, and AS2 maintains a complete topic-key database).
> > So, if publisher P1 comes with rights to publish to sport/tennis - he
> gets
> > the keys for that. But, if he comes with the right to publish to
> > sport/tennis/#, he gets multiple keys, one each for every node under
> > tennis.
>
> Having to always send all the keys would get frustrating (and/or expensive
> in terms of bytes!), but the "other option" below feels quite messy with
> respect to having to push out updates when membership/number of groups
> changes.  I suppose the right balance depends on actual usage patterns, but
> I would mostly expect a flow where permissions on a hierarchy grant the
> ability to get any (per-topic) key from the hierarchy, but you still have
> to explicitly request the individual key for the individual topics you are
> going to post to, to be of most generic applicability.  Am I forgetting a
> reason why that's not possible?
>
> Thanks,
>
>
Yes, both have problems - mainly used them to talk about the differences
between (semi-)static grouping (topics define groups) and dynamic grouping
(active publisher/subscribers and their topic permissions determine groups).

Yes, a token with scopes that use the wildcard will give you the right to
get any key from the hierarchy. In the "first approach," you would need the
get the specific one for the individual topic because any number of
publisher/subscribers may be on that topic (but not on others).
If I understand correctly, you suggest that the client asks for the right
key just-in-time before a publish/subscribe message?
This is a good solution if the client can connect to AS2 at all times, but
in ACE, I thought, we did not assume ASes are always reachable by clients.
Therefore, I was always thinking of a scenario where the client is
provisioned with the right keys beforehand (determined by their
permissions).

But the "second option", where the same encryption key may be used across
different topics,  has the same connectivity requirements due to rekeying
expected as groups change.

I hinted this in my previous e-mail by having to consider rekeying
policies, as I haven't seen it mentioned in coap-pub-sub.

Need to also consider rekeying as a separate problem that needs to be
addressed regardless of what approach is taken: ace-key-groupcomm refers
to  [RFC2093], [RFC2094] and [RFC2627] for rekeying mechanisms and I am not
exactly sure how to use them for client-broker communication.

 ace-key-groupcomm also states: If the application requires forward
security, the KDC MUST generate new group keying material and securely
distribute it to all the current group members but the leaving node, using
the message format of the Key Distribution Response"
If it is the AS2 (KDC) that needs to rekey groups, then AS2 should be able
to connect to the clients and push this information? Am I missing something
here?

(In MQTT, things were easier when tokens expire. The Broker knows a token
expired and disconnects the client, which forces the client to get a new
token. But, the Broker here has no idea of rekeying.  So, the trigger for
that needs to come from AS2. )

Regards,
--Cigdem


> Ben
>







>
> > The other option is creating groups dynamically and subtopics inherit
> > authorisations (as captured by the wildcards), i.e., publisher and
> > subscribers that have an exact match in their topic filters form a group.
> > Going back to the previous example, assuming AS2 is generating the keys
> > (need to read the groupcomm in detail to understand how the KDC and its
> > endpoints work in general), I imagine something like this may work:
> > Publisher P1 - publish_sport/tennis/#  -> AS2 checks if a matching group
> > exists, doesn't find one, generates the key, and hands it out to P1,
> stores
> > the mapping.
> > Publisher P2 - publish_sport/tennis/# -> AS2 checks if a matching group
> > exists, find one, gives out the key to P2.
> > Subscriber S1 - publish_sport/tennis/# -> AS2 checks if a matching group
> > exists, find one, gives out 

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

[Cigdem Sengul]

Dear Francesca,

Thank you for your responses to my comments.
My comments are inline.

>
>
> In the following, I list a few things reading the draft made me think,
> especially in its applicability to MQTT:
>
> (1) What is planned to make this document a generic pubsub solution? Will
> there a generic architecture section, and specific descriptions for each of
> the protocols?
>
>
>
> FP: Yes, I am planning to make some updates to the text to make this
> generic. In general, I think the structure of the draft will be the same,
> but each section would either have a sentence or (if longer text is needed)
> a subsection talking about the different alternatives. For example, Section
> 2 would remove current specific text about CoAP pubsub (only talk about
> general pubsub) and would replace that text with an additional paragraph
> mentioning that the pubsub protocol can be CoAP or MQTT. Section 3 would
> have 2 subsections, coap_pubsub_app and mqtt_pubsub_app, etc.
>
>
>

CS: YEs, sounds good.


> For instance, if an MQTT client implements this,  the client would talk to
> AS1 to get a token based on the way we describe in the mqtt-tls profile,
> and then get keying material for topics from AS2.
>
> I expect the MQTT client would use a different profile name like
> mqtt_tls_app to signal to AS1 that it is supporting the application layer
> security. This is because the draft hints that there should be a policy
> agreement between AS1 and AS2: “Note that AS1 and AS2 might either be
> co-resident or be 2 separate physical entities, in which case access
> control policies must be exchanged between AS1 and AS2, so that they agree
> on rights fo  joining nodes about specific topics.”
>
>
>
> FP: That is all correct. Moreover, we can also discuss details such as
> what communication protocol the Client uses to talk to AS2. Right now
> ace-key-groupcomm is only defined for CoAP, but if MQTT prefers to use
> HTTP, that is very easy to define.
>
>
>
>
> (2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake,
> the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub
> draft describes these, expectedly, in CoAP. Will there be support for HTTPS?
>
>
>
> FP: I promise I did not read this question before answering the text above
> :) Yes. This is really easy to specify, we already do this with CBOR/JSON,
> in ace-key-groupcomm:
>
>
>
> The ACE framework is based
>
>on CBOR [RFC7049], so CBOR is the format used in this specification.
>
>However, using JSON [RFC8259] instead of CBOR is possible, using the
>
>conversion method specified in Sections 4.1 and 4.2 of [RFC7049].
>
>
>
> We would add CoAP/HTTP in the same way ("CoAP is default, but HTTP works
> the same way"). Then the pubsub-profile could specify which protocol is
> used in the different profiles.
>

CS: Cool. Because, I imagine a client or its AS would follow the same
protocol, HTTPS,  to talk to the ASes, and then talk to MQTT to RS.


> (3) In the mqtt_tls profile, the AS grants tokens that identify both
> “publish” and “subscribe” rights and the topics by adding scopes in the
> format, e.g. “publish_topic1” “subscribe_topic2/#”..  This format allows
> representing all publish/subscribe permissions concisely for the client
> which may be acting both as a publisher and a subscriber.
>
> In the coap-pubsub, this is separated between AS1 and AS2. “AS1 hosts the
> policies about the Broker: what endpoints are allowed to Publish on the
> Broker.” “The AS2 hosts the policies about the topic: what endpoints are
> allowed to access what topic. “
>
> The coap-pubsub also permits that AS1 can host policies about what
> endpoints are allowed to Subscribe to the Broker.
>
>
>
> However, wouldn’t this separation between AS1 and AS2 have the following
> issue: Publisher P, having the permission to publish to topic1 and hence,
> successfully getting an access token from AS1, then goes ahead and sends a
> PUBLISH on topic 2, which it doesn’t have a right to publish.
>
> Wouldn't the broker would pass this message to subscribers, and the
> subscribers would discard the message because the publisher does not belong
> to their “publishers list” (subscribers have all the public keys of all
> publishers). Have I missed something, does the draft protect against this
> at the broker?
>
>
>
> FP: No, the broker would not accept this message. In fact, during the ACE
> exchange between Publisher, AS1, and Broker, the Publisher would post a
> token to the Broker that contains the resource it is allowed to publish to,
> namely in this case topic 1. If it does have rights to publish to topic 2
> as well, that would be included in the token. That is covered by the
> transport profile used, as you mentioned (MQTTL-TLS/CoAP OSCORE).
> Orthogonally to this, when getting the keys from AS2 to protect the
> publication, if the Publisher has tried to publish to topic 2 without
> having the correct content encryption keying material, the decryption 

[Ace] Version -03 prep for draft-ietf-ace-mqtt-tls-profile

[Cigdem Sengul]

Dear Jim and Daniel,

As discussed in Singapore, we've started working on the -03 based on the
comments we've received.

https://github.com/ace-wg/mqtt-tls-profile/tree/v-03-WIP

The main changes are:
 Version 02 to 03:
 1) Added the option of Broker certificate thumbprint in the 'rs_cnf' sent
to the Client.
 2) Clarified the use of a random nonce from the TLS Exporter for PoP,
added to the IANA requirements that the label should be registered.
 3) Added a client nonce, when Challenge/Response Authentication is used
between Client and Broker.
 4) Clarified the use of the "authz-info" topic and the error response if
token validation fails.
 5) Added clarification on wildcard use in scopes for publish/subscribe
permissions
 6) Reorganised sections so that token authorisation for publish/subscribe
messages are better placed.
7) Clarified protection of Application Message payload as out of scope, and
cited draft-palombini-ace-coap-pubsub-profile for a potential solution

Could you provide input regarding the following:
1) Based on Jim's suggestion I added a statement that says:
 The AS MAY include the thumbprint of the RS's X.509 certificate in the
'rs_cnf'
(thumbprint as defined in ),
 then the client MUST validate the RS certificate against this thumbprint.
Is this implemented by rs_cnf = x5t

and then the client computes the hash and checks against x5t?


Regarding other questions raised by Jim on OASIS certificate guidelines and
the mqtt/mqtt(s), I have not managed to get more information than:

   1.

   there is no official UIR scheme but there is a community wiki entry
   which proposes something:
   https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme. The MQTT 5
   server redirection feature uses a very simple way of indicating a server
   reference, see
   https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html#_Server_redirection
   2.

   There's currently no certificate validation document. The
   recommendations linked in the spec can be found here:
   https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901280
   .

2) I temporarily added the exporter label to our draft but will wait on the
final decision on that.
So, if it is defined and registered in another document, I can refer to it.

I will push changes as 03 once there is an agreement on how to resolve
these issues.

Kind regards,
--Cigdem
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Certificate processing for MQTT

[Cigdem Sengul]

Hello Jim,

Thank you for your email. I am in the process of revising the document for
the December update agreed in Singapore, so these comments are extremely
helpful.
Comments are inline.

On Thu, Dec 5, 2019 at 6:19 AM Jim Schaad  wrote:

> I got to the point of needing to start producing and validating
> certificates
> for MQTT and started running into some questions as well as starting to
> pickup some odd information that this document does not point to.
>
> 1.  Should probably reference the mqtt(s) URI scheme, I am however somewhat
> irritated that it is not a registered scheme with IANA.
>

Indeed, we used MQTT over TLS to mean MQTTS, though it is not mentioned
explicitly in the MQTT v5 OASIS spec,
but here: https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme
Do you suggest we reference this?
The latest I know: "The URI scheme has been discussed by the technical
committee a few times. The proposal was to produce a committee note rather
than make it a formal part of the spec."
based on this - https://github.com/mqtt/mqtt.github.io/issues/41
I will see if I can find more information from OASIS.


2.  Has OASIS done anything sort of document for certificate validation.  As
> an example is there an OID defined for extended key usage?
>

This is what is mentioned in the MQTT v5 for authenticating the AS with a
certificate:
"Implementations providing MQTT service for multiple hostnames from a
single IP address should be aware of the Server Name Indication extension
to TLS defined in section 3 of [RFC6066]
.
This allows a Client to tell the Server the hostname of the server it is
trying to connect to."

I also found the following information when first writing the draft:
https://www.oasis-open.org/committees/download.php/50161/X-MQTT-Security.txt
that goes into some detail but did not cite it because it did not look
official. However, it at least mentions things like TLS versions and
certificate types.


>
> 3.  What should be said about matching data in the response from the AS and
> the certificate.  What should be said about matching for raw public keys.
> I
> think that later is easy as it should just match the rs_cnf returned from
> the AS, but I don't know what should be said for certificates.
>

At the moment I have the following text:

The Broker MUST be authenticated during TLS handshake.  If the Client
   authentication included TLS:Known(RPK/PSK), then the Broker is
   authenticated using the respective method.  For the other Client
   Authentication cases, to authenticate the Broker, the client MAY
   either have the ability to receive and validate a server-side
   certificate or an RPK from the Broker checked against the 'rs_cnf' parameter
   in the token.


The reason why I did not go into more detail for TLS/certificate use
on the server-side,

was because MQTT OASIS standard recommends it but does not go into
detail (as discussed in the previous points).

And my experience with mqtt brokers that they define how to set it up
in their config pages:

e.g., HiveMQ with BoringSSL
https://www.hivemq.com/docs/4.2/hivemq/security.html (HiveMQ is what
Edinburgh colleagues are implementing ACE mqtt-tls profile with now).

or Mosquitto with OpenSSL https://mosquitto.org/man/mosquitto-conf-5.html

 https://mosquitto.org/man/mosquitto-tls-7.html


My assumption was that for MQTT developers who have opted for a
certain MQTT implementation and want to use server-side certificates,

they would continue configuring the server-side TLS as they always do,

and then use the ACE  plugin to do the client authentication/authorisation.



>
> 4.  With the definition of some guidance in COSE, should there be a field
> for doing certificates in the rs_cnf - returning a fingerprint not the
> entire certificate.
>

This is interesting - do you mean working with this draft:
https://tools.ietf.org/html/draft-ietf-cose-x509-04

 Thanks,
--Cigdem

>
> 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] Review for draft-palombini-ace-coap-pubsub-profile

[Cigdem Sengul]

Hello,


As I remotely promised in the WG meeting in Singapore, here is my review of
the pubsub-coap document.


When reviewing the document, I have kept two things in mind: how the
document reads now, and whether it can easily be extended to include MQTT
as well.  I’ve understood including MQTT is in scope for this document in
the workgroup meeting in Singapore. I would be happy to help, if you need
me to, for MQTT-specific contributions to this draft.  Doing this would
allow the mqtt_tls profile to progress independently of this document by
stating that content protection is out of scope for mqtt_tls profile and
referring to this document for a solution.


I want to repeat my support for the adoption of this profile, as it
addresses a significant problem for publishers to constrain the content of
their publications to only their subscribers. It does handle the multiple
publishers to a single topic case well (allowing subscribers to learn about
all the publishers to a specific topic).


In the following, I list a few things reading the draft made me think,
especially in its applicability to MQTT:

(1) What is planned to make this document a generic pubsub solution? Will
there a generic architecture section, and specific descriptions for each of
the protocols?

For instance, if an MQTT client implements this,  the client would talk to
AS1 to get a token based on the way we describe in the mqtt-tls profile,
and then get keying material for topics from AS2.

I expect the MQTT client would use a different profile name like
mqtt_tls_app to signal to AS1 that it is supporting the application layer
security. This is because the draft hints that there should be a policy
agreement between AS1 and AS2: “Note that AS1 and AS2 might either be
co-resident or be 2 separate physical entities, in which case access
control policies must be exchanged between AS1 and AS2, so that they agree
on rights fo  joining nodes about specific topics.”


(2) If we keep AS1 as the mqtt-tls profile AS, then for consistency sake,
the MQTT client would expect to talk to HTTPS to AS2, but the coap-pubsub
draft describes these, expectedly, in CoAP. Will there be support for HTTPS?


(3) In the mqtt_tls profile, the AS grants tokens that identify both
“publish” and “subscribe” rights and the topics by adding scopes in the
format, e.g. “publish_topic1” “subscribe_topic2/#”.  This format allows
representing all publish/subscribe permissions concisely for the client
which may be acting both as a publisher and a subscriber.

In the coap-pubsub, this is separated between AS1 and AS2. “AS1 hosts the
policies about the Broker: what endpoints are allowed to Publish on the
Broker.” “The AS2 hosts the policies about the topic: what endpoints are
allowed to access what topic. “

The coap-pubsub also permits that AS1 can host policies about what
endpoints are allowed to Subscribe to the Broker.


However, wouldn’t this separation between AS1 and AS2 have the following
issue: Publisher P, having the permission to publish to topic1 and hence,
successfully getting an access token from AS1, then goes ahead and sends a
PUBLISH on topic 2, which it doesn’t have a right to publish.

Wouldn't the broker would pass this message to subscribers, and the
subscribers would discard the message because the publisher does not belong
to their “publishers list” (subscribers have all the public keys of all
publishers). Have I missed something, does the draft protect against this
at the broker?


Differently, with the current way mqtt_tls scopes are described, AS1 would
need to know not only who can publish or subscribe, but also the policies
on topics.


(4) That brings me to another point regarding this note in coap-pubsub
profile. The profile says: “How the policies are exchanged [between AS1 and
AS2] is out of scope for this specification.” I wonder whether the token
the client gets from AS1 should also be usable towards AS2, and AS2 is
replaced with an RS for retrieving the keying material for topics (more on
this later), i.e., AS2 does not need to host/manage/coordinate policies
with AS1.


(5) Regarding groups and group memberships, it seems like for the draft
group = a single topic.


In MQTT, topics can have level separators and multi-level (#) and
single-level (+) wildcards.  Similarly, CoAP would also have hierarchies.


Consider the case when a PUBLISHER is allowed to publish to
sport/tennis/player1/# but not sport/tennis/player2/#.  The players'
directory may have sub-levels like “rankings”.

And a subscriber has permissions to get content from sport/tennis/#.

It seems like sport/tennis/player1 would be a group, and
sport/tennis/player2 be another group.

And, the subscriber needs to be in two groups. This is fine, I believe,
according to this document.


In MQTT token scopes, we also accepted that a publisher represents its
PUBLISH rights with topic filters (note a PUBLISH message cannot be sent to
a filter, but the topic filters are useful in summarising 

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

[Cigdem Sengul]

Hello Daniel,

I am interpreting them as they are saying the same thing. Am I reading the
following correctly?

RFC 6749 defines the conditions under 401 can be returned:

The authorization server responds with an HTTP 400 (Bad Request)
   status code (unless specified otherwise)

invalid_client
   Client authentication failed (e.g., unknown client, no
   client authentication included, or unsupported
   authentication method).  The authorization server MAY
   return an HTTP 401 (Unauthorized) status code to indicate
   which HTTP authentication schemes are supported.  If the
   client attempted to authenticate via the "Authorization"
   request header field, the authorization server MUST
   respond with an HTTP 401 (Unauthorized) status code and
   include the "WWW-Authenticate" response header field
   matching the authentication scheme used by the client.


ietf-ace-oauth-authz says it follows the same conditions for 4.01
defined in RFC6749.

A response code equivalent to the CoAP code 4.00 (Bad Request)
  MUST be used for all error responses, except for invalid_client
  where a response code equivalent to the CoAP code 4.01
  (Unauthorized) MAY be used under the same conditions as specified
  in Section 5.2 of [RFC6749]
<https://tools.ietf.org/html/rfc6749#section-5.2>.


Thanks,

--Cigdem


On Wed, Nov 27, 2019 at 4:10 PM Daniel Migault 
wrote:

> Hi,
>
> Changing the thread name.
>
> If I were using CoAP/JSON, I think 6749 and ace-oauth-authz may have
> different error 4.00/4.01.
>
> My interpretation is that I would recommend ace-oauth-authz would result
> in implementation sending 4.00 and 4.01 while 6749 would always send 4.00.
> As a result, I would rather recommend ace-oauth-authz. Am I missing
> something ?
>
> Yours,
> Daniel
>
> -Original Message-
> From: Daniel Migault
> Sent: Wednesday, November 27, 2019 11:03 AM
> To: Ludwig Seitz ; Cigdem Sengul <
> cigdem.sen...@gmail.com>
> Cc: ace@ietf.org
> Subject: RE: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> Hi,
>
> Just for clarification, as the one starting the thread, I believe that it
> is clear that  draft-ietf-ace-oauth-authz-26 has no issue and can be moved
> forward.
>
> Yours,
> Daniel
>
>
>
> -Original Message-
> From: Ludwig Seitz 
> Sent: Wednesday, November 27, 2019 8:36 AM
> To: Cigdem Sengul ; Daniel Migault <
> daniel.miga...@ericsson.com>
> Cc: ace@ietf.org
> Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> If you are using JSON-based interactions, I believe that the most
> straightforward way is to refer to RFC6749 for the error messages as you
> currently do. I don't find this confusing or problematic, but YMMV.
>
> /Ludwig
>
> 
> From: Cigdem Sengul 
> Sent: Thursday, November 21, 2019 10:27 AM
> To: Daniel Migault
> Cc: Ludwig Seitz; ace@ietf.org
> Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> Hello,
>
> Ludwig, I agree that the current draft describes specifically for when
> CBOR is used.
> When CBOR is not used, I have read it as it will act similar to Section
> 5.2 of [RFC6749]<https://tools.ietf.org/html/rfc6749#section-5.2> as you
> have indicated also in the ace-oauth-authz document.
>
> Therefore, instead of an indirect reference to RFC6749 by referencing
> ace-oauth-authz, we used a direct reference to explain what the error
> response should be.
>
> Is this problematic? or confusing?
>
> I can reword in mqtt_tls draft something like:
> "As described in [ace-oauth-authz] the error responses for JSON-based
> interactions with AS follow RFC6749. When CBOR is used, the interactions
> MUST implement [ace-oauth-authz]"
>
> Would that help?
>
> Thanks,
> --Cigdem
>
>
>
> On Thu, Nov 21, 2019 at 3:06 AM Daniel Migault  40ericsson.@dmarc.ietf.org<mailto:40ericsson@dmarc.ietf.org>>
> wrote:
> Hi Ludwig,
>
> Thanks for the feed back. I was raising the issue before it got forgotten.
> , and I must say I did not checked whether it had been addressed or not, as
> I did not remember this had been raised for the ace-oauth-authz document.
>
> What you are saying is that the draft has been updated already. I will
> have a closer look at it, and ask mqtt-profile to confirm the current text
> is fine.
>
> Thanks!
> Daniel
>
> -Original Message-
> From: Ace mailto:ace-boun...@ietf.org>> On Behalf
> Of Ludwig Seitz
> Sent: Thursday, November 21, 2019 10:51 AM
> To: ace@ietf.org<mailto:ace@ietf.org>
> Subject: Re: [Ace]

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

[Cigdem Sengul]

Hello,
I support the adoption of this document and will be interested in reviewing
it.

Kind regards,
--Cigdem

On Tue, Nov 19, 2019 at 8:45 AM Daniel Migault  wrote:

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

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

[Cigdem Sengul]

Hello,

Ludwig, I agree that the current draft describes specifically for when CBOR
is used.
When CBOR is not used, I have read it as it will act similar to Section 5.2
of [RFC6749]  as you have
indicated also in the ace-oauth-authz document.

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

Is this problematic? or confusing?

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

Would that help?

Thanks,
--Cigdem



On Thu, Nov 21, 2019 at 3:06 AM Daniel Migault  wrote:

> Hi Ludwig,
>
> Thanks for the feed back. I was raising the issue before it got forgotten.
> , and I must say I did not checked whether it had been addressed or not, as
> I did not remember this had been raised for the ace-oauth-authz document.
>
> What you are saying is that the draft has been updated already. I will
> have a closer look at it, and ask mqtt-profile to confirm the current text
> is fine.
>
> Thanks!
> Daniel
>
> -Original Message-
> From: Ace  On Behalf Of Ludwig Seitz
> Sent: Thursday, November 21, 2019 10:51 AM
> To: ace@ietf.org
> Subject: Re: [Ace] comment on draft-ietf-ace-oauth-authz-26
>
> On 21/11/2019 03:29, Daniel Migault wrote:
> > Hi,
> >
> > This only concerns potential clarification of the text.
> >
> > While reviewing mqtt-profile draft I raised an issue regarding the
> > reference for Oauth [RFC6749] while the remaining of the document
> > references draft-ietf-ace-oauth-authz [1]. My reading of
> > draft-ietf-ace-oauth-authz section 5.6.3
> >  ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>.
> > was the same of the one of mqtt-profile coauthors, that is error
> > mandates the use of CBOR. Discussing this with others it seems a mis
> > interpretation of  draft-ietf-ace-oauth-authz section 5.6.3
> > 
> [2].
> >
> > I believe that is nice this is a mis-interpretation, but I would
> > recommend that the text makes it more explicit the use of JSON is
> > permitted. This seems to me a request to clarify the text.
> >
> > Yours,
> > Daniel
> >
>
> I would be happy to add more clarification, but I'm currently at a loss of
> what that would be. Most of the bullets you cited already modify the MUSTs
> with "...when CBOR is used" or something similar to the same effect. The
> idea was to express: You can use the vanilla OAuth interactions based on
> JSON, but if you use CBOR then do it as specified here.
>
> I am happy to take suggestions.
>
> /Ludwig
>
> > [1]
> > """
> >
> > In the case of an error, the AS returns error responses for HTTP-
> > based interactions as ASCII codes in JSON content, as defined in
> > Section 5.2 of RFC 6749  <
> https://tools.ietf.org/html/rfc6749#section-5.2>  [RFC6749  <
> https://tools.ietf.org/html/rfc6749>].
> >
> > """
> >
> > [2]
> > """
> >
> >
> > 5.6.3
> > <
> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-26#section-5.6.3>.
> > Error Response
> >
> >
> >
> > The error responses for CoAP-based interactions with the AS are
> > generally equivalent to the ones for HTTP-based interactions as
> > defined inSection 5.2 of [RFC6749]  <
> https://tools.ietf.org/html/rfc6749#section-5.2>, with the following
> exceptions:
> >
> > o  When using CBOR the raw payload before being processed by the
> >communication security protocol MUST be encoded as a CBOR map.
> >
> > o  A response code equivalent to the CoAP code 4.00 (Bad Request)
> >MUST be used for all error responses, except for invalid_client
> >where a response code equivalent to the CoAP code 4.01
> >(Unauthorized) MAY be used under the same conditions as specified
> >inSection 5.2 of [RFC6749]  <
> https://tools.ietf.org/html/rfc6749#section-5.2>.
> >
> > o  The Content-Format (for CoAP-based interactions) or media type
> >(for HTTP-based interactions) "application/ace+cbor" MUST be used
> >for the error response.
> >
> > o  The parameters "error", "error_description" and "error_uri" MUST
> >be abbreviated using the codes specified in Figure 12, when a CBOR
> >encoding is used.
> >
> > o  The error code (i.e., value of the "error" parameter) MUST be
> >abbreviated as specified in Figure 10, when a CBOR encoding is
> >used.
> > /+-\
> >
> > | Name   | CBOR Values |
> > |+-|
> > | invalid_request|  1  |
> > | invalid_client |  2  |
> > | invalid_grant

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

[Cigdem Sengul]

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  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] Fwd: FW: New Version Notification for draft-ietf-ace-mqtt-tls-profile-02.txt

[Cigdem Sengul]

Dear ace,

I have just submitted a new version of the mqtt_tls profile to address Jim
and Daniel's comments.
Mainly the changes include:

 Version 01 to 02:


   o  Expanded Client connection authorization to capture different

  options for Client and Broker authentication over TLS and MQTT


   o  Removed Payload (and specifically Client Identifier) from PoP

  validation in favor of using tls-exporter for a TLS-session

  based challenge.


   o  Moved token transport via "authz-info" topic from the Appendix to

  the main text.


   o  Clarified Will scope.


   o  Added MQTT AUTH to terminology.


   o  Typo fixes, and simplification of figures.

Tried to capture all input, however,
I am aware that the part that uses tls-exporter for PoP is under-specified.
However, this got a bit confusing to specify after reading the ace-coap-est
channel binding and tls-unique discussion.
Also looked at other drafts like QUIC, TTLS etc. that use tls-exporter to
export keying material and challenge information.
It seems necessary to register a new label for the exporter?

Thanks,

--Cigdem




On 03/11/2019, 22:57, "internet-dra...@ietf.org" 
wrote:


A new version of I-D, draft-ietf-ace-mqtt-tls-profile-02.txt
has been successfully submitted by Cigdem Sengul and posted to the
IETF repository.

Name:   draft-ietf-ace-mqtt-tls-profile
Revision:   02
Title:  MQTT-TLS profile of ACE
Document date:  2019-11-02
Group:  ace
Pages:  24
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-tls-profile-02.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
Htmlized:
https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-02

Abstract:
   This document specifies a profile for the ACE (Authentication and
   Authorization for Constrained Environments) framework to enable
   authorization in an MQTT-based publish-subscribe messaging system.
   Proof-of-possession keys, bound to OAuth2.0 access tokens, are used
   to authenticate and authorize MQTT Clients.  The protocol relies on
   TLS for confidentiality and server authentication.




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] Review for draft-ietf-ace-mqtt-tls-profile-01

[Cigdem Sengul]

Just saw it in the core document as well. Thanks, Jim.

--Cigdem

On Wed, Oct 30, 2019 at 4:21 PM Jim Schaad  wrote:

> Just one quick comment below
>
>
>
> *From:* Cigdem Sengul 
> *Sent:* Wednesday, October 30, 2019 9:13 AM
> *To:* Daniel Migault 
> *Cc:* Jim Schaad ; ace@ietf.org;
> draft-ietf-ace-mqtt-tls-prof...@ietf.org
> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>
>
>
> Thank you for your comments Daniel (prefixed [CS])
>
> My comments are inside. I've also created the -v-02-WIP branch for the
> work in progress based on your and Jim's comments.
>
>
>
> On Thu, Oct 24, 2019 at 2:50 AM Daniel Migault  40ericsson@dmarc.ietf.org> wrote:
>
> HI,
>
>
>
> Thanks for sending an update. Please find my comments of the draft.
>
>
>
>This document makes the same assumptions as the Section 4 of the ACE
>framework [I-D.ietf-ace-oauth-authz] regarding Client and RS
>registration with the AS and establishing of keying material.
>
>  The document seems mostly focuses on the latest version of MQTT,
> I am wondering if we could encourage similarly the use of the latest
> version of TLS that is 1.3 at the time of writing.
>
> It seems AS as not been defined previously, so maybe it should be
> expanded there.
> 
>
>
>
> [CS] Can add a similar recommendation for TLS 1.3.
>
> AS is expanded.
>
>
>
>
>
>
>
>MQTTS
>Secured transport profile of MQTT.  MQTTS runs over TLS.
>The Server in MQTT acts as an intermediary between
>Clients that publishes Application Messages, and the Clients
>that made Subscriptions.  The Broker acts as the Resource
>Server for the Clients.
>
> publishes
>
> [CS] Fixed.
>
>
>
>
>
>
>
>Subscription
>A subscription comprises a Topic Filter and a maximum Quality
>of Service (QoS).
>
> Maybe that would be clearer to specify QoS level as well.
>
>
>
> [CS] Added.
>
>
>
>
>
>PINGREQ
>A ping request sent from a Client to the Broker.  It signals
>to the Broker that the Client is alive, and is used to
>confirm that the Broker is still alive.
>
> It may look a bit strange to have PINGREQ without PINGRESP. You
> might also indicate the keep alive period is provided in the CONNECT
>
>
>
> [CS] Added PINGRESP, clarified the Keep Alive period is set in the CONNECT
> in the definition of PINGREQ.
>
>
>
>
>Will
>An application message published by the Server after the
>network connection is closed in cases where the network
>connection is not closed normally.  If the Will Flag is set,
>then the payload of the CONNECT message has information about
>the Will.  The Will consists of the Will Properties, Will
>Topic, and Will Payload fields in the CONNECT message.
>
> 
> The first sentence seems to be related to the Will message while the
> intent, I suppose of teh definition was to define the generic conpet of
> Will. It might be clearer to expose the principle of the wil, that is a
> server sends a given message in case a client is disconnected
> improperly.   It might be clearer to mention explicitly there is a Will
> "concept" that is implemented a WillFlag WillQoS, WillRetain in the
> CONNECT header as well as other Will Properties and Will Messages. This
> mostly consists in the last sentence being moved up.
> 
>
>
>
> [CS] I reworded it - let me know if it is more clear.
>
>
>
> 2.  Protocol Interactions
>
>This section describes the following exchanges between Clients, the
>Broker, and the Authorization Server according to the MQTT v5.0.
>
>  Though english is not my first language, I have the impression the
> text can be interpreted as MQTT enables clients to establish session
> which does not seems correct to me. The text that follows clarifies this
> as well.
> 
>
>
>
> [CS] Neither mine, I reworded that as: "Authorizing connection requests
> from the Clients to the Broker"
>
> Actually, I also went through the text to reword "establishment" to set-up
> which is simpler.
>
>
>
>
>
> 2.1.  Authorizing Connection Establishment
>
>
>
> If the
>Client is resource-constrained, a Client Authorisation Server may
>
> I have the impression an AS would be sufficient.
>
>
>
> [CS] Client Authorization Server was the terminology used in the Actors
> draft - I've removed all other references but wanted to distinguish that
> this is separate than the AS

Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Cigdem Sengul]

essages, which are sent after a connection set-up, do not contain
>access tokens.  If the introspection result is not cached, then the
>RS needs to introspect the saved token for each request.  The Broker
>SHOULD use a cache time out to introspect tokens regularly.
>
> The latest sentence seems to indicate that result provided as
> via introspection do not necessarily have a Time to Live which could be
> interpreted as a commitment from the AS to authorize during that
> period. If that is possible, it would be appropriated this time out is
> provided by the AS.
> I am also wondering why the token expiration cannot be considered as
> well.
> 
>


[CS] This is to handle the situation where the resource owner changes the
permissions of the Client, which would revoke the token.
And hence the token exp field would not help.
 If the RS does not check the token introspection results, it
will use the token until its expiration time.
I've considered this more appropriate to be set by the RS as its RS risk
management.


>
> Appendix B.  The Authorization Information Endpoint
>
>The main document described a method for transporting tokens inside
>MQTT CONNECT messages.  In this section, we describe an alternative
>method to transport an access token.
>The method consists of the MQTT Broker accepting PUBLISH messages to
>a public "authz-info" topic.  A Client using this method MUST first
>connect to the Broker, and publish the access token using the "authz-
>info" topic.  The Broker must verify the validity of the token (i.e.,
>through local validation or introspection).  After publishing the
>token, the Client disconnects from the Broker and is expected to try
>reconnecting over TLS.
>
> I understand this as an open channel for CONNECT and sending
> PUBLISHING message. This potentially open the door for DoSing the RS
> either by openning too many MQTT sessions or by sending too many tokens.
> I expect this to be mentioned in the security consideration section as
> well as potential mechanisms to limit these risks.
> 
>

[CS] It is indeed mentioned in this paragraph in the security consideration
section.
"The RS may monitor Client behaviour to detect potential security problems,
especially those affecting availability.
 These include repeated token transfer attempts to the public "authz-info"
topic, repeated connection attempts,
 abnormal terminations, and Clients that connect but do not send any data.
 If the RS supports the public "authz-info" topic, described in Appendix B,
 then this may be vulnerable to a DDoS attack, where many Clients use the
"authz-info" public topic
   to transport fictitious tokens, which RS may need to store
indefinitely."


Thank you for your comments. And will try to address Jim's shortly to be
able to push another version before the deadline.

Kind regards,
--Cigdem


>
>
> On Thu, Oct 17, 2019 at 2:47 PM Jim Schaad  wrote:
>
>>
>>
>>
>>
>> *From:* Cigdem Sengul 
>> *Sent:* Thursday, October 17, 2019 4:13 AM
>> *To:* Jim Schaad 
>> *Cc:* draft-ietf-ace-mqtt-tls-prof...@ietf.org; ace@ietf.org
>> *Subject:* Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01
>>
>>
>>
>> Hello Jim,
>>
>> Thanks for this review. I have responded inline.
>>
>>
>>
>> 1.  Are there any specifics about using ACE over HTTP that need to be
>> explicitly stated some place.  Some of these things might include:
>> a) Must be HTTPS even if encrypted requests/responses are
>> provided.
>> b) What types of validation are permitted/required: anon-anon,
>> server validation, server & client validation. The latter corresponds to
>> current DTLS statements.
>> c) Are we looking for using the normal HTTP/HTTPS ports or should
>> we
>> be using different ports?
>>
>>
>>
>> >> Agreed. Need to specify that it is HTTPS.
>>
>> Mutual authentication and server validation Required.
>>
>> Was thinking it would be normal HTTPS ports. Should we consider different?
>>
>> What scenarios should permit anon-anon; anon clients?
>>
>>
>>
>> [JLS] If you look at my last email I went through this.  Anon-anon is
>> going to be a bad idea because the server is never validated, however
>> client anon is fine since you are going to validate the client in the MQTT
>> protocol.
>>
>>
>>
>>
>>
>>
>> 4.  Section 2.1.2: It is not clear from the document is a Broker is going
>> to
>> also have the possibility of doing a post of the token via HTTPS.
>> Cur

Re: [Ace] Review for draft-ietf-ace-mqtt-tls-profile-01

[Cigdem Sengul]

Hello Jim,
Thanks for this review. I have responded inline.

>
>
> 1.  Are there any specifics about using ACE over HTTP that need to be
> explicitly stated some place.  Some of these things might include:
> a) Must be HTTPS even if encrypted requests/responses are
> provided.
> b) What types of validation are permitted/required: anon-anon,
> server validation, server & client validation. The latter corresponds to
> current DTLS statements.
> c) Are we looking for using the normal HTTP/HTTPS ports or should
> we
> be using different ports?
>
>
>> Agreed. Need to specify that it is HTTPS.
Mutual authentication and server validation Required.
Was thinking it would be normal HTTPS ports. Should we consider different?
What scenarios should permit anon-anon; anon clients?



> 2.  Section 2.1.2: Somehow I missed on the first reading that you were
> suggesting the use of a topic /authz-info inside of the MQTT server for
> posting.   I think that this needs to have a more detailed set of
> instructions.  I assume but don't know that initially this would mean an
> anonymous connect, publish, disconnect, validated connect.  This however is
> not clear from the text.  It is also not clear that this should be over a
> TLS wrapped session for the publish.
>

>> OK. this was described in the Appendix. I will bring this forward in the
document, as an optional flow.

3.  Section 2.1.2: The correct reference is I-D.ietf-ace-dtls-authorize and
> not I-D.gerdes-ace-dtls-authorize.
>

>>  Will fix.


>
> 4.  Section 2.1.2: It is not clear from the document is a Broker is going
> to
> also have the possibility of doing a post of the token via HTTPS.
> Currently
> I would think not, but given that this is documented in OAuth 2.0 as an
> option I am not clear.
>
> >> Do you mean for introspection? Yes, this is a MAY as in the core
document, and so in this one too.
And if there is an RS-AS interaction, we expect that to be on HTTPS.
I will try to see where I should clarify in the text.

5.  It might make sense to break up section 2.1.2 more and cover the
> different methods either in continuous paragraphs or in subsections.
>

>> Sure. That would increase readability. It became rather long with the
new additions.

>
> 6.  As noted before, you need to have a section on TLS requirements.  This
> should cover what levels/types of authentication are permitted.  Some type
> of statement on TLS 1.3 vs prior versions.  Part of what needs to be placed
> here is the fact that while there is client authentication in MQTT, there
> is
> no method of doing server authentication other than the surrounding TLS
> protocol.  Also should cover how the certificate(?) or RPK would be
> validated.  Use the existing rs_cnf?
>

>> OK. Will add that.


>
> 7.   In Figure 2, I think the use of Client Identifier is somewhat
> confusing.  I think this is supposed to be the token as the Client
> Identifier is a different thing in MQTT.  Either that or you need to do a
> better job of describing the property block.
>

OK. I think I should explain MQTT packets better.
A connect packet has three parts: 1) Fixed header 2) Variable Header and 3)
Payload.
The variable header may have several properties, and Authentication Method
and Authentication Data are two of these properties.
According to MQTT Specification:
The ClientID MUST be present and is the first field in the CONNECT packet
Payload.
The ClientID MUST be a UTF-8 Encoded String
A Server MAY allow a Client to supply a ClientID that has a length of zero
bytes, however, if it does so the Server MUST treat this as a special case.

And this is what is done in the case of a collision:
If the ClientID represents a Client already connected to the Server, the
Server sends a DISCONNECT packet to the existing Client with Reason Code of
0x8E (Session taken over)

Is this more clear? If yes, I will try to clarify in text.


> 8.  If the value of Clean Start or Expiry Interval are not set correct is
> the server to fail the connect?
>

>> Agreed. This should be specified.
Two options: 1) Do not accept connection or 2) accept the connection but
then never create sessions, and then server  MUST set Session Present to 0
in the CONNACK packet, indicating
no session is present.

This basically makes Clean Start flag meaningless.
If this is better than client MUST be setting those parameters correctly,
then we can go this way.
Any thoughts?


> 9.  Should do a pass through the document and make sure that terms like
> "AUTH (Authentication Exchange) method" are not used.  I think you meant to
> use 'packet' rather than method in this location.  You need to be clear on
> the difference between methods and packets in the document.
>

>>I think I should clarify this piece as well as it is MQTT terminology. I
will add these to the terminology in the beginning.

AUTH (Authentication Exchange): AUTH packet sent from Client to Server or
Server to Client as part of an extended authentication exchange.

Re: [Ace] test planning?

[Cigdem Sengul]

Hello,

Thank you, Jim, for this plan.
Responses are inline.

On Mon, Oct 14, 2019 at 2:47 AM Jim Schaad  wrote:

> I was going through the document and trying to figure out what a test plan
> might look like.  I was also trying to make sure I understood all of the
> information flows.
>
> 1.  Post the token to the server before starting:
> a.  Yes
> b. No
>

Both options are supported but 1b is explained in the main document.
1a is explained as supporting an unprotected subscribe-only "authz-info"
topic in Appendix B.
We considered this as a MAY in section 2.1.2:  "To this end, the Broker MAY
support /authz-info
   endpoint via the "authz-info" topic.  Then, to transport the token,
Clients publish to "authz-info" topic unauthorized. "

Should this Appendix B come to the main document as some flows in section 2
require it? Should we explicitly say 1b is RECOMMENDED? Any opinions?


> 2.  Establish the connection to the server:
> a. Use the token as the PSK ID
> b. Use the token ID (or key ID) as the PSK ID (Requires 1.a)
> c. Use RPK for server & client authentication (Requires 1.a)
> d. Use RPK for the server but anonymous client (Could be X.509 cert
> for the server)
> e. Anonymous for both client and server authentication (Does not
> seem to be usable as none of the methods in 3 provide for server
> authentication.)
>

All except 2.e - we did not plan to support it.


> 3. Send MQTT Connect message
> a.  Use underlying TLS session for authentication - No additional
> POP is required on the CONNECT event.  Permissions are inferred from the
> token used for client authentication to TLS (2.a, 2.b, 2.c).  (Works with
> all versions of MQTT.)
> b.  Use POP as a password over client ID + nonce.  (Not clear where
> the nonce is carried for MQTT 3.1.1) This replaces the TLS client
> authentication (2.d).   Requires use of JWT as binary not allowed.
> c. Use the POP via challenge/response.  Replaces the TLS client
> authentication (2.d).  (Requires MQTT 5.x)
>

True for 3.b -> We need to clarify that the nonce needs to be part of the
data that is passed. Since we overload password/username for this, we may
need
to provide this in a structure in the username. Will define.



> 4. Update token within an open session.  If the server closes the session
> or
> sends a DISCONNECT then this is moot.
> a. Post token to the server.  (Only thing that would work for MQTT
> 3.1.1)
> b.  Respond with an AUTH packet and re-run the POP via
> challenge/response.
>
>
4a. True - here post token to the server means start everything over with
CONNECT or "authz-info". If the client knows this is not due to token
expiration somewhat (hard to know in MQTT 3.1, then it may skip
authz-info).



> 5.  Update token after a session is closed.  Start with step 1 above and
> create a new session.
>
>
> Based on this, there are a couple of things that need to be clarified in
> the
> document:
>
> 1.  What requirements are there for validating the TLS client/server
> identities.
>

Do you mean apart from TLS certificate verification, whether the TLS client
checks server identity against a preconfigured reference identity?



> 2.  Is the option in 3.a planned to be a legal option or not?  If so then
> it
> needs to be documented as such.
>

We added them as options with MAY statements.
How should we change the document to signal this more strongly?



> 3.  Does it make any sense to allow for the publication of a new token to
> the server via a publish to a fixed name.  One would not allow for it to be
> subscribed to.   This would allow for an authenticated post rather than the
> unauthenticated post and would also allow an update method for option 3.a.
> If not, doe the option of 4.a make sense and should it be documented as
> such.
>
>
This is described in Appendix B - as a means of implementing "authz-info".
I think this suggests we should move authz-info to the main document.


> I will still do a full review of the document.
>
> Jim
>
>
Thanks for this. I hope I was able to clarify some of the issues.

Sincerely,
--Cigdem


>
> ___
> 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] Fwd:New Version Notification for draft-ietf-ace-mqtt-tls-profile-01.txt

[Cigdem Sengul]

Hello,

We have uploaded a new version of the MQTT-TLS profile.
Thank you very much for the feedback and responses  - Jim, Daniel, Ludwig,
Carsten and Hannes.

We have done the following changes. However, even though we tried to keep a
clear language around the HTTPS/CoAP, JSON/CBOR, JWT/CWT, we are aware that
more work needs to be done; and these are also tied to OAuth WG.

Version 00 to 01:


   o  Presented the MQTTv5 as the RECOMMENDED version, and MQTT v3.1.1
for backward
compatibility.


   o  Clarified Will message.


   o  Improved consistency in the use of terminology, and upper/lower

  case.


   o  Defined Broker and MQTTS.


   o  Clarified HTTPS use for C-AS and RS-AS communication.  Removed

  reference to actors document, and clarified the use of client

  authorization server.


   o  Clarified the Connect message payload and Client Identifier.


   o  Presented different methods for passing the token, and PoP.


   o  Added new figures for AUTH methods, updated CONNECT message

  figure.



Thank you very much for your help.
--Cigdem

On 05/10/2019, 22:29, "internet-dra...@ietf.org" 
wrote:


A new version of I-D, draft-ietf-ace-mqtt-tls-profile-01.txt
has been successfully submitted by Cigdem Sengul and posted to the
IETF repository.

Name:   draft-ietf-ace-mqtt-tls-profile
Revision:   01
Title:  MQTT-TLS profile of ACE
Document date:  2019-10-05
Group:  ace
Pages:  23
URL:
https://www.ietf.org/internet-drafts/draft-ietf-ace-mqtt-tls-profile-01.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
Htmlized:
https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-01

Abstract:
   This document specifies a profile for the ACE (Authentication and
   Authorization for Constrained Environments) to enable authorization
   in an MQTT-based publish-subscribe messaging system.  Proof-of-
   possession keys, bound to OAuth2.0 access tokens, are used to
   authenticate and authorize MQTT Clients.  The protocol relies on TLS
   for confidentiality and server authentication.




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] Transporting different types of cnf objects - CBOR vs JSON

[Cigdem Sengul]

Hello,

Thank you for your responses.

Until this issue is resolved, is it OK just to point to RFC 7800, which
says the client provides the symmetric PoP key?

For MQTT draft,  would like to explain that C-RS is MQTT - MQTT may carry
JSON/CBOR encoding for the Data fields in the packets.

C-AS and RS-AS can be HTTPS/CoAP/MQTT - what we describe in the draft it is
HTTPS; MQTT support needs more thought for request-response style
communication.
For HTTPS/CoAP, application/ace+json or application/ace+cbor content
formats.

Since this info is a bit muddled in the current draft, I would like to
ensure there is a clear paragraph, which the workgroup would be fine with.

Thank you for your help.
Sincerely,
--Cigdem





On Thu, Oct 3, 2019 at 7:42 AM Hannes Tschofenig 
wrote:

> There is unfortunately a problem.
>
> With proof-of-possession keys there is more than just conveying the
> CWT/JWT over another transport.
> In the PK-case, the client has to provide the public key to the server and
> get it bound to the PoP token.
> In the symmetric key case, the server has to provide the token along with
> the symmetric key that is also included although encrypted) in the PoP
> token.
>
> We have standardized the transport of this additional information in ACE
> for use with CoAP but for HTTP we decided to do the work on OAuth, where it
> got stuck because the IoT-interested people are not there and the Web folks
> want something else.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Ace  On Behalf Of Carsten Bormann
> Sent: Mittwoch, 2. Oktober 2019 15:05
> To: Cigdem Sengul 
> Cc: Jim Schaad ; Ludwig Seitz ;
> ace@ietf.org
> Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs
> JSON
>
> There is no strong interdependency between Web transfer protocol
> (HTTPS/CoAPS) and data format.
> COSE works great over HTTPS, and if it must be, you can ship JOSE over
> CoAPS.
>
> Grüße, Carsten
>
>
> > On Oct 2, 2019, at 14:00, Cigdem Sengul  wrote:
> >
> > Hello all,
> >
> > I am trying to implement this discussion in the draft.  A point is
> raised about COSE keys in JSON messages.
> > Could it be possible to go with:
> > (1) HTTPS - application/ace+json - jwt - jose - PoP for JWT or
> > (2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT without
> > mixing anything?
> >
> > (1) we thought to describe by default in the document, and (2) we said
> MAY be supported.
> > Is there a problem with this approach?
> >
> > Thanks,
> > --Cigdem
> >
> >
> > On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul 
> wrote:
> > Hello,
> > Yes, we thought supporting JSON option would be good, though indeed
> there is no issue with transporting CBOR..
> > If there are no other concerns, we can define the new media type in the
> MQTT draft.
> > Will add the issue to GitHub repo.
> >
> > --Cigdem
> >
> > On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad 
> wrote:
> >
> >
> > > -Original Message-
> > > From: Ace  On Behalf Of Ludwig Seitz
> > > Sent: Monday, June 3, 2019 11:51 PM
> > > To: ace@ietf.org
> > > Subject: Re: [Ace] Transporting different types of cnf objects -
> > > CBOR vs JSON
> > >
> > > On 01/06/2019 02:51, Jim Schaad wrote:
> > > > Ludwig,
> > > >
> > > > I have been doing some adaptions of my codebase for dealing with
> > > > the MQTT specification.  In the process of this, I have identified
> > > > the following items that I think needs some discussion.  They may
> > > > not need changes in any documents and maybe should get a new
> document.
> > > >
> > > > 1.  The MQTT document is using the content type "application/json"
> > > > over HTTPS for transporting messages.  Does there need to be an
> > > > "application/ace+json" defined as a media type, but not
> > > > necessarily a CBOR media type?  I think the answer may be yes, but
> > > > it could be a new
> > > document.
> > > >
> > > I would argue that the first draft using such a media type would be
> > > the right place to specify it. However I'm not sure using JSON is
> > > the right approach for an ACE specification at all, aren't we
> > > supposed to cater for the constrained world?
> > > What is there to prevent us from transporting CBOR over HTTP?
> >
> > There would be no reason that one cannot transport CBOR over HTTP.
> During the discussions for these drafts Hannes was very explicit that he
> wanted to be able to use JSON rat

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

[Cigdem Sengul]

Hello all,

I am trying to implement this discussion in the draft.  A point is raised
about COSE keys in JSON messages.
Could it be possible to go with:
(1) HTTPS - application/ace+json - jwt - jose - PoP for JWT
or
(2) CoAP - application/ace+cbor - cwt - cose - PoP for CWT
without mixing anything?

(1) we thought to describe by default in the document, and (2) we said MAY
be supported.
Is there a problem with this approach?

Thanks,
--Cigdem


On Tue, Jun 4, 2019 at 9:29 PM Cigdem Sengul 
wrote:

> Hello,
> Yes, we thought supporting JSON option would be good, though indeed there
> is no issue with transporting CBOR.
> If there are no other concerns, we can define the new media type in the
> MQTT draft.
> Will add the issue to GitHub repo.
>
> --Cigdem
>
> On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad  wrote:
>
>>
>>
>> > -Original Message-
>> > From: Ace  On Behalf Of Ludwig Seitz
>> > Sent: Monday, June 3, 2019 11:51 PM
>> > To: ace@ietf.org
>> > Subject: Re: [Ace] Transporting different types of cnf objects - CBOR
>> vs JSON
>> >
>> > On 01/06/2019 02:51, Jim Schaad wrote:
>> > > Ludwig,
>> > >
>> > > I have been doing some adaptions of my codebase for dealing with the
>> > > MQTT specification.  In the process of this, I have identified the
>> > > following items that I think needs some discussion.  They may not need
>> > > changes in any documents and maybe should get a new document.
>> > >
>> > > 1.  The MQTT document is using the content type "application/json"
>> > > over HTTPS for transporting messages.  Does there need to be an
>> > > "application/ace+json" defined as a media type, but not necessarily a
>> > > CBOR media type?  I think the answer may be yes, but it could be a new
>> > document.
>> > >
>> > I would argue that the first draft using such a media type would be the
>> right
>> > place to specify it. However I'm not sure using JSON is the right
>> approach for
>> > an ACE specification at all, aren't we supposed to cater for the
>> constrained
>> > world?
>> > What is there to prevent us from transporting CBOR over HTTP?
>>
>> There would be no reason that one cannot transport CBOR over HTTP.
>> During the discussions for these drafts Hannes was very explicit that he
>> wanted to be able to use JSON rather than CBOR with the protocol that was
>> defined by ACE.  This would mean that there needs to be an ability to use
>> JSON with the ACE framework document.
>>
>> I would have no problems with the statement that the MQTT document would
>> be a good place to define the new media type.
>>
>> >
>> > > 2.  If I use a "COSE_Key" confirmation method inside of an
>> > > application/ace+json message, there is a potential problem and it
>> > > could be dealt with in a number of different ways.
>> > > *  The JWT confirmation method is identified as "jwk".  The COSE key
>> > > must be translated into JOSE even if there is no equivalent key in
>> > > JOSE.  I.e. that is a fatal error
>> > > *  This does not make sense and the confirmation method should be
>> > > changed to "cwk" so that either key format could be used in either
>> > encoding.
>> > >
>> >
>> > If we use JSON messages mixing in COSE becomes awkward. If the use case
>> > calls for JSON, I'd argue it should also use RFC7800 instead of
>> draft-ietf-ace-
>> > cwt-proof-of-possession.
>>
>> I would not have a problem with this, it was one of the options above.  I
>> was just expanding my code to allow for JSON to be used and ran into this.
>> I just wanted to get a clear group decision on this before I put things
>> into stone.
>>
>> Jim
>>
>> >
>> > > 3.  If the confirmation is changed, you would need to convert the COSE
>> > > key to a binary string, base64 encoded it and pass as a string when
>> > > occurring in a JSON encoding.  There is not any other valid way to do
>> > > this (except see above of just converting the key format).  However,
>> > > the opposite of putting a JOSE key into a COSE confirmation has three
>> > > different options that could be used.
>> > > *  Encode the JOSE key to a string and pass as a string
>> > > *  Encode the JOSE key top level map as CBOR but leave all of the
>> > > elements alone.
>> > > *  Encode the JOSE key in CBOR 

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

[Cigdem Sengul]

xplains how the broker deals with the
>retained messages in further detail.
>
> 
> Figure mentions Will Flag while the text mentions Will flag.
>
> From the paragraph, I cannot figure out what a Will message is. Maybe
> that could be explained or a reference to it may be indicated.
>
> 
>

Cigdem :

Sure, will pay attention to be consistent with the capitalisations.

The Will message is indeed the client’s will when it dies. That’s why it is
sent in the case of a disconnection. Will improve its explanation.

I can this also to MQTT terminology section:

*Will Message:*

An Application Message which is published by the Server after the Network
Connection is closed in cases where the Network Connection is not closed
normally.

If Will Flag is set, then the payload of the Connect message has
information about the Will message.

The Will Message consists of the Will Properties, Will Topic, and Will
Payload fields in the CONNECT Payload.

Github issue:https://github.com/ace-wg/mqtt-tls-profile/issues/13

https://github.com/ace-wg/mqtt-tls-profile/issues/11



>
>The broker responses may follow either the MQTT v3.1.1 - the OASIS
>Standard [MQTT-OASIS-Standard] or the MQTT v5 - the OASIS Standard
>[MQTT-OASIS-Standard-v5], depending on which version(s) the broker
>supports.
> 
> I believe that references to MQTTv3.1.1 and MQTTv5 provided in the
> introduction are sufficient, and there is no need to have teh reference
> anytime MQTT is invoked.
> 
>

Cigdem:


Will remove, and it will improve the readability of the document.
https://github.com/ace-wg/mqtt-tls-profile/issues/14



> 3.  Improved Protocol Interactions with MQTT v5
>
>In the new MQTT v5 - the OASIS Standard [MQTT-OASIS-Standard-v5],
>several new capabilities are introduced, which enable better
>integration with ACE.  The newly enhanced authentication and re-
>authentication methods support a wider range of authentication flows
>beyond username and password.  With the MQTT v5, there is a clearly
>defined approach for using token-based authorization.  Also, it is
>possible for a client to request a re-authentication avoiding
>disconnection.  Finally, MQTT v5 generally improves error reporting,
>enabling better response to authorization failures during publishing
>messages to the subscribers.
>
> 
> Given that MQTT provides a better integration with ACE, I am wondering
> if MQTTv5 should not be considered as the primary description and having
> MQTT3.1.1 related to legacy MQTT. This is seems to me simply re-ordering
> the
> sections. However, the message carried would be to move to MQTTv5 when
> possible.
>
> I also believe that a recommendation on supporting MQTTv5 should me made
> in the document.
>
> 
>

Cigdem:

This is a good idea. We kept the order because of historical reasons. Will
work on that as a first requirement before fixing other GitHub issues.
https://github.com/ace-wg/mqtt-tls-profile/issues/12

>
>   hentication capabilities, it is not necessary to
>overload the username and password fields in the CONNECT message for
>ACE authentication.  Nevertheless, the RS MUST support both methods
>for supporting the token: (1) Token transport via username and
>password and (2) using the new AUTH (Authentication Exchange) method.
>The token transport via username and password is as described in
>Section 2.1.2.  The rest of this section describes the AUTH method.
>
> 
> As mentioned before, it might be better to mention what to do and
> explain in MQTT why we overload the username/password.
> 
>


Cigdem: If the order of descriptions is changed, then we can clarify this
better.

Github issue: https://github.com/ace-wg/mqtt-tls-profile/issues/12


 On Fri, May 24, 2019 at 4:57 AM Cigdem Sengul 
wrote:

> Hello,
>>
>> Thanks, Jim, this was helpful, and it also triggered that I go back and
>> read the introspection section of the core draft again.
>>
>>
>>>
>>>
>>> [JLS] For introspection, but not for a published token, the token could
>>> be “revoked” by the RS.  In this case a new introspection check would lead
>>> to that information.  There may be ways to deal with this in the
>>> introspection dialog and not need to be called up here.  The question would
>>> be does the exi field mean – recheck the token or discard the token.
>>>
>>
>> Understood. We definitely need to clarify here what we do with exi field
>> if it exists, and if it doesn't exist. The MAY language we used in the
>> draft is not appropriate if exi does not exist.
>> We considered the expiration time in the introspection response as a
>> revocation signal and hence RS discards the t

Re: [Ace] Transporting different types of cnf objects - CBOR vs JSON

[Cigdem Sengul]

Hello,
Yes, we thought supporting JSON option would be good, though indeed there
is no issue with transporting CBOR.
If there are no other concerns, we can define the new media type in the
MQTT draft.
Will add the issue to GitHub repo.

--Cigdem

On Tue, Jun 4, 2019 at 7:37 PM Jim Schaad  wrote:

>
>
> > -Original Message-
> > From: Ace  On Behalf Of Ludwig Seitz
> > Sent: Monday, June 3, 2019 11:51 PM
> > To: ace@ietf.org
> > Subject: Re: [Ace] Transporting different types of cnf objects - CBOR vs
> JSON
> >
> > On 01/06/2019 02:51, Jim Schaad wrote:
> > > Ludwig,
> > >
> > > I have been doing some adaptions of my codebase for dealing with the
> > > MQTT specification.  In the process of this, I have identified the
> > > following items that I think needs some discussion.  They may not need
> > > changes in any documents and maybe should get a new document.
> > >
> > > 1.  The MQTT document is using the content type "application/json"
> > > over HTTPS for transporting messages.  Does there need to be an
> > > "application/ace+json" defined as a media type, but not necessarily a
> > > CBOR media type?  I think the answer may be yes, but it could be a new
> > document.
> > >
> > I would argue that the first draft using such a media type would be the
> right
> > place to specify it. However I'm not sure using JSON is the right
> approach for
> > an ACE specification at all, aren't we supposed to cater for the
> constrained
> > world?
> > What is there to prevent us from transporting CBOR over HTTP?
>
> There would be no reason that one cannot transport CBOR over HTTP.  During
> the discussions for these drafts Hannes was very explicit that he wanted to
> be able to use JSON rather than CBOR with the protocol that was defined by
> ACE.  This would mean that there needs to be an ability to use JSON with
> the ACE framework document.
>
> I would have no problems with the statement that the MQTT document would
> be a good place to define the new media type.
>
> >
> > > 2.  If I use a "COSE_Key" confirmation method inside of an
> > > application/ace+json message, there is a potential problem and it
> > > could be dealt with in a number of different ways.
> > > *  The JWT confirmation method is identified as "jwk".  The COSE key
> > > must be translated into JOSE even if there is no equivalent key in
> > > JOSE.  I.e. that is a fatal error
> > > *  This does not make sense and the confirmation method should be
> > > changed to "cwk" so that either key format could be used in either
> > encoding.
> > >
> >
> > If we use JSON messages mixing in COSE becomes awkward. If the use case
> > calls for JSON, I'd argue it should also use RFC7800 instead of
> draft-ietf-ace-
> > cwt-proof-of-possession.
>
> I would not have a problem with this, it was one of the options above.  I
> was just expanding my code to allow for JSON to be used and ran into this.
> I just wanted to get a clear group decision on this before I put things
> into stone.
>
> Jim
>
> >
> > > 3.  If the confirmation is changed, you would need to convert the COSE
> > > key to a binary string, base64 encoded it and pass as a string when
> > > occurring in a JSON encoding.  There is not any other valid way to do
> > > this (except see above of just converting the key format).  However,
> > > the opposite of putting a JOSE key into a COSE confirmation has three
> > > different options that could be used.
> > > *  Encode the JOSE key to a string and pass as a string
> > > *  Encode the JOSE key top level map as CBOR but leave all of the
> > > elements alone.
> > > *  Encode the JOSE key in CBOR including conversion of base64 strings
> > > to binary data.
> > > (My first preference is probably the second option, but either of the
> > > first two make sense.)
> > >
> > > Jim
> > >
> >
> > I'm still unsure that there is a good use case for transporting JOSE
> keys in
> > CBOR, but if such a case turns up, I would agree that touching the
> encoding
> > as little as possible is a good idea (=option 1 or 2).
> >
> > /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] Comments on draft-ietf-ace-mqtt-tls-profile

[Cigdem Sengul]

Hello,

Thanks, Jim, this was helpful, and it also triggered that I go back and
read the introspection section of the core draft again.


>
>
> [JLS] For introspection, but not for a published token, the token could be
> “revoked” by the RS.  In this case a new introspection check would lead to
> that information.  There may be ways to deal with this in the introspection
> dialog and not need to be called up here.  The question would be does the
> exi field mean – recheck the token or discard the token.
>

Understood. We definitely need to clarify here what we do with exi field if
it exists, and if it doesn't exist. The MAY language we used in the draft
is not appropriate if exi does not exist.
We considered the expiration time in the introspection response as a
revocation signal and hence RS discards the token.  (The basic flow was: RS
receives a token, introspects it, caches the result and then when it
expires, it revokes the token - which may next lead to different steps
depending on the version of the MQTT.)
But if introspection is done to handle the case of dynamic authorisation
decisions, and exi would signal a recheck indeed.
Will clarify.

Thanks,
--Cigdem



>
>
> Jim
>
>
>
>
>
> 7. That is correct. Will add the clarification.
>
>
>
> Thanks,
>
> --Cigdem
>
>
>
>
>
>
>
>
>
> On Wed, May 22, 2019 at 10:58 PM Jim Schaad 
> wrote:
>
> Thanks for the updates from my last message.  This has helped quite a bit..
>
> 1.  A discussion of the use of raw public keys rather than certificates for
> the server may be in order.  This can refer to the same RPK issues from the
> current DTLS document.  It may also be that this just uses normal
> certificate processing and that should be noted as well, but some
> discussion
> of deciding if the subject name/alt name matches the token returned from
> the
> AS.
>
> For the connect message there are a couple of issues that need to be
> thought
> about.
>
> 2.  What items are required to be in the connect message.  The response to
> my last message suggested that a client identifier is required to be
> present
> but that is not documented.
>
> 3.  It is not completely clear what portions of the CONNECT message are
> being covered by the signature/MAC value.  As an example, is the password
> field omitted entirely or is it set to a zero length password.  In addition
> to this, from the couple of implementations that I have looked at the
> entire
> packet is not passed out of the base server code for authentication
> purposes.  This might need to be taken into account in terms of what is
> used
> for the body and how it is constructed.  (As a side note, the
> implementations that I have looked at so far also think that the password
> is
> a text string rather than a binary value which is going to be a short term
> issue as well.)
>
> 4.  I must admit that I am disappointed that there is no challenge response
> mechanism in the MQTT specifications.  I don't know that anything can be
> done at this point about it but there are some security issues that need to
> be highlighted because of this in the security considerations section.
> Only
> the v3 seems to have this problem.  Also doing the channel binding would
> deal with this problem as well.  Might just need some general discussions
> around the channel binding text.
>
> 5.  Is there an intention to provide a "standard" format for the scope
> field
> or just to leave it as ad hoc?
>
> 6.  It might be reasonable in section 2.1.3 to note that even if a result
> is
> cached, that cached check should be limited for a specific amount of time
> to
> recheck if the token is still active.  More of an issue in terms of how
> long
> to cache for introspection.
>
> 7.  In section 2.1.4 - I would presume that the last paragraph should be
> extended to say that the token is stored only for the length of the
> connection.  That is the token always needs to be supplied every time a
> connect message is sent.
>
> 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

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

[Cigdem Sengul]

Thank you, Jim, for the comments.
I have created issues corresponding to each one in the GitHub repository.

We will start working on them, and specifically clarify the issues 1-3
around the CONNECT message.

For 4, MQTT v5 can support a challenge-response; not possible with v3
indeed. Will expand the security considerations section on that.

5.  We described a convention in the draft with SHOULD. Do we turn that
into a MUST?

6. We thought that the AS would dictate the token expiration time. It can
also be done that RS times out tokens even if they have not expired. But,
security-performance trade-off should be considered.
Token caching is important even if the token does not need introspection.
The only time the MQTT client can push a token is with the CONNECT message
(all subsequent publish/subscribe messages rely on this). In MQTT v5, a
client can push a new token via reauthentication during an ongoing session
(enabled by MQTT v5). If RS times out the token, this means a disconnection
in MQTT v3. We mention this  in Security considerations as "it is expected
that AS follows a reasonable expiration strategy for access tokens"

-->There may be workarounds designed especially MQTT v5 which has better
support for request-response style communication. But need to think about
it.

7. That is correct. Will add the clarification.

Thanks,
--Cigdem




On Wed, May 22, 2019 at 10:58 PM Jim Schaad  wrote:

> Thanks for the updates from my last message.  This has helped quite a bit.
>
> 1.  A discussion of the use of raw public keys rather than certificates for
> the server may be in order.  This can refer to the same RPK issues from the
> current DTLS document.  It may also be that this just uses normal
> certificate processing and that should be noted as well, but some
> discussion
> of deciding if the subject name/alt name matches the token returned from
> the
> AS.
>
> For the connect message there are a couple of issues that need to be
> thought
> about.
>
> 2.  What items are required to be in the connect message.  The response to
> my last message suggested that a client identifier is required to be
> present
> but that is not documented.
>
> 3.  It is not completely clear what portions of the CONNECT message are
> being covered by the signature/MAC value.  As an example, is the password
> field omitted entirely or is it set to a zero length password.  In addition
> to this, from the couple of implementations that I have looked at the
> entire
> packet is not passed out of the base server code for authentication
> purposes.  This might need to be taken into account in terms of what is
> used
> for the body and how it is constructed.  (As a side note, the
> implementations that I have looked at so far also think that the password
> is
> a text string rather than a binary value which is going to be a short term
> issue as well.)
>
> 4.  I must admit that I am disappointed that there is no challenge response
> mechanism in the MQTT specifications.  I don't know that anything can be
> done at this point about it but there are some security issues that need to
> be highlighted because of this in the security considerations section.
> Only
> the v3 seems to have this problem.  Also doing the channel binding would
> deal with this problem as well.  Might just need some general discussions
> around the channel binding text.
>
> 5.  Is there an intention to provide a "standard" format for the scope
> field
> or just to leave it as ad hoc?
>
> 6.  It might be reasonable in section 2.1.3 to note that even if a result
> is
> cached, that cached check should be limited for a specific amount of time
> to
> recheck if the token is still active.  More of an issue in terms of how
> long
> to cache for introspection.
>
> 7.  In section 2.1.4 - I would presume that the last paragraph should be
> extended to say that the token is stored only for the length of the
> connection.  That is the token always needs to be supplied every time a
> connect message is sent.
>
> 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

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

[Cigdem Sengul]

Hello Ludwig,

This was MQTT-SN-over-DTLS was on our agenda when first we started out.
However, at that time there was not much take-up of MQTT-SN  in practice
(not sure that changed). If there is sufficient interest in the group,
would make sense to do that as well, and theoretically, it would be a more
natural fit to ACE.
Thanks,
--Cigdem

On Thu, May 23, 2019 at 7:29 AM Ludwig Seitz  wrote:

> On 21/05/2019 22:35, Cigdem Sengul wrote:
> > Thank you for your comments.  I see that we tried to cover too many
> > options in the draft, and things got mixed up.I tried to clarify inline.
> >
> > * So as a client I get a token from the AS.  For the first run,
> > assume that
> > it has a RPK in it.
> > * I now connect to the server using TLS.
> >  Question #1 - Am I doing client authentication at this
> > point in TLS?
> > This is what is happening for all of the current profiles, but it is
> not
> > clear that this is happening for this profile.  The answer appears
> to be
> > both yes and no.
> >
> > The basic method we were thinking:
> >
> >
> >  1. We have not assumed client-side certificates for authenticating
> > clients during TLS handshake. RS uses a server-side certificate.
>
>
>
> One quick question: If I understand it correctly there is a variant of
> MQTT using UDP (MQTT-SN). Since TLS and TCP are not exactly
> "constrained-friendly", would it make sense to look at that as well to
> define a "MQTT-SN-over-DTLS-based" profile?
>
> /Ludwig
>
>
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
>
> ___
> 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