Re: [Ace] [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport

[Brockhaus, Hendrik]

Mohit
Thanks for the update. I'm looking forward to the discussion in ACE.

Hendrik

Von: Mohit Sahni  
Gesendet: Dienstag, 14. Juli 2020 00:06

Hi All
I have published the first draft for the document here is the link to the draft 
https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/. As Jim 
mentioned that adopting this might need change in the ACE WG charter can we 
please discuss that in IETF 108 ?

Thanks
Mohit 

On Sat, Jun 6, 2020 at 10:01 AM Mohit Sahni  wrote:
Hi Jim,
Thanks for the feedback. I will go over the EST document and update sections 
around DTLS and proxying and address your other comments. Once ready, I will 
post the draft in ACE WG.

Regards,
Mohit 


On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad  wrote:
I suppose that this could go into the ACE working group, but it will require a 
charter change to do so.  
 
I would suggest that you review the EST document with special attention to the 
sections on DTLS and proxying.  It would also help to have some idea of 
guidance for when coap or coaps is going to be used.  I am not sure that this 
strongly exists in CMP as my very vague memory was that it was assumed that all 
transactions where going to be done over TLS with server validation as a 
minimum.
 
Jim
 
 
From: Spasm  On Behalf Of Mohit Sahni
Sent: Thursday, June 4, 2020 10:49 PM
To: Tomas Gustavsson 
Cc: LAMPS WG 
Subject: Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport
 
Hi Tomas
Thanks for the feedback, I was trying to write it in a way so that it can work 
for both CMPv2 and LightWeight CMP, I have noted it your feedback and I will 
try to make it more clear.
 
-Mohit 
 
On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson  
wrote:
Hi,

I noticed that section 4, Proxy Support (good section btw), mentions
Announcement messages. These are excluded from the Lightweight
specification. Since the LIghtweight specification is mentioned in the
beginning, I'm not sure if that's worth mentioning here?

Cheers,
Tomas

On 2020-06-04 20:03, Mohit Sahni wrote:
> Hi Jim,
> There were some discussions about using CoAP as transport for the
> Lightweight CMP profile in the last LAMPS WG meeting. After having some
> discussions with Hendrik, David, and Andreas I have written an
> internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP
> Profile. If I am not mistaken, the recommendation was to present this
> draft to ACE WG for the review instead of Lamps group, can you please
> advice on that?
> 
> Here is the link to the internet-draft that I wrote
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-msahni-tbd-cmpv2-coap-transport-00.txt=02%7C01%7Chendrik.brockhaus%40siemens.com%7C7553d8af26034360311208d82778f6a0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637302747769875510=%2BUhTMJjgH8J3gVVyVa8eYZe0cNO8AKZNK8Axi5RZAgc%3D=0
>  
> 
> Thanks
> Mohit  
> 
> ___
> Spasm mailing list
> mailto:sp...@ietf.org
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm=02%7C01%7Chendrik.brockhaus%40siemens.com%7C7553d8af26034360311208d82778f6a0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637302747769885467=SBDJa6P7%2Fd5OSQ4wnd8o%2FuO2PJg5esYnXtKmHlBcTao%3D=0
> 

___
Spasm mailing list
mailto:sp...@ietf.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm=02%7C01%7Chendrik.brockhaus%40siemens.com%7C7553d8af26034360311208d82778f6a0%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637302747769890437=h5iBuM%2BxucjGNAESzoAIQ26To55izeklFeuYGUkXYfc%3D=0
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport

[Mohit Sahni]

Hi All
I have published the first draft for the document here is the link to the
draft
https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/ .
As Jim mentioned that adopting this might need change in the ACE WG charter
can we please discuss that in IETF 108 ?

Thanks
Mohit

On Sat, Jun 6, 2020 at 10:01 AM Mohit Sahni  wrote:

> Hi Jim,
> Thanks for the feedback. I will go over the EST document and update
> sections around DTLS and proxying and address your other comments. Once
> ready, I will post the draft in ACE WG.
>
> Regards,
> Mohit
>
>
> On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad  wrote:
>
>> I suppose that this could go into the ACE working group, but it will
>> require a charter change to do so.
>>
>>
>>
>> I would suggest that you review the EST document with special attention
>> to the sections on DTLS and proxying.  It would also help to have some idea
>> of guidance for when coap or coaps is going to be used.  I am not sure that
>> this strongly exists in CMP as my very vague memory was that it was assumed
>> that all transactions where going to be done over TLS with server
>> validation as a minimum.
>>
>>
>>
>> Jim
>>
>>
>>
>>
>>
>> *From:* Spasm  *On Behalf Of *Mohit Sahni
>> *Sent:* Thursday, June 4, 2020 10:49 PM
>> *To:* Tomas Gustavsson 
>> *Cc:* LAMPS WG 
>> *Subject:* Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport
>>
>>
>>
>> Hi Tomas
>>
>> Thanks for the feedback, I was trying to write it in a way so that it can
>> work for both CMPv2 and LightWeight CMP, I have noted it your feedback and
>> I will try to make it more clear.
>>
>>
>>
>> -Mohit
>>
>>
>>
>> On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson > > wrote:
>>
>> Hi,
>>
>> I noticed that section 4, Proxy Support (good section btw), mentions
>> Announcement messages. These are excluded from the Lightweight
>> specification. Since the LIghtweight specification is mentioned in the
>> beginning, I'm not sure if that's worth mentioning here?
>>
>> Cheers,
>> Tomas
>>
>> On 2020-06-04 20:03, Mohit Sahni wrote:
>> > Hi Jim,
>> > There were some discussions about using CoAP as transport for the
>> > Lightweight CMP profile in the last LAMPS WG meeting. After having some
>> > discussions with Hendrik, David, and Andreas I have written an
>> > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP
>> > Profile. If I am not mistaken, the recommendation was to present this
>> > draft to ACE WG for the review instead of Lamps group, can you please
>> > advice on that?
>> >
>> > Here is the link to the internet-draft that I wrote
>> > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt
>> >
>> > Thanks
>> > Mohit
>> >
>> > ___
>> > Spasm mailing list
>> > sp...@ietf.org
>> > https://www.ietf.org/mailman/listinfo/spasm
>> >
>>
>> ___
>> Spasm mailing list
>> sp...@ietf.org
>> https://www.ietf.org/mailman/listinfo/spasm
>>
>>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

[Ace] Agenda for IETF 108

[Jim Schaad]

We are collecting agenda items for IETF 108.  We have a 100 minute slot at
the meeting and I am sure that it will be overflowing.  If you want to be on
the agenda please let the chairs know.

Please include the following data in your agenda request:

1. The document(s) that the presentation applies to
2. Who is giving the presentation
3.  How long do you expect the presentation to take.
4.  Are there any ordering issues that need to be noted.

Jim & Daniel


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

[Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-08.txt

[internet-drafts]

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

Title   : Key Management for OSCORE Groups in ACE
Authors : Marco Tiloca
  Jiye Park
  Francesca Palombini
Filename: draft-ietf-ace-key-groupcomm-oscore-08.txt
Pages   : 50
Date: 2020-07-13

Abstract:
   This specification defines an application profile of the ACE
   framework for Authentication and Authorization, to request and
   provision keying material in group communication scenarios that are
   based on CoAP and secured with Group Object Security for Constrained
   RESTful Environments (OSCORE).  This application profile delegates
   the authentication and authorization of Clients that join an OSCORE
   group through a Resource Server acting as Group Manager for that
   group.  This application profile leverages 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.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-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] I-D Action: draft-tiloca-ace-oscore-gm-admin-02.txt

[internet-drafts]

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   : Admin Interface for the OSCORE Group Manager
Authors : Marco Tiloca
  Rikard Hoeglund
  Peter van der Stok
  Francesca Palombini
  Klaus Hartke
Filename: draft-tiloca-ace-oscore-gm-admin-02.txt
Pages   : 29
Date: 2020-07-13

Abstract:
   Group communication for CoAP can be secured using Group Object
   Security for Constrained RESTful Environments (Group OSCORE).  A
   Group Manager is responsible to handle the joining of new group
   members, as well as to manage and distribute the group key material.
   This document defines a RESTful admin interface at the Group Manager,
   that allows an Administrator entity to create and delete OSCORE
   groups, as well as to retrieve and update their configuration.  The
   ACE framework for Authentication and Authorization is used to enforce
   authentication and authorization of the Administrator at the Group
   Manager.  Protocol-specific transport profiles of ACE are used to
   achieve communication security, proof-of-possession and server
   authentication.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin-02
https://datatracker.ietf.org/doc/html/draft-tiloca-ace-oscore-gm-admin-02

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


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

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

[internet-drafts]

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

Title   : Key Provisioning for Group Communication using ACE
Authors : Francesca Palombini
  Marco Tiloca
Filename: draft-ietf-ace-key-groupcomm-08.txt
Pages   : 58
Date: 2020-07-13

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

Discussion Venues

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

   Source for this draft and an issue tracker can be found at
   https://github.com/ace-wg/ace-key-groupcomm.


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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-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

Re: [Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client

[Stefanie Gerdes]

Hi Christian,

On 07/13/2020 05:12 PM, Christian Amsüss wrote:
> 
> * A malicious attacker intercepts the discovery process, and tells C
>   that there is an RD at
>   `;rt=core.rd`
>   (which is a perfectly legitimate service we're running there for
>   commercial purposes; its interface is that you submit POST a link
>   there in link-format, and then it ties up the link target with endless
>   requests).

I would say that C would need to ascertain that C's owner allowed C to
communicate with this RD.

Viele Gruesse
Steffi

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

[Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client

[Christian Amsüss]

Hello ACE,

piecing together parts of the big picture of Resource Directory, CoRAL
forms and ACE, I was wondering where in the whole story the client
should tie its intention to the key material it uses to authorize an
action.

Take this -- admittedly contrived, but hopefully illustrative example:

* We have a device (C) inside example.com that coordinates a lot of
  actions (and thus has a good standing with the AS and gets almost all
  the tokens it asks for.

* The device would ike to register its management interface with the RD.

* A malicious attacker intercepts the discovery process, and tells C
  that there is an RD at
  `;rt=core.rd`
  (which is a perfectly legitimate service we're running there for
  commercial purposes; its interface is that you submit POST a link
  there in link-format, and then it ties up the link target with endless
  requests).

* The device tries to register to the local RD by POSTing some data
  there, but as it has no token to the attack server, it receives a

  4.01 Unauthorized
  Get your token from coap://as.example.com, scope launch-attack,
  audience attack.example.com

* The client takes those pieces to the AS, which grants it a token
  (after all, C would be authorized to launch an attack, given it's
  known to be a coordinator -- it just doesn't mean to).

* C sends the token to the RS attack, and sends its POST again, with th
  link to its own management interface.

* The attack server brings C to a grinding halt, because it was tricked
  to shoot its own foot.

(Admittedly it's good practice for foot- and other guns to not just
silently ignore query parameters like ep=the-coordinator=3600, but A)
other interfaces may be more accidentally-compatible, and B) CoRAL forms
would widen the range of craftable requests enormously).

My question here is: Where did this go wrong? Should C have verified
with attack.example.com that it really has the resource type core.rd?
Should it have understood the scope of the action? Should it have a
different security association with the AS for every action it asks
tokens for? And does the answer still hold if it has already obtained a
token to launch attacks (but just didn't notice that the RD it was sent
to happens to have the very URI its attack forces use)?

Kind regards
Christian

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


signature.asc
Description: PGP signature
___
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

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

[internet-drafts]

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