[Ace] Re: Agenda for ietf 120

[Göran Selander]

Hi Logan,

I'd like to discuss some updates to

draft-ietf-ace-edhoc-oscore-profile, 10-15 minutes would be good.


Best regards

Göran


Från: Loganaden Velvindron 
Skickat: onsdag, juni 26, 2024 8:02 em
Till: Ace Wg 
Ämne: [Ace] Agenda for ietf 120

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] Re: 2nd WGLC for draft-ietf-ace-revoked-token-notification

[Göran Selander]

Sorry for late response. I’ve looked through the changes and it overall 
contains many good clarifications and the new content is well presented. I had 
some questions about certain formulations in English but not being native I 
leave that to RFC Editor.

Best regards
Göran


From: Tim Hollebeek 
Date: Tuesday, 28 May 2024 at 11:15
To: ace@ietf.org 
Subject: [Ace] 2nd WGLC for draft-ietf-ace-revoked-token-notification

Hello,

Marco recently submitted a rather large set of changes in response to AD review 
and IETF last calls.  Due to the size and number of the changes, Paul has asked 
that we have another WGLC to make sure the group has sufficiently analyzed the 
new text.

So this is a 2nd WGLC for draft-ietf-ace-revoked-token-notification.  Due to 
the amount of information to review, we’ll give people three weeks.

So please review the latest version and send comments to the list by 17 June 
2024.

For the chairs,

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

[Göran Selander]

Hi,

I’ve been following the development of this draft and think it is ready in the 
working group. In addition to some comments already made by Cigdem, I found 
only a few nits in the latest version:


Section 3



’In the rest of this section, these are referred to as "user scope entries".’



…



’In the rest of this section, these are referred to as "admin scope entries".’



  *   Remove “In the rest of this section” in these sentences, as the terms are 
used throughout the document.
  *   Move the text about the convention to abbreviate “admin scope entry” with 
“scope entry”   from the end of section 3.0 to where the former is defined, to 
keep definitions of “scope” together in the document.






Thanks,
Göran


From: Ace  on behalf of Cigdem Sengul 

Date: Friday, 16 February 2024 at 23:36
To: ace@ietf.org 
Cc: Tim Hollebeek 
Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-gm-admin
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

Re: [Ace] Call for adoption for draft-tiloca-ace-group-oscore-profile

[Göran Selander]

Hi,

I also support adoption and am willing to review the draft.

Much of the group-related work in ACE deals with authorization of access to 
keys used for authentication in a group, which is a good application of the ACE 
framework, but this draft actually deals with authorization to access certain 
resources in a group setting, which makes it possible to handle access control 
with granularity.

Göran


From: Ace  on behalf of Alfonso Iacovazzi 

Date: Monday, 18 December 2023 at 12:38
To: Ace Wg 
Subject: Re: [Ace] Call for adoption for draft-tiloca-ace-group-oscore-profile
Hello,

I support the adoption of this document.

Alfonso Iacovazzi



From: Ace  on behalf of Loganaden Velvindron 

Sent: Tuesday, December 12, 2023 4:29 AM
To: Ace Wg 
Subject: [Ace] Call for adoption for draft-tiloca-ace-group-oscore-profile

Hello everyone,



Item #2 coming out of IETF 118 is the call for adoption of
draft-tiloca-ace-group-oscore-profile


https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiloca-ace-group-oscore-profile%2F&data=05%7C02%7Calfonso.iacovazzi%40ri.se%7Cab050f9f5b6f455fbba208dbfac2977d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638379485904621904%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BgRkc1fvD5HbRvJNuUkiNjlvHzssVddTsghuXnvbatc%3D&reserved=0



Should the ACE working group adopt this draft as a working group
draft?  Please clearly state whether you are for or against adoption,
and optionally why, by 20 December, 2023.



-Tim and Logan.

___
Ace mailing list
Ace@ietf.org
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=05%7C02%7Calfonso.iacovazzi%40ri.se%7Cab050f9f5b6f455fbba208dbfac2977d%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638379485904621904%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=RavaSYincC1fCkjXiz8cTbvpcozf4VyTPYI6BithT3M%3D&reserved=0
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Göran Selander]

Hi David,

I agree with Cigdem. Sorry for the delay.

Thanks,
Göran

From: Cigdem Sengul 
Date: Friday, 3 November 2023 at 22:06
To: drafts-expert-review-comm...@iana.org 

Cc: Göran Selander , ace@ietf.org 
Subject: Re: [IANA #1284520] expert review for draft-ietf-ace-key-groupcomm 
(ace)
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 
mailto: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

[Ace] IETF 117 follow up

[Göran Selander]

Hello ACE chairs,

(welcome Tim!)

I was looking for the minutes from IETF 117, and realized that they are not to 
be found in the ACE datatracker but in the same location as the LAKE minutes, 
presumably since it was a shared meeting slot:
https://datatracker.ietf.org/doc/minutes-117-lake-202307241630/

Is there some way to update the ACE datatracker so people will have a better 
chance to find information about this meeting (agenda, material, minutes)?

(Also found in the minutes some notes about planned adoption calls …)

Thanks,
Göran
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] IETF 117 ACE agenda & slot

[Göran Selander]

> Our slot is 17:30-18:30 UTC

Just to avoid potential misunderstanding: LAKE starts 16:30 UTC (and may be 
quite short).

Göran

From: Ace  on behalf of Loganaden Velvindron 

Date: Monday, 24 July 2023 at 08:06
To: Ace Wg 
Subject: [Ace] IETF 117 ACE agenda & slot
Dear Ace participants,

Dear ACE participants, Please find below the ACE agenda. Please be
aware that we are sharing our slot with the LAKE WG
and we need to start as soon as the LAKE WG is done. We rely on your
cooperation so that we can start as soon as LAKE WG
is done. Our slot is 17:30-18:30 UTC.

Kind regards,
//Logan



Administrivia
-- chairs, 5 mins
draft-ietf-ace-edhoc-oscore-profile
-- Göran Selander, 5 mins
draft-ietf-ace-coap-est-oscore
-- Mališa Vučinić, 5 mins
draft-ietf-ace-oscore-gm-admin
-- Marco Tiloca, 5 mins
draft-tiloca-ace-group-oscore-profile
-- Rikard Hoglund, 15 mins
draft-tiloca-ace-authcred-dtls-profile
-- Marco Tiloca, 10 mins
draft-tiloca-ace-workflow-and-params
-- Marco Tiloca, 10 mins
draft-vattaparambil-ace-poa-based-device-reg
-- Sreelakshmi Vattaparambil Sudarsan, 10 mins
AOB
-- 5 mins

___
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] Shepherd review of draft-ietf-ace-revoked-token-notification

[Göran Selander]

Hi Marco, 

> I think it would read better if bullet 4 was merged into bullet 2 altogether. 
> I have made a proposal as a PR at [1]. 

Agree. Looks good. I suggested an editorial change in the same PR. 

Göran 

From: Marco Tiloca 
Date: Friday, 2 June 2023 at 15:08
To: Göran Selander , Ace Wg , 
ace-cha...@ietf.org , 
draft-ietf-ace-revoked-token-notificat...@ietf.org 

Subject: Re: Shepherd review of draft-ietf-ace-revoked-token-notification 

Hi Göran,

Thanks a lot!

Regarding point 21 on the Expert Review Instructions, I think it would read 
better if bullet 4 was merged into bullet 2 altogether.

I have made a proposal as a PR at [1]. Please have a look.

Best,
/Marco

[1] https://github.com/ace-wg/ace-revoked-token-notification/pull/2 
<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-8e4ec944ccdfc0a0&q=1&e=d4d41e59-e93b-4ba5-9097-4fb7e638fa1d&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-revoked-token-notification%2Fpull%2F2>
 
On 2023-06-02 13:58, Göran Selander wrote: 

Hi, 

Here is my shepherd review of draft-ietf-ace-revoked-token-notification. 

1. The working group consensus represents a strong concurrence of 7+ 
individuals with others being silent. 

2-3. No controversy / discontent regarding particular points has been recorded. 

4. There is an existing implementation by Marco Rasori, CNR: 

https://bitbucket.org/marco-rasori-iit/ace-java/src/ucs/ 
<https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-a887080a27565fc8&q=1&e=d4d41e59-e93b-4ba5-9097-4fb7e638fa1d&u=https%3A%2F%2Feur05.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fbitbucket.org%252Fmarco-rasori-iit%252Face-java%252Fsrc%252Fucs%252F%26data%3D05%257C01%257Cmarco.tiloca%2540ri.se%257C3e72876fc6c4467a185408db6360cb5a%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C638213039606562556%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%257C%257C%257C%26sdata%3Duxc6sPqTlxC1JWI%252FN504UYJpal6EA5LA4vWzLtY1uJQ%253D%26reserved%3D0>
 

5. The contents relate to the constrained RESTful cluster of work which covers 
several working groups, but is essentially a "leaf-draft" which provides a 
feature for the ACE framework. 

6. MIB and YANG seems not relevant. Media type and CoAP content-format review 
criteria are met. 

7. The document does not contain YANG 

8. No formal review tools have been used. Two simple examples of CDDL are 
included. 

9. The draft is ready for AD review 

10. No areas have identified any issues, area reviews still to come 

11. The draft aims to be Proposed Standard, which is the proper type of RFC for 
this kind of protocol. 
The datatracker state attributes correctly reflect this intent. 

12. None of the authors of the current version (-05) are aware of any IPR that 
affects this draft. (Question asked by ACE chair earlier this year.) 

13. All authors of the current version (-05) are willing to be listed as an 
author. (Question asked by ACE chair earlier this year.) 

14. No remaining nits were found. 

15. Normative and Informative References seems to be correctly attributed. 

16. All normative references are freely available to anyone. 

17. No normative downward references. All normative references are either BCP, 
Proposed Standard or Internet Standard. 

18. No normative references to documents that are not ready to be submitted to 
the IESG for publication or otherwise in unclear state. 

19. Publication of this document will not change the status of any existing 
RFCs. 

20. IANA considerations 

The required IANA assignments are complete and appropriate. The IANA 
considerations contain two registrations: 
- media type for messages defined in this protocol and 
- the associated CoAP content format. 
and two new registries, listed in the next point. 

The required IANA assignments are associated with the appropriate reservations 
in IANA registries. The referenced IANA registries have been clearly 
identified. Each newly created IANA registry specifies initial contents, 
allocations procedures, and have a reasonable name . 

21. The following new IANA registries are requested: 

- ACE Token Revocation List Parameters 
- ACE Token Revocation List Errors 

The instructions to the Designated Expert are clear, but there are seem to be 
duplicate instructions in bullets 2 and 4: 

- 'Specifications are needed for the "Expert Review" range if they are expected 
to be used outside of closed environments in an interoperable way. When 
specifications are not provided, the description provided needs to have 
sufficient information to identify what the point is being used for.' 

- ‘When specifications are not provided for a request where "Expert Review" is 
the assignment policy, the description provided needs to have sufficient 
information to verify the code points above.' 

Some of the autho

[Ace] Shepherd review of draft-ietf-ace-revoked-token-notification

[Göran Selander]

Hi,

Here is my shepherd review of draft-ietf-ace-revoked-token-notification.

1. The working group consensus represents a strong concurrence of 7+ 
individuals with others being silent.

2-3. No controversy / discontent regarding particular points has been recorded.

4.  There is an existing implementation by Marco Rasori, CNR:

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

5. The contents relate to the constrained RESTful cluster of work which covers 
several working groups, but is essentially a "leaf-draft" which provides a 
feature for the ACE framework.

6. MIB and YANG seems not relevant. Media type and CoAP content-format review 
criteria are met.

7. The document does not contain YANG

8. No formal review tools have been used. Two simple examples of CDDL are 
included.

9. The draft is ready for AD review

10. No areas have identified any issues, area reviews still to come

11. The draft aims to be Proposed Standard, which is the proper type of RFC for 
this kind of protocol.
The datatracker state attributes correctly reflect this intent.

12. None of the authors of the current version (-05) are aware of any IPR that 
affects this draft. (Question asked by ACE chair earlier this year.)

13. All authors of the current version (-05) are willing to be listed as an 
author. (Question asked by ACE chair earlier this year.)

14. No remaining nits were found.

15. Normative and Informative References seems to be correctly attributed.

16. All normative references are freely available to anyone.

17. No normative downward references. All normative references are either BCP, 
Proposed Standard or Internet Standard.

18. No normative references to documents that are not ready to be submitted to 
the IESG for publication or otherwise in unclear state.

19. Publication of this document will not change the status of any existing 
RFCs.

20. IANA considerations

The required IANA assignments are complete and appropriate. The IANA 
considerations contain two registrations:
- media type for messages defined in this protocol and
- the associated CoAP content format.
and two new registries, listed in the next point.

The required IANA assignments are associated with the appropriate reservations 
in IANA registries. The referenced IANA registries have been clearly 
identified. Each newly created IANA registry specifies initial contents,
allocations procedures, and have a reasonable name .

21. The following new IANA registries are requested:

- ACE Token Revocation List Parameters
- ACE Token Revocation List Errors

The instructions to the Designated Expert are clear, but there are seem to be 
duplicate instructions in bullets 2 and 4:

- 'Specifications are needed for the "Expert Review" range if they are expected 
to be used outside of closed environments in an interoperable way.  When 
specifications are not provided, the description provided needs to have 
sufficient information to identify what the point is being used for.'

- ‘When specifications are not provided for a request where "Expert Review" is 
the assignment policy, the description provided needs to have sufficient 
information to verify the code points above.'

Some of the authors should be request to be designated experts.



In summary, with possible exception for the duplicate instructions mentioned in 
item 21, the document is ready to progress.

Göran

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

Re: [Ace] ACE agenda / presentation

[Göran Selander]

Hi,

Just confirming the need for a slot for edhoc-oscore-profile, 5-10 minutes. In 
particular it would be good to discuss a proposal to take out the use of 
EDHOC_KeyUpdate, sketched here:
https://github.com/ace-wg/ace-edhoc-oscore-profile/pull/1

Göran

From: Ace  on behalf of Daniel Migault 

Date: Monday, 13 March 2023 at 23:14
To: Ace Wg 
Cc: lake-cha...@ietf.org 
Subject: Re: [Ace] ACE agenda / presentation
Please find the current draft agenda that considers the received inputs so far. 
Feel free to comment, we will share it with lake chairs so they can upload it 
on time (march 15).

- words from chairs / AD (5 minutes)
- pubsub-profile (10 minutes) Cigdem
- revoked-token WGLC discussions (10 minutes) Marco
- oscore-gm-admin (10 minutes) Marco
- follow-up activities (5-10 minutes) Marco
- selander-ace-coap-est-oscore (10 minutes )
- edhoc-oscore-profile ?

Yours,
Logan and Daniel

On Mon, Mar 13, 2023 at 12:20 PM Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:
Hi,

Please do not forget to provide feed backs regarding the current agenda by 
today if possible  - and confirm your slot.
- words from AD
- revoked-token WGLC discussions if needed)
- oscore-gm-admin
- pubsub-profile
- edhoc-oscore-profile
- group-oscore-profile
- selander- -ace-coap-est-oscore (10 minutes )

Yours,
Logan and daniel

On Fri, Mar 10, 2023 at 2:37 PM Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:
Hi all,

As we are sharing the session with the lake, we need to be a bit more organized 
than we usual are. If you intend to request a session please provide by Monday 
13 (end of your day) a time slot request.

current agenda could be, but please confirm.
- words from AD
- revoked-token WGLC discussions if needed)
- oscore-gm-admin
- pubsub-profile
- edhoc-oscore-profile
- group-oscore-profile

Yours,
Daniel

On Sat, Feb 25, 2023 at 10:04 AM Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:
Hi,

Please do not forget to update the agenda:
https://notes.ietf.org/notes-ietf-116-ace

and upload your presentations by 2023-03-26 (Yokhoama time)
https://datatracker.ietf.org/meeting/116/session/ace

Yours,
Logan and Daniel

--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson


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

Re: [Ace] I-D Action: draft-ietf-ace-extend-dtls-authorize-07.txt

[Göran Selander]

Done in https://github.com/ace-wg/ace-extend-dtls-authorize/commit/5159d04

(Assuming you meant “please change Extension of x to y into Extension to y of x 
when x is ridiculously long. 😊)

From: Ace  on behalf of Carsten Bormann 
Date: Thursday, 9 March 2023 at 23:44
To: Ace Wg 
Subject: Re: [Ace] I-D Action: draft-ietf-ace-extend-dtls-authorize-07.txt
Note that DTLS and TLS are on the RFC-editor’s “unnecessary to expand” list:

https://www.rfc-editor.org/materials/abbrev.expansion.txt

(And please change Extension of x to y into Extension of y to x when x is 
ridiculously long.)

Grüße, Carsten

>
>Title   : Extension of the Datagram Transport Layer Security 
> (DTLS) Profile for Authentication and Authorization for Constrained 
> Environments (ACE) to Transport Layer Security (TLS)

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

Re: [Ace] ACE interim meeting: 2023-01-23 14:00 UTC.

[Göran Selander]

Hi Daniel and all,

I thought I had answered but it seems not have left my mailbox: If there is 
time on the agenda, I’d like to discuss some new input related to ACE framework 
and profiles.

One particular item is the EDHOC-OSCORE profile [1], I will bring some slides.

Göran

[1] https://datatracker.ietf.org/doc/html/draft-ietf-ace-edhoc-oscore-profile



From: Ace  on behalf of Daniel Migault 

Date: Wednesday, 18 January 2023 at 04:16
To: Ace Wg 
Subject: Re: [Ace] ACE interim meeting: 2023-01-23 14:00 UTC.
Hi,

This is just a reminder of our next interim meeting. If you would like to 
present feel free to let the WG know.

Yours,
Logan and Daniel

On Wed, Jan 4, 2023 at 9:13 PM Daniel Migault 
mailto:mglt.i...@gmail.com>> wrote:
Hi,

This is just a reminder that we have an ACE interim meeting this month on 
2023-01-23 14:00 UTC.

Meeting informations are available here:
https://datatracker.ietf.org/meeting/interim-2023-ace-01/session/ace

Current documents we expect to make progress and discuss are:
1. -pubsub-profile
2. -revoked-token-notification
3. -oscore-gm-admin
4. -edhoc-oscore-profile (first presentation)
5. (key-groupcomm-oscore) if not already shipped to the IESG.

Yours,
Logan and Daniel

--
Daniel Migault
Ericsson


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

Re: [Ace] Check about IPR relating to draft-ietf-ace-key-groupcomm-oscore

[Göran Selander]

Sorry, responded to the wrong request, please disregard.

Göran

From: Ace  on behalf of Göran Selander 


Subject: Re: [Ace] Check about IPR relating to 
draft-ietf-ace-key-groupcomm-oscore
Hi,

I am not aware of any IPR related to this document.

Best regards
Göran

From: Ace  on behalf of Francesca Palombini 

Date: Thursday, 12 January 2023 at 10:41
To: Marco Tiloca , Rikard Höglund 
, ace@ietf.org 
Cc: draft-ietf-ace-key-groupcomm-osc...@ietf.org 

Subject: Re: [Ace] Check about IPR relating to 
draft-ietf-ace-key-groupcomm-oscore
I am not aware of any IPR related to this document.

Thanks,
Francesca

From: Ace  on behalf of Marco Tiloca 

Date: Monday, 19 December 2022 at 14:32
To: Rikard Höglund , ace@ietf.org 
Cc: draft-ietf-ace-key-groupcomm-osc...@ietf.org 

Subject: Re: [Ace] Check about IPR relating to 
draft-ietf-ace-key-groupcomm-oscore
Hi Rikard,

I do not have and I am not aware of any IPR on this document.

Best,
/Marco
On 2022-12-19 13:49, Rikard Höglund wrote:
Hello.

To the authors of draft-ietf-ace-key-groupcomm-oscore and all working group 
members.

As I am shepherd for draft-ietf-ace-key-groupcomm-oscore, I would like to check 
whether there are any claims of Intellectual Property Rights (IPR) on the 
document.

Question to the authors: Are you personally aware of any IPR that applies to 
this draft? If so, has this IPR been disclosed in compliance with IETF IPR 
rules? Please reply to this email regardless of whether or not you are 
personally aware of any relevant IPR.

Question to all others: If you are aware of IPR relevant to this draft please 
reply to this mail thread with such information.

Best
Rikard Höglund






--

Marco Tiloca

Ph.D., Senior Researcher



Phone: +46 (0)70 60 46 501



RISE Research Institutes of Sweden AB

Box 1263

164 29 Kista (Sweden)



Division: Digital Systems

Department: Computer Science

Unit: Cybersecurity



https://www.ri.se<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-3d296ae5721cac2b&q=1&e=64bd58a3-ed46-4003-9063-26caeb12ffb0&u=https%3A%2F%2Fwww.ri.se%2F>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Check about IPR relating to draft-ietf-ace-key-groupcomm-oscore

[Göran Selander]

Hi,

I am not aware of any IPR related to this document.

Best regards
Göran

From: Ace  on behalf of Francesca Palombini 

Date: Thursday, 12 January 2023 at 10:41
To: Marco Tiloca , Rikard Höglund 
, ace@ietf.org 
Cc: draft-ietf-ace-key-groupcomm-osc...@ietf.org 

Subject: Re: [Ace] Check about IPR relating to 
draft-ietf-ace-key-groupcomm-oscore
I am not aware of any IPR related to this document.

Thanks,
Francesca

From: Ace  on behalf of Marco Tiloca 

Date: Monday, 19 December 2022 at 14:32
To: Rikard Höglund , ace@ietf.org 
Cc: draft-ietf-ace-key-groupcomm-osc...@ietf.org 

Subject: Re: [Ace] Check about IPR relating to 
draft-ietf-ace-key-groupcomm-oscore
Hi Rikard,

I do not have and I am not aware of any IPR on this document.

Best,
/Marco
On 2022-12-19 13:49, Rikard Höglund wrote:
Hello.

To the authors of draft-ietf-ace-key-groupcomm-oscore and all working group 
members.

As I am shepherd for draft-ietf-ace-key-groupcomm-oscore, I would like to check 
whether there are any claims of Intellectual Property Rights (IPR) on the 
document.

Question to the authors: Are you personally aware of any IPR that applies to 
this draft? If so, has this IPR been disclosed in compliance with IETF IPR 
rules? Please reply to this email regardless of whether or not you are 
personally aware of any relevant IPR.

Question to all others: If you are aware of IPR relevant to this draft please 
reply to this mail thread with such information.

Best
Rikard Höglund





--

Marco Tiloca

Ph.D., Senior Researcher



Phone: +46 (0)70 60 46 501



RISE Research Institutes of Sweden AB

Box 1263

164 29 Kista (Sweden)



Division: Digital Systems

Department: Computer Science

Unit: Cybersecurity



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

Re: [Ace] Meeting in Yokhohama ?

[Göran Selander]

Hi Daniel,

I plan to be present at IETF 116 and the ACE meeting. I agree with much of what 
Carsten writes. At the f2f meetings we usually get valuable input from people 
who not normally attend interims (if we arrange for stimulating such 
discussions).

Göran


From: Ace  on behalf of Carsten Bormann 
Date: Monday, 19 December 2022 at 10:56
To: Daniel Migault 
Cc: Ace Wg 
Subject: Re: [Ace] Meeting in Yokhohama ?
Hi Daniel,

> 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

I plan to be present.

> 2 - what should be discussed that cannot be discussed during interim meetings

A lot of things can be discussed.  The question is whether we get the people 
that we want to have for the discussion in the room.

A formal meeting session at an IETF meeting has a stronger draw.  We usually 
have much serendipity in having the right people around.
Occasionally, pushing discussions into interim meetings can be beneficial; 
e.g., if we need more guest-like appearances (from people who wouldn’t be as 
inclined to pay meeting fees).  Periodic interim meetings are also good for 
tracking progress and deciding little things.

Grüße, Carsten

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

Re: [Ace] ace-ake-auth updates for latest EDHOC principles

[Göran Selander]

Some additional comments inline:

From: Ace  on behalf of Michael Richardson 

Date: Wednesday, 12 October 2022 at 15:24
To: l...@ietf.org 
Cc: ace@ietf.org , an...@ietf.org 
Subject: [Ace] ace-ake-auth updates for latest EDHOC principles

The authors of draft-selander-ace-ake-auth have been discussing how to update
this draft to reflect some of the changes in EDHOC.  Specifically, there is a
concern that ace-ake-auth reveals too much in message_1, things which EDHOC
has worked hard to keep private.
One planned change in the next version is to shift the trust model
from:

  *   the trusted third party, W, is trusted to decide to which authenticator V 
the identity of the device U is revealed
to:

  *   the device U decides to which authenticator V it reveals its identity.
Since the authentication credential of U may be large it is still desirable 
that V can obtain it from W rather than over the constrained link between U and 
V, but - to match the changed trust assumption above - at a different time in 
the protocol: after message_3 instead of before message_2.

For those that don't know ace-ake-auth, it fits into the "Ultra-constrained"
onboarding column for the diagram that was part of
https://datatracker.ietf.org/doc/html/draft-richardson-enrollment-roadmap-03
(and was in the IoT-Dir wiki, which needs to be resurrected.  The diagram is
also visible at:
https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-bbfeee37309f6b5e&q=1&e=ed56df95-0487-4240-99b5-7a62a7af1bd5&u=https%3A%2F%2Fgithub.com%2Fanima-wg%2Fenrollment-roadmap%2Fblob%2Fmaster%2Ftechnology-components.svg
 )

The ACE connection is that the backend (aka "BRSKI-MASA" protocol equivalent)
was leveraged against the ACE mechanism.  There is now some reconsideration
here.  Fundamentally, it would be nice to know where the document adoption is
going so that we'd know where to have public discussions about the trade-offs.
(please note reply-to)
Michael’s way of saying that LAKE is a natural candidate. This draft is 
building on EDHOC and matches a request from the LAKE WG to produce an example 
showing how the External Authorization Data message fields can be applied.

The location of the MASA (aka "W" in the document) is provided in the clear
during message_1, with the actual device serial number encrypted to W using a
static DH key that the pledge ("U") has been provisioned with.

It would be nice to move some of this from message_1 to message_3, which
would guard better against on-path attacks that impersonate V.
See above.
Göran

The URL
provided during message_1 is visible to any observers, and since this is
onboarding, any network privacy is not yet applicable.

OTH, the authorization step needs to complete before message_2 can properly
be formed, as it contains enough of the RFC8366 constrained-voucher semantics
that it allows the pledge (U) to authenticate V.

Knowing the identity of the MASA may tell you a lot about the device in
question.  This is a place where having many MASA outsourced to a big MASA
helps with privacy.  It's also a place where perhaps oblivious-HTTP might
help.

There is a question about what the security policy of W is.
Is it TOFU-ish, aka promiscious MASA, or does *it* know which device has been
sold to whom?

Also, the URL for the MASA is ideally very very short :-)

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




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

Re: [Ace] interim-2022-ace-01 interim approved

[Göran Selander]

Hi Daniel,

We would like to present the new EDHOC-OSCORE profile of ACE that was submitted 
for IETF 114:

https://datatracker.ietf.org/doc/html/draft-selander-ace-edhoc-oscore-profile

In brief, the idea is the following: Whereas in the OSCORE profile the access 
token is bound to a symmetric key used with OSCORE, in
this profile the access token is bound to a public key credential used to 
authenticate with EDHOC and establish a shared symmetric key which is used with 
OSCORE.

Best regards
Göran


From: Ace  on behalf of Daniel Migault 

Date: Thursday, 8 September 2022 at 15:13
To: Ace Wg 
Subject: Re: [Ace] interim-2022-ace-01 interim approved
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 
mailto:mglt.i...@gmail.com>> 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 
mailto:session-requ...@ietf.org>>
Date: Mon, Aug 29, 2022 at 8:53 AM
Subject: interim-2022-ace-01 interim approved
To: mailto:ace-cha...@ietf.org>>, 
mailto:mglt.i...@gmail.com>>



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

Re: [Ace] WGLC draft-ietf-ace-extend-dtls-authorize

[Göran Selander]

Besides the recent notification on the ACE mailing list, I'm not aware of any 
other IPR related to this document.

Göran

From: Ace  on behalf of Daniel Migault 

Date: Tuesday, 22 March 2022 at 14:43
To: Olaf Bergmann 
Cc: Loganaden Velvindron , Marco Tiloca 
, Ace Wg 
Subject: Re: [Ace] WGLC draft-ietf-ace-extend-dtls-authorize
Just reminding other co-authors
.
Yours,
Daniel

On Tue, Mar 15, 2022 at 11:00 AM Olaf Bergmann 
mailto:bergm...@tzi.org>> wrote:
Hi Logan and Daniel,

On 2022-02-28, Daniel Migault mailto:mglt.i...@gmail.com>> 
wrote:

> For all co-authors, please provide an IPR statement and let us
> know of any known implementations.

I am not aware of any IPR related to this document.

Our implementation (WIP) at [1] supports CoAP transport over DTLS
and TLS using libcoap [2]. The client-side retry with different
transport layer security is not yet implemented, though.

[1] https://gitlab.informatik.uni-bremen.de/DCAF/dcaf
[2] 
https://libcoap.net

Grüße
Olaf


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

Re: [Ace] IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ace-extend-dtls-authorize

[Göran Selander]

All,

F.y.i. - this is the same IPR disclosure that has been given on 
draft-ietf-ace-dtls-authorize (RFC-to-be 9202) some years ago.

Göran


From: IETF Secretariat 
Date: Friday, 25 March 2022 at 09:41
To: draft-ietf-ace-extend-dtls-author...@ietf.org 

Cc: ace@ietf.org , ipr-annou...@ietf.org 
Subject: IPR Disclosure Telefonaktiebolaget LM Ericsson (publ)'s Statement 
about IPR related to draft-ietf-ace-extend-dtls-authorize
Dear Olaf Bergmann, John Preuß Mattsson, Göran Selander:


An IPR disclosure that pertains to your Internet-Draft entitled "Extension of
the CoAP-DTLS Profile for ACE to TLS" (draft-ietf-ace-extend-dtls-authorize)
was submitted to the IETF Secretariat on 2022-03-25 and has been posted on
the "IETF Page of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/5575/). The title of the IPR disclosure is
"Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to
draft-ietf-ace-extend-dtls-authorize"


Thank you

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

[Ace] draft-ietf-ace-key-groupcomm-oscore-13

[Göran Selander]

All,

I have taken a look at ace-key-groupcomm-oscore-13. The intent was to make a 
complete review but I think it would be easier to do that if the draft was 
somewhat restructured first - a concrete proposal is the main content of this 
mail. A lot of good thinking has been put into this draft and there are traces 
from re-writes due to changes in the documents it depends on, which may be the 
reason for the current structure. In any case I would like to come back with 
more detailed comments once we discussed the structure.

Dependencies:

The main "parent" of this draft is ace-key-groupcomm, of which it is a profile. 
Another parent is core-oscore-groupcomm, for which it provides key management. 
Both are pre-requisite reading and therefore this draft uses content from these 
drafts directly without much introduction. While this is a reasonable 
assumption, I think the reading would be simplified by a slight rearrangement 
of the content.


Restructure proposal summary:

* Follow more closely the order of content in ace-key-groupcomm. More below.

* Start with the main cases and what happens first, wait with exceptions and 
what comes later. Some sections start with listing error codes and come to 
normal operations later. Of course, this is a matter of style, but I was 
surprised, for example, to find group *re-keying* in section 2.2 - essentially 
the first content of the draft - basically before any keying procedures have 
been described.

* Group some of the later sections into subsections, to allow a reader of the 
table-of-contents an overview. The draft has 26 sections excluding appendices. 
For example, sections 8-17 are all about sharing information about groups and 
nodes, which could be made into subsections of one or more sections.

* There are a large number of parameters discussed in the document. It would be 
good if they could be grouped into tables for easier overview and to see which 
belong together and for what purpose. Section 21 provides a list which is a 
good starting point.


I made a sketch as PR #50 to illustrate the comments above (except tables). It 
may be difficult to read the diff since I rearranged sections, made some into 
subsections, and also rearranged some content within sections to make the point 
about my preferred order of things. Again, this is just a proposal and it may 
be that we happen to have quite opposite preferences here.


More details:

ace-key-groupcomm has the following content:

Sec. 3.  authorization req/resp & token transfer req/resp
Sec. 4.  RS REST interface / KDC functionality

Then sections about changes in the group.

Sec. 5. removing member
Sec. 6. rekeying

Then formats, parameters, error identifiers in Secs. 7-9.

This is something like a top-down structure, starting with the main cases and 
what happens first, waiting with exceptions and what comes later.

Now looking at ace-key-groupcomm-oscore, Section 2.1 is essentially a pointer 
to sections 4 and 6  corresponding to section 3 in ace-key-groupcomm). I 
propose to delete section 2.1 and let sections 4 and 6 follow suite, rather 
than point to them.

The next section in  would then be 5 corresponding to section 4 in 
ace-key-groupcomm.

Section 2.2 is about re-keying and stale IDs corresponding to sections 5-6 in 
ace-key-groupcomm. I think that makes more sense to speak about after the 
normal procedure has been described.

Section 3 is about format but is quite independent. This could come before or 
after the main procedures, I put it before. Section 7 is about the public keys 
is also quite independent and actually provides high level understanding of the 
trust model, so I put that before too, but is not critical.


So the order of the first sections would become something like this:

1
3
7
2.0
4
6
5
2.2
...

There are individual paragraphs moved around the PR to make the text flow 
better. Have a look and let's discuss.


A few nits already now:


Nit 1.

> Group OSCORE is
   used to protect CoAP group communication over IP multicast
[I-D.ietf-core-groupcomm-bis]

Not necessarily IP multicast. This is mentioned in multiple occasions. Use the 
general formulation “to protect CoAP group communication.” and mention IP 
multicast as occasional example where needed


Nit 2.

The identification of the HKDF algorithm by using an algorithm value for a 
direct method in COSE (COSE algorithms -11, -10) is somehow violating the 
intent, as there is in this case no COSE object for which the direct method is 
used. The OSCORE profile of ACE (RFC-to-be 9203 
https://www.rfc-editor.org/authors/rfc9203.html) identifies HKDF by the HMAC 
algorithms (see COSE algorithms 5,6,7).



Nit 3.

Consider shorten terminology from "Joining Request/Response" to "Join 
Request/Response" (would also impact ace-key-groupcomm)


Göran






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

Re: [Ace] [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt

[Göran Selander]

Hi Dan,

Please find my replies to your two questions about the update inline below.

Best regards
Göran



From: Dan Garcia Carrillo 

"The communication with the last resource (e.g. '/a/w') from this point MUST be 
protected with OSCORE except during a new (re)authentication (see Section 3.3)."

I don't understand why there is an exception. OSCORE seems to be applied to 
communication with the last resource in all cases:

* In the case of new authentication the procedure explained in Section 3.2 
applies protection with OSCORE in communication with the last resource.
* In the case of re-authentication, the procedure is explained in Section 3.3 
to be "exactly the same" as in Section 3.2.
[authors] Yes, we agree. We can remove that part from the sentence to avoid any 
confusion. Nevertheless, after your comment, it would be worth stating that if 
the access to any other resource requires OSCORE protection can use the 
generated OSCORE context. Does it sound reasonable?

[GS] Yes, the established security context can be used between other resources 
if allowed by the application's security policy. Proposed rephrasing of step 8:

OLD

 "The IoT Device answers with '2.04 Changed' if the EAP

  authentication is a success and the verification of the "POST"

  protected with OSCORE in Step 7 is correctly verified.  The

  communication with the last resource (e.g. '/a/w') from this point

  MUST be protected with OSCORE.  Any other resource that requires

  OSCORE protection MAY be protected with this OSCORE security

  context."

NEW

 "If the EAP authentication and the verification of the OSCORE protected 
"POST" in Step 7 is successful, then the IoT Device answers with an OSCORE 
protected '2.04 Changed'. From this point on, the communication with the last 
resource (e.g. '/a/w')

MUST be protected with OSCORE. If allowed by application policy, same OSCORE 
security context MAY be use to protect communication to other resources between 
the same endpoints."




Another editorial comment refering to the recent update:


OLD
 "The reception of the POST
  message protected with OSCORE with Sender ID equal to RID-I
  (Recipient ID of the IoT device) sent in Step 2 is considered by
  the IoT device as an alternate indication of success 
([RFC3748])."


I would avoid the term Sender ID since it is all about verification of a 
received message, e.g. like this.


NEW

 "The verification of the received OSCORE protected "POST"

message using RID-I (Recipient ID of the IoT device) sent in Step 2 is 
considered by

  the IoT device as an alternate indication of success 
([RFC3748])."






Section 5.1

"If the Controller sends a restricted list
   of ciphersuites that is willing to accept, and the ones supported by
   the IoT device are not in that list, the IoT device will respond with
   a '4.00 Bad Request', expressing in the payload the ciphersuites
   supported. "


Make clear (here or in a security consideration) that in case of an error 
message containing a cipher suite, the exchange of cipher suites between EAP 
authenticator and EAP peer cannot be verified. For example, a man-in-the-middle 
could replace cipher suites in either message which would not be noticed if the 
protocol is ended after step 2.


[authors] That’s right. However, after your comments, we believe this could be 
improved. The reason is that by default we can assume that at least cipher 
suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both entities. As such, 
if the controller includes option 0 in the list of cipher suites, the 
controller will not receive a bad request since at least the IoT device can 
select cipher suite 0 and therefore the authentication will follow until the 
end cipher suite negotiation can be verified.  We think it is simpler and we 
can get rid of a bad request. Does it sound reasonable?

[GS] Sounds OK to me.



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

Re: [Ace] [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt

[Göran Selander]

Hello authors of draft-ietf-ace-wg-coap-eap,

Thanks for working with this draft. Here is a mix of nits/editorials and more 
substantial comments in the order as they appear in the draft.


Abstract

OLD
One of the primer goals is to
NEW
One of the main goals is to


Section 1.

"EAP methods transported in CoAP MUST generate cryptographic material
   [RFC5247] for this specification. "

The term “cryptographic material” is used multiple times in this document but 
is not defined. RFC 5247 uses “keying material”, does that match the intended 
meaning?


Section2.

Figure 1 is perhaps too informative containing endpoints, stacks, what is CoAP, 
and scope of this document. There is no line/arrow between IoT Device and 
Controller, presumably because there is too much other information. Section 2 
don’t talk about the stack at all.

* Proposal: Make two figures: one with nodes and lines/arrows (“architecture”); 
another with the stack, which is essentially the same in the two nodes in scope 
of this document.

*  It is confusing that CoAP role allocation is shown in the figure since those 
only apply to one step of the operation in section 3.2. In all other steps the 
roles are reversed. Proposal: omit the CoAP roles in the figure, and/or provide 
an explanation in section text or caption.  The section text talking about CoAP 
client also needs to be modified accordingly.

* Nit: RFC8323 calls the layer between request/response and reliable transport 
“message framing”. Perhaps you want to have a common layer renaming the 
"Messages" layer with “Message /framing/”.



Section 3.

"It is RECOMMENDED a light EAP method for the case of constrained link and 
constrained IoT devices."

If this will remain a normative recommendation, then there needs to be a 
definition (reference) of "light EAP method". Perhaps consider just explain the 
intention of "light" ("lightweight"?) and remove the normative recommendation?

---

OLD
The article [eap-framework], highlights the benefits of the EAP
   framework.
NEW
The benefits of the EAP framework are highlighted in [eap-framework].


3.1

"resource directory"
Provide a reference or at least as an example, like 
draft-ietf-core-resource-directory,

---

OLD
Example of this protocols
NEW
Example of such protocols



3.2

Step 0

"The message also includes an URI in the payload of the message to indicate to 
what resource (e.g. '/a/x') the Controller MUST send the first message with the 
EAP authentication"

The DoS issues with requiring the Controller to send a message to an unknown 
URI need to be considered.


Step 1

"the Sender ID for OSCORE selected by the Controller"

Is this the Sender ID *of the IoT device* selected by the Controller? In other 
words, is it the Recipient ID of the Controller selected by the Controller? 
That would correspond to how OSCORE identifiers are chosen in EDHOC:

https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#section-3.3.2

Best not to use the terms "SID" or "RID" unqualified in message fields since 
they are reversed on the IoT device and Controller. Better use terminology like 
e.g. RID-I and RID-C for RID of IoT device and Controller, respectively.


Step 2

"the EAP response, the Recipient ID and the selected ciphersuite for OSCORE are 
in the payload."

Is this the Recipient ID *of the IoT device*? See comment above.

---

OLD
In this step, the IoT device MAY create a OSCORE security context with the 
Sender ID and Recipient ID.
NEW
In this step, the IoT device MAY create a OSCORE security context with its 
Sender ID and Recipient ID.


Step 7

OLD
The reception of the POST message protected with OSCORE using the Sender ID 
sent in Step 1 is considered by the IoT device as an alternate indication of 
success ([RFC3748]).

The unqualified "Sender ID" is confusing here. Why does the ID sent in step 1 
indicate success to the IoT device? I would expect the ID selected by the IoT 
device itself and sent in step 2, if used by the Controller to derive the 
OSCORE security context to protect the message in step 7 would be a stronger 
indication of success. Proposal (check if this is correct):

NEW
The reception of the POST message protected with an OSCORE security context 
derived using the Recipient ID of the IoT device sent in Step 2 is considered 
by the IoT device as an alternate indication of success ([RFC3748]).

---

"The communication with the last resource (e.g. '/a/w') from this point MUST be 
protected with OSCORE except during a new (re)authentication (see Section 3.3)."

I don't understand why there is an exception. OSCORE seems to be applied to 
communication with the last resource in all cases:

* In the case of new authentication the procedure explained in Section 3.2 
applies protection with OSCORE in communication with the last resource.
* In the case of re-authentication, the procedure is explained in Section 3.3 
to be "exactly the same" as in Section 3.2.

Also I find the expression "new (re)authentication"

Re: [Ace] New Version Notification for draft-bergmann-ace-extend-dtls-authorize-00.txt

[Göran Selander]

All,

As previously announced, we have now uploaded a tiny draft (essentially two 
paragraphs contained in the Introduction) extending the CoAP-DTLS profile of 
ACE to TLS, for discussion in the ACE meeting tomorrow.

Göran


From: internet-dra...@ietf.org 
Date: Monday, 8 November 2021 at 13:40
To: Göran Selander , John Mattsson 
, Göran Selander , 
John Mattsson , Olaf Bergmann 
Subject: New Version Notification for 
draft-bergmann-ace-extend-dtls-authorize-00.txt

A new version of I-D, draft-bergmann-ace-extend-dtls-authorize-00.txt
has been successfully submitted by Göran Selander and posted to the
IETF repository.

Name:   draft-bergmann-ace-extend-dtls-authorize
Revision:   00
Title:  Extension of the ACE CoAP-DTLS Profile to TLS
Document date:  2021-11-08
Group:  Individual Submission
Pages:  4
URL:
https://www.ietf.org/archive/id/draft-bergmann-ace-extend-dtls-authorize-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bergmann-ace-extend-dtls-authorize/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-bergmann-ace-extend-dtls-authorize


Abstract:
   This document updates the ACE CoAP-DTLS profile by specifying that
   the profile applies to TLS as well as DTLS.




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

[Ace] Extending the CoAP-DTLS profile to TLS

[Göran Selander]

All,

We would like the ACE WG to consider the extension of the CoAP-DTLS profile of 
the ACE framework (draft-ietf-dtls-authorize) to TLS.

An example of where this may be useful: 3GPP has specified the use of CoAP in 
SEAL (Service Enabler Architecture Layer for Verticals) [1] and the 
Service-Based Architecture has previously adopted OAuth 2.0 for authorization 
of access to services. CoAP as specified there is not restricted to UDP but may 
also carried in TCP and web sockets. To apply the ACE framework in that setting 
would require an ACE profile supporting TLS.

The CoAP-DTLS profile supports DTLS 1.2 and 1.3, but is applicable also to 
corresponding versions of TLS. What is missing is essentially that statement. 
This has been discussed previously as John noted in a recent email to the list.

Considering the CoAP-DTLS profile is in a progressed state it may be too late 
to include this in the CoAP-DTLS profile. The other option is a new draft 
updating draft-ietf-dtls-authorize. To illustrate how little additional 
information is needed we wrote a draft with all content in the two-paragraph 
introduction, available in [2], to be submitted when the I-D submission opens 
again.

Note that the proposal is not to define a new profile of the ACE framework. 
That is not desirable since for most practical purposes the authorization is 
independent of whether UDP, TCP or websockets is used.

Could we have a slot on the ACE agenda on Tuesday to discuss this?

Thanks,
Göran


[1] 
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3587

[2] 
https://gitlab.informatik.uni-bremen.de/ace/extend-dtls-authorize/-/blob/main/draft-bergmann-ace-extend-dtls-authorize-00.txt
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Göran Selander]

Hi Marco,

Please find responses inline.

On 2021-08-31, 18:10, "Marco Tiloca"  
wrote:
On 2021-08-24 18:52, Göran Selander wrote:
> Hi,
>
> Here is a review of ace-key-groupcomm-13.
>
>
> General
> ===
  
> 1. How does this scale to large groups?
>
> Depending on application it may not be necessary to update keys during 
join of new members, and depending on the dynamics of the members rekeying may 
not be a major issue. But if it is a large group and all group members need to 
be updated at joining or leaving then this may require a lot of communication 
for which the underlying group communication may be helpful.
>
> For example, in case of a new member joining then a new group key or the 
new node's public key may be distributed using broadcast/multicast and 
protected with some existing group key.

==>MT
Definitely the new group key material to use before completing the 
joining of the new member.

As to the public key of the new group member (if there is one at all, 
depending on the member's roles), it's actually good to admit its 
provisioning _together_ with the group key material. It would spare 
other group members to perform dedicated retrieval traffic with the KDC 
just for that later on. This can be added to the last paragraph of 
Section 4.3.

[GS: OK.]

As to using "some existing group key", yes, this requires a separate set 
of administrative key material, possibly organized into a hierarchy 
whose root is the administrative group key (see also later comments). 
That's the key material used to protect rekeying messages at the 
application layer, and in principle unrelated to the secure 
communication protocol used in the group.

[GS: Sure, I could have been more accurate and written "a key derived from some 
existing shared key". This can be done in different ways but since this draft 
is about rekeying for group communication in resource constrained settings, 
shouldn't the use of the existing secure group communication be defined here or 
in an application profile?]

>
> In case of rekeying a group key after a node has been evicted, a similar 
method could be used if it was possible to apply some key hierarchy scheme like 
e.g. LKH, i.e. distributing new keys corresponding to a path from the evicted 
node to the root in a key hierarchy.

==>MT
Yes. This is explicitly mentioned in Section 4.4, in the second bullet 
point after Figure 15.

As above, this requires a separate set of administrative key material, 
possibly organized into a hierarchy whose root is the administrative 
group key (see also later comments). Also as above, that's the key 
material used to protect rekeying messages at the application layer, and 
in principle unrelated to the secure communication protocol used in the 
group.
<==

[GS: Thanks, I missed that. It seems inevitable for good scalability that at 
least the application profiles define this. More below.]


>
> Two sub-questions:
>
> a. Is it possible to extend the interface to make use of the underlying 
group communication?

==>MT
It should already be able to accommodate it. In particular:

* In Section 4.4, the second bullet point after Figure 15 already 
mentions this possibility. An application profile or a separate 
specification that builds on and extends it would have to define the 
exact rekeying scheme to use and its message formats.

* At the end of Section 4.1.2.1, it is defined that the Joining Response 
can include an optional parameter 'mgt_key_material'. In case of 
rekeying schemes more advanced than a basic point-to-point approach 
using pairwise security associations, this parameter provides a group 
member with the administrative key material _it_ needs to have to 
participate in a group rekeying.

For example, if a hierarchy-based scheme is used, the parameter 
specifies the administrative keys in the key tree from the leaf node 
associated to the group member all the way up along the path from that 
leaf node to the root (which is the administrative group key shared by 
all the group members).

* In Section 4.4, the third bullet point after Figure 15 refers to a 
local "control" resource at a group member, where the KDC can send 
requests such as rekeying messages. The group member can provide the KDC 
with the URI of such a local resource when joining the group, in the 
'control_uri' parameter of the Joining Request.

This is more generally intended as a resource where the KDC can 
reach the group member with a request, and is potentially usable for 
several administrative operations, including a group re

Re: [Ace] About securing last exchange CoAP-EAP

[Göran Selander]

Hi,



Here is a late response to this thread (see first mail at the end).



On 2021-08-16, 16:52, "Ace on behalf of Christian Amsüss" 
 wrote:



Hello,



On Sat, Aug 14, 2021 at 01:37:06PM +0200, Dan Garcia Carrillo wrote:

> As such, CoAP server (left side) could not see the content of the CoAP

> message (message 7) without deciphering it. Moreover, as the URI-path is

> also ciphered we cannot point to the right application to process the

> message to achieve an alternate indication of success.



If the recipient ID were available a bit earlier (and not derived from

the MSK), would it then be viable to infer from the OSCORE ID that this

is the last message, process an "EAP success", and start derivation just

to extract the session lifetime (and thereby confirm the keys)?



(That'd be all assuming that the "EAP success" contains really just the

EAP success code and no further information, which would be "compressed"

into the "some OSCORE is sent on this" information, and that the

Session-Lifetime does not need to be known to advance the EAP state

machine).



[GS] If I understand right, MSK is not intended to be available from the EAP 
state machine until "EAP success" has been declared, which creates a problem to 
protect the message carrying the "EAP success" with MSK or key derived from it. 
Even if EAP success would only be integrity protected, there is still need to 
access the key to verify the integrity of the success message which is a catch 
22.



As far as I understand the two proposals (by the authors and by Christian) they 
are both opportunistic: preliminary declare success, get the MSK, derive the 
key, and attempt to verify the message. But it was not clear to me if success 
can be "withdrawn" or what happens if the message doesn't verify.



Or conversely, if success can be declared opportunistically before access to 
MSK and without verification of message 7, then why not do that already before 
reception of message 7, and withdraw if it doesn't verify?



Other alternatives:



* If the mapping from EAP to CoAP client/server is instead reversed, then 
message 8 would be a CoAP request which can be protected by OSCORE using a key 
derived from MSK since it is by then available. This would add a message 9 (10% 
of the total no. of messages) for key confirmation in the other direction.



* Alternatively, OSCORE may be started after EAP is concluded. This would add 
another message exchange but that exchange could be normal traffic and thus not 
add to the number of messages, if key confirmation can wait until there is 
traffic. An extra exchange for key confirmation can be added only in use cases 
it can't wait and there is no traffic, whatever those are. There is a similar 
setting in LAKE, where EDHOC has an optional message 4 if explicit key 
confirmation cannot be obtained otherwise.





Göran









From: Ace  on behalf of Dan Garcia Carrillo 


Date: Saturday, 14 August 2021 at 13:37

To: EMU WG , "ace@ietf.org" 

Cc: "garcia...@uniovi.es" 

Subject: [Ace] About securing last exchange CoAP-EAP



Dear ACE and EMU WG members,



In the last exchange of CoAP-EAP we intended to run OSCORE to achieve key 
confirmation, a protected EAP success and the establishment of the OSCORE 
security association. It was our understanding that only integrity protection 
was possible but it is not the case after consulting OSCORE authors. More 
specifically, the payload and URI-Path with OSCORE are class E they are 
ciphered (and integrity protected) and, as far as we understand, there is no 
option, currently, of using a NULL encryption suite to achieve only integrity.



 CoAP CoAP

SeverClient

   ...

   5) |<|

  | ACK [0x9869]|

  | Token (0xac)|

  | 2.01 Created Location-Path [/a/z]   | MSK

  | Payload EAP-X-Resp (n)  |  |

   6) |>|  v

  |CON [0x7811] POST /a/z   |OSCORE

  |  Token (0xac), OSCORE   |CONTEXT

MSK   | Payload (EAP success||Session-Lifetime) |(*)

 | 7) |<|

 v| ACK [0x7811]|

   OSCORE  (*)| Token (0xac), OSCORE|

   CONTEXT 8) |>|

  (*) Protected with OSCORE



As such, CoAP server (left side) could not see the content of the CoAP message 
(message 7) without deciphering it. Moreover, as the URI-path is also ciphered 
we cannot point to the right application to process the message to achieve an 
alternate indication of success. However, t

[Ace] draft-ietf-ace-key-groupcomm-13

[Göran Selander]

Hi,

Here is a review of ace-key-groupcomm-13.


General
===

This draft provides a link between the ACE-OAuth authorization framework 
(including its transport profiles) and specifications of communication security 
in groups of constrained devices, e.g. the coap-groupcomm work currently 
developed in CORE. The document is intended to support different group 
communication schemes, but the details of those are defined in separate 
“application profiles” such as draft-ietf-ace-key-groupcomm-oscore (for Group 
OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This draft instead 
defines a common interface to a KDC acting as RS in the ACE-OAuth architecture, 
how to use this interface to perform various key management operations, and 
requirements for such application profiles.

As such, this draft is thus an “intermediary” specification, and its usefulness 
will be determined by the application profiles which I've glanced at but are 
not part of this review. 

While this approach seems reasonable from a structure point of view, I have a 
question about abstracting the underlying communication in comment 1 below. 

The content of the draft is quite elaborate and with detailed examples which is 
good but also leads to my comment number 2.

Now for the main comments:

1. How does this scale to large groups? 

Depending on application it may not be necessary to update keys during join of 
new members, and depending on the dynamics of the members rekeying may not be a 
major issue. But if it is a large group and all group members need to be 
updated at joining or leaving then this may require a lot of communication for 
which the underlying group communication may be helpful. 

For example, in case of a new member joining then a new group key or the new 
node's public key may be distributed using broadcast/multicast and protected 
with some existing group key. 

In case of rekeying a group key after a node has been evicted, a similar method 
could be used if it was possible to apply some key hierarchy scheme like e.g. 
LKH, i.e. distributing new keys corresponding to a path from the evicted node 
to the root in a key hierarchy.

Two sub-questions: 

a. Is it possible to extend the interface to make use of the underlying group 
communication?

b. Is it possible to apply this interface with a key hierarchy scheme? 

These features are not necessarily in scope of this draft, but it would be good 
to understand if a specification of these features would be able to use the 
interface defined here, or if some generalization is required in which case 
that change may be considered already now.


2. How would a "minimal" profile look like?

The target setting for ACE in general and this draft in particular is 
constrained devices and networks. Some parts of the draft give example of 
thinking about lightweight aspects, but other parts are not at all minimalistic 
and includes a large number of features, however in many cases optional. 

It would be interesting to have a “minimal” example, where care has been taken 
in trying to define a group setting such that the resulting messages are as few 
and as small as possible (for a certain security level). The same comment 
applies to code size and state machine: There are a number of options and “nice 
to have” features, which if all implemented could have a measurable impact on 
the footprint.  

The use of the word "minimal" is not intended in an absolute sense but to 
target as little as possible and still provide authorized group key 
functionality. Perhaps such an exercise makes more sense in an application 
profile, such as draft-ace-key-groupcomm-oscore. But this draft may be provide 
a partial answer by indicating what handlers to include (sec. 4), what 
groupcomm parameters (sec. 7), what error ids (sec 8), etc.

(This comment actually applies also to the transport profiles, which this draft 
does not need to take responsibility for.)


 
More detailed comments
===


I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST 
Token” for the different message exchanges, respectively, quite confusing. For 
a long time I thought the latter referred to the former. It is true that the 
access token is carried with the method POST in the second exchange, but I 
think that is irrelevant and would suggest to instead use some other consistent 
terminology. For example, use  “POST /token” and “POST /authz-info” to refer to 
the exchanges, respectively. Alternatively, call the latter “Token 
provisioning” or something similar without reference to the actual method by 
which the token is provisioned.

This applies in particular to:

Figure 2 
“Token Post”

Figure 3 
“POST Token”

“3.3. Token Post”

3.3.1.
“an OPTIONAL parameter of the Token Post
   response message “

3.3.2
“Token Post response”

etc.


4.1

Section 4.1 specifies the handlers, 20 pages. This is followed by how the 
handlers are used 4.2 - 4.10, roughly one page per subsection. When reading

Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oscore-profile-17: (with COMMENT)

[Göran Selander]

Hello Martin, 

Thanks for the review. Please see proposed updates below.

On 2021-03-21, 06:27, "Benjamin Kaduk"  wrote:

On Fri, Mar 19, 2021 at 03:39:31PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-ace-oscore-profile-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Sec 4.1. I don't understand how the OSCORE security context is secure. In 
Sec
> 4.1 it says the C-RS communications need not be protected. But the 
context is
> fully derived from parameters that go back and forth over this channel. 
Why
> can't an observer simply compute the OSCORE keys?

The POST to the authz-info endpoint includes just the access_token, nonce1,
and ace_client_recipientid.  I think that your concerns focuus on the
access_token itself, since that is how the various OSCORE security context
parameters are conveyed from AS to RS (via C).  Note that these parameters
need not be conveyed directly in the token, since the token could be an
opaque reference that requires the RS to use token introspection in order
to retrieve the associated parameters.  However, when introspection is not
used, the security context parameters are indeed carried directly in the
token, and this scheme does not provide security in that case unless the
token contents themselves are protected.

It seems (on a quick check, so I might have missed it) that we don't
actually say "you have to use an encrypted or opaque token" (not one that's
only signed) anywhere.  So ... good catch, and thank you!

[GS] 

The ACE framework (draft-ietf-ace-oauth-authz-38) mandates integrity protection 
of access token, and in the case it contains a symmetric key, encryption:

6.1.   Protecting Tokens

  "If the access token contains the
   symmetric key, this symmetric key MUST be encrypted by the
   authorization server so that only the resource server can decrypt it."

In oscore-profile, the access token is recommended to be CWT which are COSE 
objects, but the requirement to encrypt in case the access token contains the 
OSCORE master secret should of course be explicitly stated. Here is a proposed 
change:

Section 3.2 

OLD
"This profile RECOMMENDS the use of CBOR web token (CWT) as specified in 
[RFC8392]."

NEW
"The OSCORE master secret MUST be encrypted by the authorization server so that 
only the resource server can decrypt it (see Section 6.1. of 
[I-D.ietf-ace-oauth-authz]). This profile RECOMMENDS the use of CBOR web token 
(CWT) protected with COSE_Encrypt/COSE_Encrypt0 as specified in [RFC8392]."

Does this address the comment?

Thanks
Göran


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

Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

[Göran Selander]

Hi Daniel,

I just submitted -38 which includes these changes and some nits.

Göran

On 2021-03-08, 13:14, "Daniel Migault"  wrote:

Thanks Goran, It looks good to me. I believe that a new version can be 
published to reflect the changes and close this issue. 
Yours, 
Daniel 


On Mon, Mar 8, 2021 at 2:35 AM Göran Selander  
wrote:


Hi Daniel,

Here is a proposed changed to the last sentence:

Section 5:
OLD
"Profiles MUST specify a communication security protocol that 
provides the features required above."

  NEW
"Profiles MUST specify a communication security protocol between 
client and RS that provides the features required above. Profiles MUST  specify 
a communication security protocol RECOMMENDED to be used between client and AS 
that provides the features required above. Profiles MUST  specify for 
introspection a communication security protocol RECOMMENDED to be used between 
RS and AS that provides the features required above. These recommendations 
enable interoperability between different implementations without the need to 
define a new profile if the communication between C and AS, or between RS and 
AS, is protected with a different security protocol complying with the security 
requirements above."


Göran


On 2021-03-05, 22:23, "Daniel Migault"  wrote:

Thanks. "C/RS and AS" may not be very clear as it seems - at least to 
me -  to include the communication between the client and the RS. It seems to 
me that  only communications between Client and AS as well as between AS and RS 
are in scope. If that is correct, I would suggest expanding "C/RS and AS" 
accordingly.
Yours, 
Daniel


On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini 
 wrote:


Hi,

(Adding back the ace ml that was dropped at some point)

Here is a proposal for the paragraph in Section 5 with a different last 
sentence to hopefully clarify the need for recommendations but not mandate only 
one sec protocol per profile:

Section 5:
OLD
"Profiles MUST specify a communication security protocol that 
provides the features required above."

  NEW
"Profiles MUST specify a communication security protocol between 
client and RS that provides the features required above. Profiles MUST  specify 
a communication security protocol RECOMMENDED to be used between client and AS 
that provides the features required above. Profiles MUST  specify for 
introspection a communication security protocol RECOMMENDED to be used between 
RS and AS that provides the features required above. These recommendations 
enable interoperability between different implementations, without the need to 
define a new profile if the communication between C/RS and AS is protected with 
a different security protocol complying with the security requirements above."


The proposal for the other section looks good to me.
Francesca

From: Daniel Migault 
Date: Thursday, 4 March 2021 at 17:49
To: Göran Selander 
Cc: Stefanie Gerdes , Olaf Bergmann , 
Francesca Palombini , Russ Mundy 
, "draft-ietf-ace-oauth-au...@ietf.org" 
, Loganaden Velvindron 

Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14



HI Goran, 



sure any wordsmithing / alternative are fine to me. For the second 
alternative the repetition of "with" may sound to me a bit strange.


Unless anyone objects that would be greatly appreciate to have a new 
version submitted. Thanks!



Yours, 
Daniel 







On Thu, Mar 4, 2021 at 11:12 AM Göran Selander 
 wrote:


Hi Daniel,

The proposal coincides with the text I proposed Feb 22 except for one 
sentence:

"Such recommendations are expected, among others, to guarantee 
independent implementations interoperate."

This sentence does not read well to me, perhaps we can change it? For 
example:

"These recommendations are expected to enable interoperability between 
independent implementations." 

 . . . or even add the reason why it is only a recommendation:

"These recommendations are expected to enable interoperability between 
independent implementations, without preventing this profile to be used with 
other security protocols with the AS complying with the security requirements."

I can make the changes and submit a new version of 
draft-ietf-ace-oauth-authz in the beginning of next week when ID submission has 
reopened.

Regards
Göran



On 2021-03-04, 15:54, "Daniel Migault"  wrote:


Hi all, 
I know everyone is very busy by now, but I am wondering if you 
could provide your input so that we can th

Re: [Ace] minor comments on draft-ietf-ace-oscore-profile-16

[Göran Selander]

Hi Ben, and all,

I just submitted -17 based on Ben's comments in this mail thread, and also a 
change of a security consideration.

* "mutual authentication" removed from figure
* the changes proposed below are all included, and further changes to the same 
effect

When I went through the  61 occurrences of "nonce" I found a description of an 
attack which I thought needed to clarified. Please review.

OLD
If that is not guaranteed, nodes are susceptible to reuse of AEAD (nonce, key) 
pairs, especially since an on-path attacker can cause the client to use an 
arbitrary nonce for Security Context establishment by replaying 
client-to-server messages.

NEW
If that is not guaranteed, nodes are susceptible to reuse of AEAD (nonce, key) 
pairs, especially since an on-path attacker can cause the use of a previously 
exchanged client nonce N1 for Security Context establishment by replaying the 
corresponding client-to-server message.


Göran



On 2021-03-04, 22:09, "Benjamin Kaduk"  wrote:

On Thu, Mar 04, 2021 at 04:17:52PM +, Göran Selander wrote:
> Hi Ben,
> 
> Thanks for good comments. 
> 
> Starting with the second comment, I agree the text "mutual 
authentication" in the figure should appear after the first exchange. It seems 
to have been left and forgotten during the ASCII art session. It is described 
in Section 4 so could be removed from the figure if it isn't possible to find a 
place for it to print well.

Sounds reasonable.

> On 2021-03-04, 03:29, "Benjamin Kaduk"  wrote:
> 
> Hi all,
> 
> I was going through the four drafts that have been "waiting for 
writeup"
> for a while, to check that the latest changes are good and they are 
ready
> to go once the last point from the secdir review of
> draft-ietf-ace-dtls-authorize is wrapped up.  In short: they are, but 
I had
> a couple comments on the OSCORE profile that might help improve it.
> 
> In section 2, we have some discussion:
> 
>The use of nonces during the exchange prevents the reuse of an
>Authenticated Encryption with Associated Data (AEAD) nonces/key 
pair
>for two different messages.  Reuse might otherwise occur when 
client
>and RS derive a new Security Context from an existing (non- 
expired)
>access token, as might occur when either party has just rebooted, 
and
>might lead to loss of both confidentiality and integrity.  Instead,
>by using nonces as part of the Master Salt, the request to the 
authz-
>info endpoint posting the same token results in a different 
Security
>Context, by OSCORE construction, since even though the Master 
Secret,
>Sender ID and Recipient ID are the same, the Master Salt is 
different
>(see Section 3.2.1 of [RFC8613]).  If nonces were reused, a node
>reusing a non-expired old token would be susceptible to on-path
>attackers provoking the creation of OSCORE messages using old AEAD
>keys and nonces.
> 
> [GS] Here is a proposal to address your first comment. There are already 
nonce qualifications in partial use so it didn't make sense to me to insert 
extra adjectives on every occasion. See below.
> 
>   The use of nonces during the exchange prevents the reuse of an
>Authenticated Encryption with Associated Data (AEAD) nonces/key 
pair
>for two different messages. 
> 
> [GS] In the sentence above the difference between the nonces should be 
clear, right?

Yes, though if we name N1 and N2 (so, "the use of nonces N1 and N2 during
the exchange") that would let us use N1 and N2 as disambiguators later in
the paragraph, if we need to.  (We may not need to use the names N1 and N2,
though.)

>   Reuse might otherwise occur when client
>and RS derive a new Security Context from an existing (non- 
expired)
>access token, as might occur when either party has just rebooted, 
and
>might lead to loss of both confidentiality and integrity.  Instead,
>by using nonces as part of the Master Salt, the request to the 
authz-
> 
> [GS] "Instead, by using the exchanged nonces as part of the Master Salt, 
..."

+1

>info endpoint posting the same token results in a different 
Security
>Context, by OSCORE construction, since even though the Master 
Secret,
>Sender ID and Recipient ID are the same, the Master Salt is 
different
>(see Section 3.2.1 of [RFC8613]).  If nonces were reused, a node
> 
> [GS] "If the ex

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

[Göran Selander]

Hi Daniel,

draft-ietf-ace-oscore-profile-16 does recommend a security protocol to be used 
between RS and AS, see Section 5:

 "As specified in the ACE framework (section 5.9 of
   [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client)
   and the AS communicates via the introspection or token endpoint.  The
   use of CoAP and OSCORE ([RFC8613]) for this communication is
   RECOMMENDED in this profile; other protocols fulfilling the security
   requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such
   as HTTP and DTLS or TLS) MAY be used instead."

For draft-ietf-ace-dtls-authorize-15: "The use of introspection is out of scope 
for this specification."

So it seems your concern is already resolved in these drafts.

We might ask ourselves why introspection is included in one or not the other. 
It is not heavily used in draft-ietf-ace-oscore-profile-16, only in Section 4.2:

 "The RS may make an introspection request (see Section 5.9.1
   of [I-D.ietf-ace-oauth-authz]) to validate the token before
   responding to the POST request to the authz-info endpoint."

A similar sentence could have been included in draft-ietf-ace-dtls-authorize as 
well (together with a recommendation to use DTLS). 

Is this something we want to change at this stage?


Göran




On 2021-03-05, 22:11, "Ace on behalf of 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

Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

[Göran Selander]

Hi Daniel,

Here is a proposed changed to the last sentence:

Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides 
the features required above."

  NEW
"Profiles MUST specify a communication security protocol between client 
and RS that provides the features required above. Profiles MUST  specify a 
communication security protocol RECOMMENDED to be used between client and AS 
that provides the features required above. Profiles MUST  specify for 
introspection a communication security protocol RECOMMENDED to be used between 
RS and AS that provides the features required above. These recommendations 
enable interoperability between different implementations without the need to 
define a new profile if the communication between C and AS, or between RS and 
AS, is protected with a different security protocol complying with the security 
requirements above."


Göran


On 2021-03-05, 22:23, "Daniel Migault"  wrote:

Thanks. "C/RS and AS" may not be very clear as it seems - at least to me -  
to include the communication between the client and the RS. It seems to me that 
 only communications between Client and AS as well as between AS and RS are in 
scope. If that is correct, I would suggest expanding "C/RS and AS" accordingly.
Yours, 
Daniel


On Fri, Mar 5, 2021 at 11:03 AM Francesca Palombini 
 wrote:


Hi,

(Adding back the ace ml that was dropped at some point)

Here is a proposal for the paragraph in Section 5 with a different last 
sentence to hopefully clarify the need for recommendations but not mandate only 
one sec protocol per profile:

Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides 
the features required above."

  NEW
"Profiles MUST specify a communication security protocol between client 
and RS that provides the features required above. Profiles MUST  specify a 
communication security protocol RECOMMENDED to be used between client and AS 
that provides the features required above. Profiles MUST  specify for 
introspection a communication security protocol RECOMMENDED to be used between 
RS and AS that provides the features required above. These recommendations 
enable interoperability between different implementations, without the need to 
define a new profile if the communication between C/RS and AS is protected with 
a different security protocol complying with the security requirements above."


The proposal for the other section looks good to me.
Francesca

From: Daniel Migault 
Date: Thursday, 4 March 2021 at 17:49
To: Göran Selander 
Cc: Stefanie Gerdes , Olaf Bergmann , 
Francesca Palombini , Russ Mundy 
, "draft-ietf-ace-oauth-au...@ietf.org" 
, Loganaden Velvindron 

Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14



HI Goran, 



sure any wordsmithing / alternative are fine to me. For the second 
alternative the repetition of "with" may sound to me a bit strange.


Unless anyone objects that would be greatly appreciate to have a new 
version submitted. Thanks!



Yours, 
Daniel 







On Thu, Mar 4, 2021 at 11:12 AM Göran Selander 
 wrote:


Hi Daniel,

The proposal coincides with the text I proposed Feb 22 except for one 
sentence:

"Such recommendations are expected, among others, to guarantee independent 
implementations interoperate."

This sentence does not read well to me, perhaps we can change it? For 
example:

"These recommendations are expected to enable interoperability between 
independent implementations." 

 . . . or even add the reason why it is only a recommendation:

"These recommendations are expected to enable interoperability between 
independent implementations, without preventing this profile to be used with 
other security protocols with the AS complying with the security requirements."

I can make the changes and submit a new version of 
draft-ietf-ace-oauth-authz in the beginning of next week when ID submission has 
reopened.

Regards
Göran



On 2021-03-04, 15:54, "Daniel Migault"  wrote:


Hi all, 
I know everyone is very busy by now, but I am wondering if you could 
provide your input so that we can think of closing this issue before the IETF 
110 - or at least as soon as possible. Our initial milestones were to send 
these doc in February ;-)

Yours, 
Logan and Daniel
-- Forwarded message -
From: Daniel Migault 
Date: Tue, Mar 2, 2021 at 11:09 PM
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14
To: Olaf Bergmann 
Cc: Göran Selander , Olaf Bergmann 
, Russ Mundy , ace@ietf.org 
, Stefanie Gerdes , Francesca Palombini 
, Daniel Migault 




 

Re: [Ace] minor comments on draft-ietf-ace-oscore-profile-16

[Göran Selander]

Hi Ben,

Thanks for good comments. 

Starting with the second comment, I agree the text "mutual authentication" in 
the figure should appear after the first exchange. It seems to have been left 
and forgotten during the ASCII art session. It is described in Section 4 so 
could be removed from the figure if it isn't possible to find a place for it to 
print well.

On 2021-03-04, 03:29, "Benjamin Kaduk"  wrote:

Hi all,

I was going through the four drafts that have been "waiting for writeup"
for a while, to check that the latest changes are good and they are ready
to go once the last point from the secdir review of
draft-ietf-ace-dtls-authorize is wrapped up.  In short: they are, but I had
a couple comments on the OSCORE profile that might help improve it.

In section 2, we have some discussion:

   The use of nonces during the exchange prevents the reuse of an
   Authenticated Encryption with Associated Data (AEAD) nonces/key pair
   for two different messages.  Reuse might otherwise occur when client
   and RS derive a new Security Context from an existing (non- expired)
   access token, as might occur when either party has just rebooted, and
   might lead to loss of both confidentiality and integrity.  Instead,
   by using nonces as part of the Master Salt, the request to the authz-
   info endpoint posting the same token results in a different Security
   Context, by OSCORE construction, since even though the Master Secret,
   Sender ID and Recipient ID are the same, the Master Salt is different
   (see Section 3.2.1 of [RFC8613]).  If nonces were reused, a node
   reusing a non-expired old token would be susceptible to on-path
   attackers provoking the creation of OSCORE messages using old AEAD
   keys and nonces.

[GS] Here is a proposal to address your first comment. There are already nonce 
qualifications in partial use so it didn't make sense to me to insert extra 
adjectives on every occasion. See below.

  The use of nonces during the exchange prevents the reuse of an
   Authenticated Encryption with Associated Data (AEAD) nonces/key pair
   for two different messages. 

[GS] In the sentence above the difference between the nonces should be clear, 
right?

  Reuse might otherwise occur when client
   and RS derive a new Security Context from an existing (non- expired)
   access token, as might occur when either party has just rebooted, and
   might lead to loss of both confidentiality and integrity.  Instead,
   by using nonces as part of the Master Salt, the request to the authz-

[GS] "Instead, by using the exchanged nonces as part of the Master Salt, ..."

   info endpoint posting the same token results in a different Security
   Context, by OSCORE construction, since even though the Master Secret,
   Sender ID and Recipient ID are the same, the Master Salt is different
   (see Section 3.2.1 of [RFC8613]).  If nonces were reused, a node

[GS] "If the exchanged nonces were reused, ... "

   reusing a non-expired old token would be susceptible to on-path
   attackers provoking the creation of OSCORE messages using old AEAD
   keys and nonces.

[GS] "... the creation of an OSCORE message using an old AEAD key and nonce."

[GS] In the rest of the document we would use nonce without qualification as it 
is referring to the exchanged value. Is that clear enough or do you want a 
consistent adjective throughout the draft?

Thanks,
Göran



Where we talk about how the nonces (N1 and N2) exchanged during the
authz-info request/response are used to prevent the use of nonce+key
combinations for the AEAD used for the OSCORE messages.  But there's really
two classes of nonce: the ones for the AEAD, and the ones used in
constructing the master salt.  Whenever we just say "nonce" or "nonces"
there is potential for ambiguity, so we might want to add an adjective
every time we use the word, as tedious as it is to do so.


Also in Section 2, I just wanted to check on the location of the "mutual
authentication" indication -- currently it's show after the second OSCORE
Response, but I am not sure why it is not achieved after just the first
Request/Response exchange that performs proof of possession.

Thanks!

-Ben

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

Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14

[Göran Selander]

Hi Daniel and all,

It seems to me that there is no full consensus, so we probably have to inform 
the AD about the disagreement. However, we do seem to agree that we want to 
clarify some parts of the framework. Here is yet another proposal: 

Section 5:
OLD
"Profiles MUST specify a communication security protocol that provides the 
features required above."

NEW
"Profiles MUST specify a communication security protocol between client and RS 
that provides the features required above. Profiles MUST  specify a 
communication security protocol RECOMMENDED to be used between client and AS 
that provides the features required above. Profiles MUST  specify a 
communication security protocol RECOMMENDED to be used between RS and AS that 
provides the features required above."


Section 6.2:
OLD
  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
NEW
"The requirements for communication security of profiles are specified
in Section 5."


If there is an unequivocal positive response from the WG then I may be able to 
publish a new version today.

Göran



On 2021-02-18, 23:03, "Daniel Migault" 
 wrote:

Hi Russ, 

Thanks for the follow-up. I was waiting clearer agreement from eth WG 
before pinging you back. I think I agree with your understanding. My 
understanding is that the WG is willing to specify one way (RECOMMMEND) and not 
leave that unspecified while not preventing other configurations (MAY). This 
obviously results in implementation not following the RECOMMENDED way do not 
interoperate with those following these recommendations.   

The question remains open on whether we should favor openness or 
inter-operability. I suppose that this will be raised at the IESG so we need to 
address this issue clearly.  

Going back to the profiles, it would be good to understand what concrete 
deployment issues the two statements below would raise: 

* OSCORE profile mandating the AS to support OSCORE and have the C <-> AS 
using OSCORE.  
* DTLS profile mandating the AS to support DTLS and have the C <-> AS using 
DTLS.  



Yours, 
Daniel


From: Russ Mundy 
Sent: Thursday, February 18, 2021 3:38 PM
To: Daniel Migault 
Cc: Russ Mundy ; Stefanie Gerdes ; Daniel 
Migault ; Francesca Palombini 
; Göran Selander 
; Olaf Bergmann 
; ace@ietf.org 
Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14  

Hi Daniel & others, 
Thanks for the continuing effort to make the documents more clear and 
understandable. 

I think that there may be a fairly fundamental difficulty understanding 
(possibly on my part) about the intended relationship between the ACE framework 
and profile documents.  It seems appropriate to me that the framework would 
define the overall requirements (especially security requirements) that 
implementers need to meet and profiles provide the ‘how’ for implementers so 
the result is secure, interoperable implementations potentially from multiple 
different implementers of the framework using a particular profile for that 
framework.

If I’m following the discussion correctly, the changes being proposed to 
the framework would only require a profile to define one ‘example (or 
description)’ definition that met the security requirements of the framework 
(even if it was the RECOMMENDED protocol set) but other protocol set(s) could 
be used (MAY) within the definition of a profile.  Including what amounts to 
unspecified protocol set(s) that do not define how they will meet security 
requirements of the framework will likely result in different implementations 
that comply with the profile but do not interoperate from either a protocol or 
a security basis (or both).

Regards,
Russ


On Feb 17, 2021, at 11:16 AM, Daniel Migault  
wrote:

Hi, 

I think that could work for me. If the changes address the initial 
concerns, we may publish these changes in the coming days. 

Yours,. 
Daniel

From: Stefanie Gerdes 
Sent: Wednesday, February 17, 2021 8:51 AM
To: Daniel Migault ; Daniel Migault 
; Francesca Palombini 
Cc: Göran Selander ; Russ 
Mundy ; Olaf Bergmann ; ace@ietf.org 

Subject: Re: [Ace] secdir review of draft-ietf-ace-dtls-authorize-14  

Hi Daniel,

On 02/16/2021 04:53 PM, Daniel Migault wrote:

> Section 5:
> OLD
> "Profiles MUST specify a communication security protocol that provides
>the features required above."
> NEW
> "Profiles MUST specify at least one communication security protocol that 
provides the features required above."
> 
> 
> I have the impression that with MUST specify one expects a mandatory 
protocol to be provided. Would the following tex

Re: [Ace] [Russ Mundy] Re: secdir review of draft-ietf-ace-dtls-authorize-14

[Göran Selander]

Hi,

Russ commented on a formulation in [I-D.ietf-ace-dtls-authorize] (which also 
exist in [I-D.ietf-ace-oscore-profile]) that he characterizes as a deviation 
from the MUST requirement of 6.2 of [I-D.ietf-ace-oauth-authz]: 

  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."

which in turn is referencing the requirements in Section 5:

"(---) it is REQUIRED that the
   communications named above are encrypted, integrity protected and protected 
against message replay.  
   It is also REQUIRED that the communicating endpoints perform mutual 
authentication.  
   Furthermore it MUST be assured that responses are bound to the requests in 
the
   sense that the receiver of a response can be certain that the
   response actually belongs to a certain request.  Note that setting up
   such a secure communication may require some unprotected messages to
   be exchanged first (e.g. sending the token from the client to the
   RS).

   Profiles MUST specify a communication security protocol that provides
   the features required above."

As I recall the intent with the text in Section 5, its purpose is to ensure 
that there is *at least* one common secure protocol complying with the 
requirements.

Furthermore, I think the formulation in section 6.2 is unfortunate - there is 
no need for additional normative text since it is referring to a section where 
the relevant requirements are stated. So, rather than change the text in the 
DTLS/OSCORE profiles, I propose we make a clarification in the ACE framework.

Proposal 1 (Section 6.2):
OLD
  "Profiles MUST specify how communication security according
   to the requirements in Section 5 is provided."
NEW
"The requirements for communication security of profiles are specified in 
Section 5."
  
Proposal 2 (Section 5):
OLD
"Profiles MUST specify a communication security protocol that provides
   the features required above."
NEW
"Profiles MUST specify at least one communication security protocol that 
provides
   the features required above."

All: Does this accurately account for the intent of the framework?
Russ: Would this address your concern?


Göran


On 2021-02-08, 18:33, "Ace on behalf of Olaf Bergmann"  wrote:

Hi Francesca, Daniel,

I did check with Russ if the new text will resolve his concerns. As the
new wording still does not seem to be sufficient, I am forwarding Russ's
response here as I am not entirely clear how to proceed. 

Any ideas?

Grüße
Olaf

 Start of forwarded message 
Subject: Re: secdir review of draft-ietf-ace-dtls-authorize-14
From: Russ Mundy 
Date: Sat, 6 Feb 2021 16:01:00 -0500
Cc: Russ Mundy ,
Daniel Migault ,
"draft-ietf-ace-dtls-authorize@ietf.org" 

To: Olaf Bergmann 

Hi Olaf,

Thanks for the follow up and the additional suggested revision.  

Unfortunately, the NEW: wording does not resolve my concern. In my view, 
this newest suggested wording has the same fundamental problem as the original 
wording, i.e., it does not meet the MUST requirement from 
[I-D.ietf-ace-oauth-authz] to define how "other protocols" meet the 
requirements in Section 5.  

I certainly understand that there are a number of choices that 
implementations can make for various parts of the ACE framework. However, the 
framework does seem to be very clear that profiles have to define how 
communications security requirements of  [I-D.ietf-ace-oauth-authz] are met.  
Even though other protocol combinations can meet the security requirements in 
Section 5 of  [I-D.ietf-ace-oauth-authz], the ACE framework requires that 
profiles define how these requirements will be met.  So the problem remains 
with the current profile only defining how communications security requirements 
are met for CoAP and DTLS but both the NEW: and OLD: wording would permit 
"other protocols" to be used under this profile without defining how the "other 
protocols" meet the security requirements in Section 5 of  
[I-D.ietf-ace-oauth-authz].

Given the requirements of [I-D.ietf-ace-oauth-authz], it seems like any 
protocols allowed by a profile have to define how the framework communications 
security requirements are met when using the allowed protocols.  

Sorry but it seems like including "other protocols" in a profile that have 
no ACE framework profile defined is a significant deviation from the MUST 
requirement of 6.2 of [I-D.ietf-ace-oauth-authz].

Regards,
Russ


> On Feb 4, 2021, at 5:26 AM, Olaf Bergmann  wrote:
> 
> Hi Russ,
> 
> On 2021-01-19, Olaf Bergmann  wrote:
> 
>> Thank you, Russ, very much for your review.
>> 
>> I am perfectly happy with your suggested change to make CoAP over DTLS
>> REQUIRED for this profile.
> 
> as it turned out, people felt that making CoAP over DTLS a requirement
> would be too re

Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Göran Selander]

Hi,

Now merged and submitted.

Göran

On 2021-02-03, 19:19, "Daniel Migault" 
 wrote:

Hi, 

Just following up, I am wondering if the merge can be pushed this week. 

Yours, 
Daniel

From: Ace  on behalf of Daniel Migault 

Sent: Thursday, January 28, 2021 10:09 AM
    To: Göran Selander 
Cc: ace@ietf.org 
Subject: Re: [Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180  

As we have not heard anyone opposed to the rewording I propose we proceed 
to the merge and publish a new version.  
Yours, 
Daniel


On Fri, Jan 15, 2021 at 3:35 AM Göran Selander 
 wrote:


Hi,

In the interim meeting yesterday I was requested to notify the ACE mailing 
list on this point: 

Marco has commented that the term "overwrite" used once in 
draft-ietf-ace-oauth-authz should not be interpreted literally and it is 
proposed to be replaced with "supersede". More details in issue #179 / PR #180.

https://github.com/ace-wg/ace-oauth/issues/179 
<https://protect2.fireeye.com/v1/url?k=6c954d49-330e740a-6c950dd2-861fcb972bfc-3f900ad0dd6394aa&q=1&e=92c9ad59-1185-4cdd-b406-54be47152c48&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fissues%2F179>
https://github.com/ace-wg/ace-oauth/pull/180 
<https://protect2.fireeye.com/v1/url?k=300264fd-6f995dbe-30022466-861fcb972bfc-fdbba8c4f7e4eb66&q=1&e=92c9ad59-1185-4cdd-b406-54be47152c48&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oauth%2Fpull%2F180>

Unless there are any objections the PR will be merged soon.

Göran




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





-- 
Daniel Migault

Ericsson

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

Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap

[Göran Selander]

+1

Devices supporting CoAP and EAP based infrastructures are parts of two disjoint 
ecosystems both of which we consider important. The specification of CoAP as 
low layer transport of EAP is one component that can be added as upgrade to 
both systems which enable their combination.

This is not targeting the most constrained setting. The details of the draft 
needs to be further analyzed and tested, so a degree of commitment from CoAP 
and EAP experts would be needed. With that assumption I believe this 
specification could be a useful component.

Göran


On 2021-01-26, 10:40, "Ace on behalf of Josh Howlett"  wrote:

Hi,

I believe this document should be adopted.


* CoAP will benefit from a successful and highly extensible authentication 
framework that today supports many different forms of authentication, 
increasing the range of use cases that can be supported
* it will enable CoAP-based infrastructure to use existing deployed AAA 
systems for authentication, reducing the barrier to adoption of CoAP
* it will help deployers to align their CoAP and their other EAP-based 
infrastructures, such as IEEE 802.1X, helping them to leverage common business 
processes (e.g., identity proofing and credentialling). This could be 
particularly beneficial within certified environments (e.g., ISO27001).


Josh



Hi, 



The charter approval by the IESG is expected to be approved in the coming 
weeks. In the meanwhile, this email starts a call for adoption on work that has 
been included in the charter. Of course, adoption is contingent on the 
rechartering succeeding.



The document called for adoption is draft-marin-ace-wg-coap-eap available 
here:

https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07





Please state your opinion on whether this work should not or should be 
adopted by the WG and express your motivation for such a statement. The call 
for adoption closes on February 4. 



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

[Ace] draft-ietf-ace-oauth-authz issue #179 / PR #180

[Göran Selander]

Hi,

In the interim meeting yesterday I was requested to notify the ACE mailing list 
on this point: 

Marco has commented that the term "overwrite" used once in 
draft-ietf-ace-oauth-authz should not be interpreted literally and it is 
proposed to be replaced with "supersede". More details in issue #179 / PR #180.

https://github.com/ace-wg/ace-oauth/issues/179
https://github.com/ace-wg/ace-oauth/pull/180

Unless there are any objections the PR will be merged soon.

Göran




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

Re: [Ace] [core] Proposed charter for ACE (EAP over CoAP?)

[Göran Selander]

>> wrote:


Thanks for updating the draft charter at [1], Daniel!

I note that Michael raised the question of whether some other group might
also be interested in working on CMP-over-coap, so the IESG will be sure to
discuss that if CMP is still in the draft ACE charter when it goes to the
IESG for review.

-Ben

On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote:
> Thank you all for the feed backs. For the purpose of driving the charter
> discussion at the IETf 109, I have added the comments into the proposed
> text [1].
>
> My current understanding is that it seems beneficial to add CMPv2 over CoAP
> in the charter. I am happy to be contradicted.
> * I have not seen a clear cut to do one or the other.
> * EST and CMPv2 are two protocols that can be used for enrollment or cert
> management while addressing different cases / needs / situations -- maybe
> we can clarify that point. I can see leveraging the existing CMP
> infrastructure, but it seems that is not the only one.
> * I am not convinced that not having CMP over CoAP will not prevent its
> deployment and as such I prefer to have it standardized - this might be a
> personal thought.
> * Adding any piece of work require cycles, but it seems to me that CPM will
> not have a major impact on the WG progress. The work will probably include
> other WG such a LAMPS.
>
> Yours,
> Daniel
>
> [1]
> https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
>  
> <https://protect2.fireeye.com/v1/url?k=a01e017d-ff8539af-a01e41e6-866132fe445e-7268e18ca0e30ad7&q=1&e=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0&u=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing>
>
> On Tue, Nov 17, 2020 at 6:02 PM Daniel Migault 
> mailto:mglt.i...@gmail.com>> wrote:
>
> > Hi Goran,
> >
> > I added the text to the charter we will discuss later.
> >
> > Yours,
> > Daniel
> >
> > On Fri, Nov 13, 2020 at 10:26 AM Göran Selander <
> > goran.selan...@ericsson.com<mailto:goran.selan...@ericsson.com>> wrote:
> >
> >> Hi Daniel,
> >>
> >>
> >>
> >> Here’s another input to the charter.
> >>
> >>
> >>
> >> The current group key management solutions addresses the problem of
> >> authorized access to group keys and public keys of group members.
> >>
> >>
> >>
> >> A related problem is authorized access of public keys of other devices
> >> not necessarily part of a security group, in the sense of sharing a
> >> symmetric key used to protect group messages.
> >>
> >>
> >>
> >> Authorized access to raw public keys serves an important function in
> >> constrained settings where public key certificates may not be feasible due
> >> to the incurred overhead, e.g. for when authenticating using EDHOC
> >> (draft-ietf-lake-edhoc).
> >>
> >> This functionality is thus a subset of what is already supported, but
> >> since the current solution is geared towards groups a different solution
> >> may be needed (although it is probably possible to reuse parts from the
> >> existing schemes for provisioning and requesting public keys).
> >>
> >>
> >>
> >> With this in mind, I propose the following change (highlighted in
> >> boldface below):
> >>
> >>
> >>
> >> OLD
> >>
> >> The Working Group is charged with maintenance of the framework and
> >> existing profiles thereof, and may undertake work to specify profiles of
> >> the framework for additional secure communications protocols (that are not
> >> necessarily limited to constrained endpoints, though the focus remains on
> >> deployment ecosystems with a substantial portion of constrained devices).
> >>
> >>
> >>
> >> NEW
> >>
> >> The Working Group is charged with maintenance of the framework and
> >> existing profiles thereof, and may undertake work to specify profiles of
> >> the framework for additional secure communications protocols *and **for
> >> additional **support services **providing* *authorized access to crypto* 
> >> *keys
> >> *(that are not necessarily limited to constrained endpoints, though the
> >> focus remains on deployment ecosystems with a substantial portion of
> >> constrained devices).
> >>
> >>
> >>
> >> Göran
> >>
> >>
> >>
> >>
> >>
> >>
> >>

Re: [Ace] Charter discussion

[Göran Selander]

Hi Daniel,

Here’s another input to the charter.

The current group key management solutions addresses the problem of authorized 
access to group keys and public keys of group members.

A related problem is authorized access of public keys of other devices not 
necessarily part of a security group, in the sense of sharing a symmetric key 
used to protect group messages.

Authorized access to raw public keys serves an important function in 
constrained settings where public key certificates may not be feasible due to 
the incurred overhead, e.g. for when authenticating using EDHOC 
(draft-ietf-lake-edhoc).

This functionality is thus a subset of what is already supported, but since the 
current solution is geared towards groups a different solution may be needed 
(although it is probably possible to reuse parts from the existing schemes for 
provisioning and requesting public keys).

With this in mind, I propose the following change (highlighted in boldface 
below):



OLD

The Working Group is charged with maintenance of the framework and existing 
profiles thereof, and may undertake work to specify profiles of the framework 
for additional secure communications protocols (that are not necessarily 
limited to constrained endpoints, though the focus remains on deployment 
ecosystems with a substantial portion of constrained devices).



NEW

The Working Group is charged with maintenance of the framework and existing 
profiles thereof, and may undertake work to specify profiles of the framework 
for additional secure communications protocols and for additional support 
services providing authorized access to crypto keys (that are not necessarily 
limited to constrained endpoints, though the focus remains on deployment 
ecosystems with a substantial portion of constrained devices).


Göran




On 2020-10-15, 19:50, "Ace"  wrote:
Hi,
I would like to start the charter discussion. Here is a draft of a proposed 
charter [1].

It seems to be that additional discussion is needed with regard to the last 
paragraph related certificate management. In particular the discussion might 
revive a discussion that happened in 2017 [2] - when I was not co-chair of ACE 
-and considered other expired work such as [3]. Please make this discussion 
constructive on this thread.

The fundamental question is whether we need certificate management at this 
stage. If the answer is yes, and we have multiple proposals, it would be good 
to clarify the position of the different proposals and evaluate whether a 
selection is needed or not before validating the charter.

Please provide your inputs on the mailing list before October 30. Of course for 
minor edits, you may suggest them directly on the google doc.

Yours,
Daniel

[1] 
https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
 

[2] https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/
[3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/

--
Daniel Migault

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

Re: [Ace] Charter discussion

[Göran Selander]

On 2020-11-03, 19:45, "Ace"  wrote:

Göran Selander wrote:

> The scope of the Working Group includes profiles of the Enrolment over 
Secure Transport (EST) transported with the Constrained Application Protocol 
(CoAP)”

Is this a re-interpretation of the charter, or a proposed charter change?

This is a draft proposed change. Other parts of the new charter text describes 
both work that has been done and work that may come. This text is intended to 
capture both.

Göran



--
Michael Richardson mailto:mcr+i...@sandelman.ca>>   . o 
O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide

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


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

Re: [Ace] Call for agenda item for IETF 109

[Göran Selander]

Hi Daniel,

If there is time we would like to discuss two drafts which are independent but 
can be combined:


  *   draft-selander-ace-ake-authz (this was discussed on the ACE list in 
September)
  *   draft-selander-ace-coap-est-oscore (motivated in a recent mail about the 
new charter)

Göran


On 2020-10-13, 18:33, "Ace"  wrote:
Hi,
The Ace WG will meet during IETF 109. If you are willing to present, please let 
me know by the end of the month what you are willing to present and the 
necessary time you need.

Yours,
Daniel

--
Daniel Migault

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

Re: [Ace] Charter discussion

[Göran Selander]

Hi Daniel, and all,

Some comments on the proposed charter and your mail, sorry for late response.

1.
”The Working Group is charged with maintenance of the framework and existing 
profiles thereof, and may undertake work to specify profiles of the framework 
for additional secure communications protocols”

I take it this text covers (should the WG want to adopt):


  *   draft-tiloca-ace-group-oscore-profile
  *   an ACE-EDHOC profile (i.e. the POST /token response and the access token 
provision information to support authentication with EDHOC, e.g. raw public key 
of the other party). Such a profile could provide good trust management 
properties, potentially at the cost of a larger access token etc.

Right?

2.
”In particular the discussion might revive a discussion that happened in 2017 
[2] - when I was not co-chair of ACE -and considered other expired work such as 
[3]. Please make this discussion constructive on this thread.”

As I remember it, the outcome of this discussion was – in line with the mindset 
of EST – that it is beneficial to re-use authentication and communication 
security appropriate for actual use case. If coaps is suitable for a particular 
use case, then it makes sense to protect also the enrolment procedure with this 
protocol. But whereas the security protocol is coaps instead of https, the 
enrolment functionality and semantics should reuse that of EST, possibly 
profiled for the new setting: [4].

In the same spirit there was support at the meeting [2] to specify protection 
of EST payloads profiled for use with OSCORE as communication security 
protocol, together with a suitable AKE for authentication. Following the 
adoption of EDHOC in LAKE this work has now been revived [5]. IMHO the 
reasoning above still makes sense.

With this in mind, and taking into account recent discussion on the list, 
perhaps this part of the charter:


”The Working Group will standardize how to use Constrained Application Protocol 
(CoAP) as a Transport Medium for the Certificate management protocol version 2 
(CMPv2).   ”

should be rephrased or complemented with the reasoning above, for example:

The scope of the Working Group includes profiles of the Enrolment over Secure 
Transport (EST) transported with the Constrained Application Protocol (CoAP)”

Thanks
Göran

[4] https://tools.ietf.org/html/draft-ietf-ace-coap-est
[5] https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore




On 2020-10-15, 19:50, "Ace"  wrote:
Hi,
I would like to start the charter discussion. Here is a draft of a proposed 
charter [1].

It seems to be that additional discussion is needed with regard to the last 
paragraph related certificate management. In particular the discussion might 
revive a discussion that happened in 2017 [2] - when I was not co-chair of ACE 
-and considered other expired work such as [3]. Please make this discussion 
constructive on this thread.

The fundamental question is whether we need certificate management at this 
stage. If the answer is yes, and we have multiple proposals, it would be good 
to clarify the position of the different proposals and evaluate whether a 
selection is needed or not before validating the charter.

Please provide your inputs on the mailing list before October 30. Of course for 
minor edits, you may suggest them directly on the google doc.

Yours,
Daniel

[1] 
https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing
 

[2] https://datatracker.ietf.org/doc/minutes-interim-2017-ace-03-201710191300/
[3] https://datatracker.ietf.org/doc/draft-selander-ace-eals/

--
Daniel Migault

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

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

[Göran Selander]

Hi Christian,

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

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

Thanks,
Göran


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

Hello Francesca, hello ACE group,

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

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

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

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

Kind Regards
Christian

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

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

Re: [Ace] bringing draft-selander-ace-ake-authz to ACE?

[Göran Selander]

Hi Michael, and all, 

No, this hasn't been discussed in ACE yet. But since you brought it to the 
list, we may restart the discussion here.

We have been working on lightweight procedures for an IoT device to join a 
network. The join process may include a number of components such as 
authentication, remote attestation, authorization, enrolment of locally 
significant certificate, etc. Much of current standards are based on doing 
things in sequence, one thing at a time. This may be a good idea but it 
introduces some redundancies. One way to reduce overhead is to reuse elements 
from the authentication protocol in the authorization or certificate enrolment 
processes. So, instead of passing public keys and signatures multiple times 
between the same endpoints over constrained links during different phases of 
the joining procedure, we try to make more use of the authentication protocol 
while ensuring that the security properties are as expected.

The draft in the subject is looking at third party authorization. It uses the 
"auxiliary data" extension point of EDHOC, and reuses the client ephemeral 
key/nonce with the authorization server. The actual authorization information 
is carried in a "voucher" using the ANIMA terminology, but is requested and 
retrieved as an 8 byte access token using a new ACE profile. This enables 
mutual authentication and authorization at completion of EDHOC, and with little 
additional overhead compared to EDHOC.

A certificate enrolment request may in a similar way be included in message 3 
(not covered in this draft) since authentication and authorization of responder 
takes place at reception of message 2. In order for sending back a certificate 
(or a reference to a certificate) to the initator, a fourth message needs to be 
added, but the overall join procedure could be completed in two round trips.

The question is if ACE is the right place to discuss this topic.

Göran




On 2020-09-08, 03:04, "Michael Richardson"  wrote:


I'm sorry that I missed today's meeting.
I guess this wasn't on the agenda in the end?

Göran Selander  wrote:
> But you are right that the draft is not just a new ACE profile. The
> voucher concept fits into ANIMA, but is carried as an ACE access
> token. It also makes use of the auxiliary data and other elements of
> EDHOC. But neither ANIMA nor LAKE seems to be the right working
> groups. ANIMA is not using the ACE framework, and LAKE is for the
> nearest future only concerned with the basic AKE.

ANIMA BRSKI is not using the ACE framework, but that's because I don't think
it was clear when we started the work that vouchers were semantically 
similar
to JWT/CWT.  Well, I tried to move things that way, but it was just too 
soon.

When we started, I thought that the thing that the AS (W) returns to V is 
an 
RFC8366 semantic voucher (encoded to CBOR a la 
draft-ietf-anima-constrained-voucher).
However, in the document it has taken on it's own life.
I think that we tried to make it close to an ACE token.

This is where the connection comes in.

Jim:
jim> I have been sitting this to try and make a decision and figure 
out
jim> what my feelings are with this draft.  I did a fast read through 
the
jim> document, too fast to actually understand what it is trying to do, 
and
jim> I immediately ran into the question of why this document would be 
part
jim> of ACE.  It is using the concepts of a voucher, which is not 
currently
jim> an ACE concept, as one of the fundamental concepts.  That combined 
with
jim> the use of an AKE makes me very wary of this document.  (I have not
jim> spent enough time embedded in the ECIES and HPKE world to 
understand
jim> this well.)

I think that the ECIES and HPKE part is not particularly significant.
There are some links at:
   
https://protect2.fireeye.com/v1/url?k=245f61e6-7affa3a3-245f217d-8692dc8284cb-0438c9725de3a5ae&q=1&e=43232919-eac0-44fe-9b22-4dd1e1e25947&u=https%3A%2F%2Fwww.sandelman.ca%2FSSW%2Fietf%2Fbrski-links%2F

The link:   Generic Animation of BRSKI - Bootstrapping Remote Secure Key
Infrastructure (ODP) (screencast) (enterprise/IoT screencast)
points to:  https://www.youtube.com/watch?v=Mtbh_GN0Ce4 which is only 5
minutes long.

I should redo this for ACE-AKE-AUTHZ, aka Ultra-Constrained enrollment.

-- 
]   Never tell me the odds! | ipv6 mesh 
networks [
]   Michael Richardson, Sandelman Software Works|IoT architect  
 [
] m...@sandelman.ca  
https://protect2.fireeye.com/v1/url?k=d54ae6c7-8bea2482-d54aa65c-8692dc8284cb-93b42ef9756fce01&q=1&e=43232919-eac0-44fe-9b22-4dd1e1e25947&u=

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

[Göran Selander]

I agree we need to distinguish between managed id-spaces, like groupcomm, and 
cases where we do not strictly need to manage the ids. 

Given the discussion we are having here, a recommendation for to add to RFC8613 
would be "Each endpoint SHOULD assign its recipient identifiers." This is what 
EDHOC does and, with hindsight, this is what the ACE-OSCORE profile should have 
done. There is no security issue with the current draft, it is about 
simplifying the identification of security contexts in various situations by 
removing the need for special considerations due to identifiers allocated by 
different parties. I see no drawbacks in allowing the endpoints make the 
assignment (an OSCORE protected resource request must complete before parties 
are authenticated but this is also required in the current version, 
Sender/Recipient ID may be reused for updated access rights between the same 
endpoints, Client/Server ID terminology becomes redundant, ... ) except that we 
are very late in the process. And this is the authors' fault, Jim has been 
raising issues on this topic and we have not been responsive.

Göran



On 2020-09-09, 08:52, "John Mattsson"  wrote:

The question in my view is if this draft should create collisions. All 
other drafts assigning identities to RFC 8613 that have ever been discussed in 
the IETF takes efforts to not create any collisions in the first place

https://tools.ietf.org/html/draft-selander-lake-edhoc-01
https://tools.ietf.org/html/draft-mattsson-ace-tls-oscore-00
https://tools.ietf.org/html/draft-friel-tls-atls-04

All these assignment mechanism can be used together collision-free without 
ID Context and with minimal length Sender ID / Recipient ID. So I don’t think 
the statement that “Collisions are going to be a common problem across all of 
these different ways of getting OSCORE contexts established.” is correct.

Group OSCORE is a different story, there the assignment mechanism have to 
handle collisions with ID Contexts (unless the deployment is strictly local, 
e.g. when used only over a local radio technology). 

One option is that this draft recommends the use of an ID context unless 
the draft is uses in a local closed system, and that a bis version of the draft 
makes the simple changes to not get collisions in the first place.

It would as you say have been very good if RFC 8613 discussed how to 
negotiate Sender ID / Recipient ID. If there is ever a bis version, this should 
definitly be added. 

John

-Original Message-
From: Jim Schaad 
Date: Tuesday, 8 September 2020 at 21:14
To: John Mattsson , Göran Selander 
, "ace@ietf.org" 
Subject: RE: [Ace] Review of draft-ietf-ace-oscore-profile

John,

I am wondering if this is really the document that should be dealing with 
this collision problem.   A number of the collisions that might occur are going 
to be out of the ACE scope and a more general discussion of the problem should 
probably occur in a BIS version of the CoRE OSCORE document itself.   Memory 
says that the document does not claim to deal with how names are assigned to 
contexts, but I think that having a centralized location that LAKE, ACE (AS, 
Groupcomm and pub-sub) and perhaps other methods that we don’t currently have 
in our radar.  Collisions are going to be a common problem across all of these 
different ways of getting OSCORE contexts established.

Jim


-Original Message-
From: Ace  On Behalf Of John Mattsson
Sent: Tuesday, September 8, 2020 12:40 AM
To: Göran Selander ; 
ace@ietf.org
Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to say that I don't have any strong opinions on how to proceed. I 
just wanted to point out the collision problems with the draft are more severe 
that the group have discussed. Ignoring collisions seems like a mistake, and to 
my understanding there seems to be no benefits of the AS dictating Sender and 
Recipient IDs.

I think Jim has a good point in that the solution with symmetric key 
authentication comes with a lot of limitations anyway.

/John 

    -----Original Message-
From: Göran Selander 
Date: Monday, 7 September 2020 at 17:05
To: John Mattsson , "ace@ietf.org" 

Subject: Re: [Ace] Review of draft-ietf-ace-oscore-profile

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that 
the major comment below is alternatively a possible -bis update. I think this 
is good functionality, and even though related problem statements have been 
discussed before, this solution has not. And although the change is small it 
comes at a late stage. But if it doesn't make it for this version then let's 
make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson" 
 
wrote:

Hi,

I have reviewed the 

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

[Göran Selander]

Hi,

Just want to acknowledge, as was discussed in the WG meeting today, that the 
major comment below is alternatively a possible -bis update. I think this is 
good functionality, and even though related problem statements have been 
discussed before, this solution has not. And although the change is small it 
comes at a late stage. But if it doesn't make it for this version then let's 
make it in an update soon. 

Göran


On 2020-09-05, 14:51, "Ace on behalf of John Mattsson"  wrote:

Hi,

I have reviewed the latest GitHub version of draft-ietf-ace-oscore-profile

https://protect2.fireeye.com/v1/url?k=cd0dd5df-93bc0ebf-cd0d9544-86e2237f51fb-51fc8fb4bf065a0f&q=1&e=5ecc1a37-faa1-4082-857b-150aa2dc3b9a&u=https%3A%2F%2Face-wg.github.io%2Face-oscore-profile%2Fdraft-ietf-ace-oscore-profile.html

In general this draft looks very good. I have one major comments, and 
several more minor comments.

Major comment
---

- Asignment of OSCORE Sender and Recipient IDs

I think the specified mechanism where the AS dictates the OSCORE connection 
parameters is unfortunate. It introduces several current and future 
limitations. The current assignment mechanisms only works without problems in 
close systems where the RS does not have any other non-AS OSCORE connections, 
where the CoAP client and CoAP server roles are fixed and cannot be switched, 
and where only draft-ietf-ace-oscore-profile is used. In systems where the 
OSCORE nodes can switch between CoAP client and CoAP server (a feature 
explicitly supported by OSCORE) the current mechanism is likely to lead to 
RecipientID collisions. Also in future systems where the AS also supports a 
more modern key management with PFS using e.g. a future 
draft-ace-edhoc-oscore-profile, the mechanism would not work together in an 
efficient way. My understanding is that the authors would like the solution to 
work with both role switching and EDHOC.

How to negotiate these type of connection identifiers (in this case OSCORE 
Sender and Recipient IDs) have been studied and specified several times in e.g. 
draft-selander-lake-edhoc, draft-ietf-tls-dtls-connection-id. A solution where 
each party choses its OSCORE recipient ID for the connection always work 
without collisions. Such a negotiation could quite easily be added to the 
roundtrip with the nonces N1 and N2. My feeling is that it would be worthwhile 
to do such a change. This would also require a new identifier for the 
OSCORE_Security_Context Object, either a new objectID or a hash of the object 
could be used. I think this would be a good change as the current "hack" of 
using the ACE client sender Id and and ID context to identify the object might 
lead to other future limitations.

The suggested changes would lead quite equal message sizes and storage 
requirements, they might even lead to some small improvements.

Minor comments
---

- "server authentication"

My understanding is that server authentication with this draft requires two 
additional things. That C trusts AS and that RS sends an OSCORE response back. 
The draft should point this out similarly to the way it points out that a 
OSCORE request is required for proof-of-possession. As C trust in AS, and RS 
sending an OSCORE response back are both optional, I would recommend to maybe 
remove "server authentication" from the abstract and intro.

- "The nonces are encoded as CBOR bstr if CBOR is used, and as Base64 
string if JSON is used"

Would be good to define exactly how the Master salt is created when JSON is 
used. I.e. is the Base64 encoded strings used, or are the byte strings after 
Base64 decoding used.

- "the authz-info endpoint is not a protected resource, so there is no 
cryptographic protection to this request."

I do not think this follows from the OAuth ACE term “protected resource”. 
Most resources on the web are not protected resources, but use cryptographic 
protection (https:// HTTPS)

- "An OSCORE_Security_Context is an object that represents part or all of 
an OSCORE Security Context"

The object cannot represent all of an RFC 8613 OSCORE Security Context as 
sequence number, replay window, and Master salt are missing. I would also 
strongly recommend removing "context" from the name of the object so that it is 
not confused with an RFC 8613 context. Maybe OSCORE input keying material or 
something similar.

- "CBOR type"

The types listed are CDDL types. Should at least mention CDDL or change to 
actual CBOR types.

- "Security Context identified by "kid""

This message has two different "kid", one on the ACE level and one on the 
OSCORE level, would be good to clarify which "kid" this refers to.

- "client" "server"

I think the draft should have a sentence saying that the terms "client" 
"server" when used without specification refer to the ACE client C and the ACE 
resource server RS. There is anothe

Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items)

[Göran Selander]

>I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that
>it fixes a gap in the set of current drafts on the topic:

>Without (something like) this, group deployment applications need
>application specific group managers, and as the GM is not trivial to
>implement, I'd expect that they would bundle the GM with their
>on-at-deployment-time tools rather than ship a constrained and
>well-specified always-on GM that's just managed by their deployment
>tools -- leading to much more error prone deployments that can't
>leverage OSCORE group communication in full.

+1 

I support adoption.

Göran



On 2020-07-03, 08:56, "Ace on behalf of Christian Amsüss" 
 wrote:

Hello ACE,

I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that
it fixes a gap in the set of current drafts on the topic:

Without (something like) this, group deployment applications need
application specific group managers, and as the GM is not trivial to
implement, I'd expect that they would bundle the GM with their
on-at-deployment-time tools rather than ship a constrained and
well-specified always-on GM that's just managed by their deployment
tools -- leading to much more error prone deployments that can't
leverage OSCORE group communication in full.

I don't quite see myself in a position to advocate adoption in this WG I
haven't actively contributed to before, but I do support this document
being processed somewhere in the IETF.

Best regards
Christian


PS: Small by-catch issues for the authors:

The pct-encoded names in the group name sound odd to me. What do those
names have to do with URI components?

The "is fixed" and "is a default name" terminology around resources is
probably confusing to people who don't know ahead of time what it's
supposed to mean; moreover, demanding that the URI be fixed is a pretty
harsh requirement for something that may move around in the network;
furthermore, while an I-D should avoid creating URI aliasing, it
shouldn't rule out that the server may do that either. (And if it
supports different transports, right now it needs to). Later in 2.5.3,
it even sounds like the path is prescribed.

Other than this being an ACE document, is there a particular reason
"Getting Access to the Group Manager" is prescribed to use ACE? The
whole 2.1 section sounds quite repetitive when read in the context of
ACE, and unnecessary when different methods are employed. Maybe if there
were talk about different admins and whether they may change each
other's groups that'd be conveniently be expressed in terms of ACE
scopes (not sure), but as of now it isn't.

Why is "Update a Group Configuration" a PUT and not a PATCH? It does not
replace the resource, it just modifies it.

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

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

[Ace] Multicast notifications for distributing public keys to other group members

[Göran Selander]

Dear CoRE and ACE,

Apologies for cross-posting, this concerns the security for CoAP group 
communications (which is a CoRE draft) and the current specified method to 
retrieve public keys for group communication (which is an ACE draft).

When a node joins a group [0] there is a need for group members to get its 
public key. Section 4.5 of the current Github version of 
draft-ietf-ace-key-groupcomm "Key Provisioning for Group Communication using 
ACE" [1] describes procedures for retrieving the public keys, by accessing the 
resource "ace-group/GROUPNAME/pub-key" in the KDC. Section 4.3 in the same 
document describes the procedure to "make the ... resource Observable, and send 
notifications to Clients when the keying material is updated".

1. The use of notifications is good to avoid similar requests from several 
nodes in these cases. But the procedure is only mentioned briefly as quoted 
above. Would it be possible to expand on this and make it a recommended 
mechanism in this draft, or alternatively, a separate draft?

2. If the number of members in the group is large, it would be even better to 
send just one multicast notification [2] instead of many notifications with the 
same content, but this requires the sending node to be member of the group. The 
Group Manager is the authorized party distributing public keys to nodes of the 
group, but we don't think of it as member of that group. Is it worth to make 
the GM a group member by default to enable the use of [2] for distribution of 
the public key of a (re-)joining node?  

Göran

[0] https://tools.ietf.org/html/draft-ietf-core-groupcomm-bis
[1] 
https://ace-wg.github.io/ace-key-groupcomm/draft-ietf-ace-key-groupcomm.html#name-retrieval-of-public-keys-an
[2] 
https://tools.ietf.org/html/draft-tiloca-core-observe-multicast-notifications


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

Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

[Göran Selander]

Hi Laurence, and all,

Thanks for providing a taxonomy. As mentioned, type 0 is clearly in the current 
draft COSE charter, and we see also the need for a representation of the X.509 
profile in RFC 7925 which relieves constrained devices from implementing 
DER/ASN.1 encoding as well as re-encoding/decompressing in order to verify. 
Whether this is type 1 as proposed in the draft, or type 2 as you propose, is 
open for discussion. I believe I speak on behalf of the authors here.

A question for the chairs and AD: Is it/can it be in the scope of COSE or ACE 
to define type 1/2? Or do you need more show of interest from the community to 
see if this is worth pursuing at all?

Göran



From: Laurence Lundblade 
Date: Thursday, 30 April 2020 at 19:38
To: Göran Selander 
Cc: Göran Selander , Joel Höglund 
, "c...@ietf.org" , "ace@ietf.org" 

Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

Hi Göran,

I understand your two types of native CBOR certs, and raise you by one. I’ve 
assumed COSE because it seems a clear choice to me (no size issue, code re use).

0) Compressed/re-encoded
- Uses CBOR Sequence that exactly mirrors X.509 from Raza draft
- Reduces size of cert, but increased code complexity; both CBOR and DER 
encoding / decoding needed
- Can transform to/from X.509 mechanically without the private key

1) COSE + Mirroring with CBOR Sequence from Raza draft
- Uses the CBOR sequence that exactly mirrors X.509
- Reduces size of cert and lowers code complexity; no DER encoding / decoding
- Must have private key to generate; must be generated by the CA

2) COSE + Mirroring with CWT Claims
- A set of CWT claims are defined that exactly mirror X.509 fields
- Reduces size of cert and lowers code complexity; no DER encoding / decoding; 
can re use some CWT code
- Must have private key to generate; must be generated by the CA

3) COSE + Improved CWT Claims
- A set of CWT claims that don’t necessarily mirror X.509 exactly, but give 
similar semantics
- Reduces size of cert and lowers code complexity; no DER encoding / decoding; 
can re use some CWT code
- Must have private key to generate; must be generated by the CA

I was definitely talking about 3) in my last email. It is clearly not in the 
charter.

So maybe the debate is between 1) and 2). Both are in the charter. Some 
advantages of 2) are:
- Can re use some of the CWT code
- Can move to 3) incrementally when the time comes
- Can drop fields that are not used possibly giving the smallest cert size on 
the wire of any of the options

LL




On Apr 28, 2020, at 3:23 AM, Göran Selander 
mailto:goran.selan...@ericsson.com>> wrote:

Hi Laurence,

Thanks for sharing your thoughts. It seems we are working on slightly different 
paths.

The part you called “Compressed Certs” is already in the draft COSE charter 
where it is referred to as “A CBOR encoding of the compressed certificate 
profile defined in RFC 7925” so we can leave that out for now.

My comment was about the other part, what we both call “native CBOR 
certificates” but mean different things. What is called native in
draft-raza-ace-cbor-certificates is not intended as a certificate format 
breaking with X.509. While there are many potential improvements to make on 
X.509, there is a resistance against new certificate architectures as was clear 
when this was brought up in Secdispatch at IETF 104 a year ago. As mentioned 
previously, what we mean by “native CBOR” is the lossless compression of the 
certificate profile of X.509 into a CBOR encoded format, but signing over the 
CBOR instead of on the uncompressed data. In this way it is possible to define 
a bijection between native CBOR certificates and profiled X.509 certificates – 
the payload of the compressed version of the latter would be identical to the 
former. So the native CBOR certificates are a faithful representation of these 
profiled X.509 certificates, using the same payload as in the CBOR compression 
scheme.

In contrast to the compression scheme, a conversion between native CBOR and 
X.509 representations requires access to the private signature key.
Therefore a mix of X.509 and native CBOR would require multiple handlers at the 
backend (parsing the payload would be the same). Dedicated deployments could of 
course use native CBOR certificates exclusively.

In the same way it would be possible to instead define a COSE_Sign1 and/or a 
CWT representing these profiled X.509 certificates, this is what I thought you 
were asking about but apparently not. That would be an alternative as long as 
we can decide on exactly one of these representations.

There are a lot of fun things to do in this space, my concern is how to get out 
a standard. Trying to replace X.509 doesn’t seem like a promising way forward 
I’m afraid . . .

Göran


From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Laurence Lundblade mailto:l...@island-resort.com>>
Date: Monday, 27 April 2020 at 20:13
To:

Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

[Göran Selander]

Hi Laurence,

Thanks for sharing your thoughts. It seems we are working on slightly different 
paths.

The part you called “Compressed Certs” is already in the draft COSE charter 
where it is referred to as “A CBOR encoding of the compressed certificate 
profile defined in RFC 7925” so we can leave that out for now.

My comment was about the other part, what we both call “native CBOR 
certificates” but mean different things. What is called native in
draft-raza-ace-cbor-certificates is not intended as a certificate format 
breaking with X.509. While there are many potential improvements to make on 
X.509, there is a resistance against new certificate architectures as was clear 
when this was brought up in Secdispatch at IETF 104 a year ago. As mentioned 
previously, what we mean by “native CBOR” is the lossless compression of the 
certificate profile of X.509 into a CBOR encoded format, but signing over the 
CBOR instead of on the uncompressed data. In this way it is possible to define 
a bijection between native CBOR certificates and profiled X.509 certificates – 
the payload of the compressed version of the latter would be identical to the 
former. So the native CBOR certificates are a faithful representation of these 
profiled X.509 certificates, using the same payload as in the CBOR compression 
scheme.

In contrast to the compression scheme, a conversion between native CBOR and 
X.509 representations requires access to the private signature key.
Therefore a mix of X.509 and native CBOR would require multiple handlers at the 
backend (parsing the payload would be the same). Dedicated deployments could of 
course use native CBOR certificates exclusively.

In the same way it would be possible to instead define a COSE_Sign1 and/or a 
CWT representing these profiled X.509 certificates, this is what I thought you 
were asking about but apparently not. That would be an alternative as long as 
we can decide on exactly one of these representations.

There are a lot of fun things to do in this space, my concern is how to get out 
a standard. Trying to replace X.509 doesn’t seem like a promising way forward 
I’m afraid . . .

Göran


From: Ace  on behalf of Laurence Lundblade 

Date: Monday, 27 April 2020 at 20:13
To: Göran Selander 
Cc: Joel Höglund , "c...@ietf.org" , 
"ace@ietf.org" 
Subject: Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

On Apr 27, 2020, at 5:00 AM, Göran Selander 
mailto:goran.selander=40ericsson@dmarc.ietf.org>>
 wrote:

[GS] The rationale for native CBOR certificates is to reuse the same encoding 
as in the compression scheme defined for RFC 7925, but signing the CBOR instead 
of signing the uncompressed data. This provides a roadmap with minimal changes 
when moving from compressed to native CBOR certificates.

I agree with you that the overhead of COSE_Sign1 or CWT is not major and these 
points are open for discussion. The more important question is where this 
should be standardized. The compression scheme is now included in the new draft 
charter for COSE:
https://github.com/cose-wg/Charter/blob/master/Charter.md<https://protect2.fireeye.com/v1/url?k=dd127709-819bd8c0-dd123792-0cc47ad93e1c-5b6bae84abc5c4a0&q=1&e=5bb412fa-ec1d-44a0-8dba-c66844d1b797&u=https%3A%2F%2Fgithub.com%2Fcose-wg%2FCharter%2Fblob%2Fmaster%2FCharter.md>
The charter is currently not explicitly supporting native CBOR certificates. If 
you think it should, in some variant, then this is a good time to raise your 
voice.

To go straight to the issue, I think a designing a native CBOR cert should be 
approached differently than compressing / re-encoding an X.509 cert:

Re-encoding
- Size is important
- Exact compatibility is required
- Near zero change to fields and semantics

Native CBOR Cert
- Clean up some of the mess in X.509; it is an old standard with a lot of cruft 
and baggage
- Re design extensions so they are in CBOR format
- Make many of the fields optional, for example not before can often be left 
off, maybe even serial number
- Avoid DN structure for issuer and subject for most use cases
- Use modern formats like COSE and CWT and COSE_Key
- Size is important, but far from the only goal (some size reductions, like 
optional fields will be possible here that are not possible with re-encoding)
- Compatibility matters, but not in the same way

Seems like the right thing to do here is to remove native CBOR certs from this 
document and just focus on compression and re-encoding. Maybe even call them 
“Compressed Certs” rather than “CBOR Certs”.. Where that work should go is 
above my pay grade.


BUT, my main interest here relates to CWT and EAT. CWT seems like a really good 
choice on which to base a native CBOR cert. Some of the fields for an X.509 
cert are already defined in CWT (subject, issuer, expiration, not-before). It 
has an extension mechanism built in already in the CWT IANA registry. The 
crypto and signing are well-handled by 

Re: [Ace] [COSE] draft-raza-ace-cbor-certificates-04.txt

[Göran Selander]

Hi Laurence,

(Copying both ACE and COSE pending further notice about right mail list.)

Comments inline.

From: COSE  on behalf of Laurence Lundblade 

Date: Friday, 24 April 2020 at 20:58
To: Joel Höglund 
Cc: "c...@ietf.org" 
Subject: Re: [COSE] [Ace] draft-raza-ace-cbor-certificates-04.txt


On Apr 24, 2020, at 5:01 AM, Joel Höglund 
mailto:joel.hogl...@gmail.com>> wrote:

> But of most interest to me is whether the COSE was considered as the
> signing format for native CBOR certs. If COSE is used, then this looks
> almost identical to CWT and may be a native CBOR cert is a variant of
> a CWT? … …

Our starting point has been to stay close to the original X.509 format while 
minimizing size. A COSE encoding would re-add some format overhead (close to 
10% for the provided example certificate). But if a COSE encoding would help 
making the format accepted and used, it can definitely be further discussed.

Once again, thank you for your comments!

Hi Joel,

I’m just focusing on the native CBOR cert here.

[GS] Thanks for showing interest!

The overhead for COSE_Sign1 to encode the algorithm ID, key id (optional), 
payload, and signature is tiny and is fixed. If you assume each of these (IDs, 
payload, sig) already have to be a CBOR-encoded integer or string, then the 
overhead is probably less than ten bytes total, maybe even less than five for 
the COSE structure that groups them.

In your example A.3, I don’t see how the to-be-signed bytes are identified. 
Some solution, probably using bstr wrapping is needed. COSE solves with no more 
overhead than necessary.  (You don’t need this in example A.2, because you 
reconstruct the X.509 ASN.1/DER which does identify the to-be-signed bytes).

I’m not sure where you got the 10% number, but it seems high. Also, the COSE 
overhead is fixed, not proportional to the size of the certificate.

[GS] I think Joel is making a rough estimate of the size of a CBOR certificate 
to that of a COSE_Sign1 of a CWT.

To go on a little more, in the ASN.1 world, X.509 certs didn’t use CMS 
structure for signing which meant they couldn’t share implementations. Seems 
like X.509 and CMS were developed separately. Also, CMS isn’t that compact.

However, COSE_Sign1 is very compact and efficient. If it could be used for a 
native CBOR cert format, then COSE code can be re used. In use cases like 
signed SW updates and secured boot that use certificate chains, both the 
certificate chain and the signed SW updates would use the COSE format and share 
for verifying signatures.

[GS] The rationale for native CBOR certificates is to reuse the same encoding 
as in the compression scheme defined for RFC 7925, but signing the CBOR instead 
of signing the uncompressed data. This provides a roadmap with minimal changes 
when moving from compressed to native CBOR certificates.

I agree with you that the overhead of COSE_Sign1 or CWT is not major and these 
points are open for discussion. The more important question is where this 
should be standardized. The compression scheme is now included in the new draft 
charter for COSE:
https://github.com/cose-wg/Charter/blob/master/Charter.md
The charter is currently not explicitly supporting native CBOR certificates. If 
you think it should, in some variant, then this is a good time to raise your 
voice.

Göran

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

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

[Göran Selander]

I support adoption.



For pub-sub, we need to specify how to do authorization of publishing to a 
broker and authorization of access to published content. What is described in 
this draft is a good way to do that with the ACE framework.



Göran


From: Ace  on behalf of Daniel Migault 

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

Dear working group,

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


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


Yours,
Daniel


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

[Ace] LAKE mailing list and BoF: a handshake protocol for OSCORE

[Göran Selander]

Apologies for cross-posting, but it seems some people not following the 
Secdispatch list have missed the connection between EDHOC and the new LAKE 
mailing list and BoF.

ACE, CoRE, 6TiSCH and LPWAN are identified as stakeholders in the draft charter 
for the LAKE WG (see [1] below).

If you are interested in a handshake protocol for OSCORE, join the LAKE mailing 
list now and attend the LAKE BoF at IETF 105.

Göran


On 2019-06-14, 21:32, "Secdispatch on behalf of Stephen Farrell" 
 wrote:


Hiya,

There's a new mailing list for discussion of lightweight
authenticated key exchange, which has previously been
discussed here in various edhoc threads. There's a BoF
on this topic planned for IETF 105 as well. [1] Yoav and
I are down to chair that at the moment.

So if you're interested in that topic please sign up.
We'll try kick off some pre-BoF discussion once people
have had a chance to get onto the new list and Yoav
and I have had a chance to chat about it all.

Cheers,
S.

[1] https://trac.tools.ietf.org/bof/trac/wiki#LAKE



 Forwarded Message 
Subject: New Non-WG Mailing List: lake
Date: Fri, 14 Jun 2019 10:10:34 -0700
From: IETF Secretariat 
Reply-To: i...@ietf.org
To: IETF Announcement List 
CC: stephen.farr...@cs.tcd.ie, ynir.i...@gmail.com

A new IETF non-working group email list has been created.

List address: l...@ietf.org
Archive: https://mailarchive.ietf.org/arch/browse/lake/
To subscribe: https://www.ietf.org/mailman/listinfo/lake


Purpose:
Constrained environments using OSCORE in network environments such as
NB-IoT, 6TiSCH, and LoRaWAN need a 'lightweight' authenticated key
exchange (LAKE) that enables forward security. 'Lightweight' refers to
resource consumption, measured by bytes on the wire, wall-clock time to
complete, or power consumption; and the amount of new code required on
end systems which already have an OSCORE stack.
This list belong IETF area: SEC

For additional information, please contact the list administrators.



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

[Ace] EDHOC next steps

[Göran Selander]

Dear ACE,

I get questions about what is happening to EDHOC from people following the ACE 
WG mailing list, noting the empty slide in the IETF 104 meeting material and 
not finding the discussion of this topic in the recordings (as it was shifted 
to the end of the meeting). Pending the meeting minutes I just relay what one 
of the co-chairs said in the ACE WG meeting on Friday:

"EDHOC has gone through a Secdispatch process.  A summary message was posted on 
the Secdispatch mailing list [see link below]. For those people who would like 
to see EDHOC done, or who really don't want to get EDHOC done please get on to 
the Secdispatch list and express support or whatever. The current intent is to 
form a WG without going through the BoF process."

https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c


Göran





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

Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

[Göran Selander]

Hi Rene,

There are two things which has a bearing on the topic we try to progress here:

1. assessing that a certain benchmark is relevant for a particular OSCORE 
deployment, and
2. assessing how well a solution performs with respect to the benchmark.

I made an attempt to explain one instance of item 1 – people can look up for 
themselves in [arch] or [0-touch] the protocol flow, the endpoints for the AKE 
(the Pledge and the JRC) and the role of the proxy (as in the Minimal Security 
protocol). This information is sufficient for defining the benchmark we are 
discussing here.

But at the end of the day, it is the users of OSCORE that should evaluate item 
1, in this case the 6tisch WG. And this is what happened at the interim when a 
person active in 6tisch presented the quantification of the benchmark. The 
discussion about status of 6tisch drafts or potential new design requirement 
documents is probably better to have on the 6tisch mailing list than on these 
lists.

Göran

[arch] draft-ietf-6tisch-architecture-20
[0-touch] draft-ietf-6tisch-dtsecurity-zerotouch-join-03, section 2.4-2.5


From: Rene Struik 
Date: Monday, 18 March 2019 at 15:15
To: Göran Selander , John Mattsson 

Cc: "secdispa...@ietf.org" , 'Benjamin Kaduk' 
, "ace@ietf.org" 
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC 
standardization

Hi Goran:

Unfortunately, it is not clear at all. Details matter: one cannot simply wave a 
magic wand ("not yet defined, but is expected to", etc, etc.).

I am not a big believer in protocol design by email exchange. Security protocol 
design is hard, as is also evidenced by the document history of [1], where the 
initial document was produced in Sep 2016, adopted as WG document in Nov 2016, 
relabeled as another WG document sprout in Sep 2017 ... and now it is March 
2019. Doesn't protocol design start on a white board, where one has an initial 
idea and then systematically work through issues, revisits assumptions, etc., 
rather than produce documents and then write the rationale after the fact?

I do not understand the current flurry of emails to push a particular design 
through: why not first coming up with a design requirements document that goes 
further than "byte-count" arguments?

One can do more analysis in the prelude to Montreal, but this is only 
meaningful if one does not cast things in concrete first and then ask for 
feedback, with some external "clients" (including the 6tisch use case that I 
questioned) as motivation. I do understand the motivation to claim a stake, but 
if intention is to reach a billion+ devices, I think the bar should be really 
high.

Ref: [1] 
https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/

[excerpt of what you wrote below]
6TiSCH minimal security [4] specifies how a Pledge joining a new network 
communicates using CoAP with the JRC via a Join Proxy and over additional hops. 
The proxy operations in the Join Proxy incurs certain overhead in the 
communication between Proxy and JRC. The exact procedure for the zero-touch is 
not yet defined, but it is expected to reuse features of the Join Proxy in the 
minimal security setting. The benchmark in [2] is based on this setting but 
replacing the OSCORE protection of CoAP with the AKE protocol messages carried 
over CoAP. Is it more clear now?

On 3/18/2019 6:08 AM, Göran Selander wrote:
Hi Rene,

Sorry for slow response to your mails.

From: Rene Struik mailto:rstruik@gmail.com>>
Date: Friday, 15 March 2019 at 15:28
To: Göran Selander 
mailto:goran.selan...@ericsson.com>>, John 
Mattsson mailto:john.matts...@ericsson.com>>
Cc: "secdispa...@ietf.org<mailto:secdispa...@ietf.org>" 
mailto:secdispa...@ietf.org>>, 'Benjamin Kaduk' 
mailto:ka...@mit.edu>>, "ace@ietf.org<mailto:ace@ietf.org>" 
mailto:ace@ietf.org>>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC 
standardization

Hi Goran:

As you recall, I suggested to look at some details of 6TiSCH enrollment (see my 
message of March 4, 2019 [1]). During the SecDispatch interim of March 5, 2019, 
this was provided as one use case scenario [2] and reiterated in your email of 
yesterday, March 14, 2019 [3]. Nevertheless, details on how this could be 
realized in practice are still missing.

I had another look at the 6TiSCH minimal security draft [1] (now in 2nd WGLC) 
and the "zero-touch" write-up [5] -- which you both referenced in your email 
[3] of yesterday.

To my understanding, the intention with 6TiSCH is to reuse the protocol flows 
of [4] to implement a public-key based enrollment scheme in the future. This 
seems to be what [5] aims for, if I try and read in between the [still 
unwritten] lines, and the impression I got from some people. From looking at 
the protocol details, though, I do not understand how this can be done in

Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

[Göran Selander]

Hi Rene,

Sorry for slow response to your mails.

From: Rene Struik mailto:rstruik@gmail.com>>
Date: Friday, 15 March 2019 at 15:28
To: Göran Selander 
mailto:goran.selan...@ericsson.com>>, John 
Mattsson mailto:john.matts...@ericsson.com>>
Cc: "secdispa...@ietf.org<mailto:secdispa...@ietf.org>" 
mailto:secdispa...@ietf.org>>, 'Benjamin Kaduk' 
mailto:ka...@mit.edu>>, "ace@ietf.org<mailto:ace@ietf.org>" 
mailto:ace@ietf.org>>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC 
standardization

Hi Goran:

As you recall, I suggested to look at some details of 6TiSCH enrollment (see my 
message of March 4, 2019 [1]). During the SecDispatch interim of March 5, 2019, 
this was provided as one use case scenario [2] and reiterated in your email of 
yesterday, March 14, 2019 [3]. Nevertheless, details on how this could be 
realized in practice are still missing.

I had another look at the 6TiSCH minimal security draft [1] (now in 2nd WGLC) 
and the "zero-touch" write-up [5] -- which you both referenced in your email 
[3] of yesterday.

To my understanding, the intention with 6TiSCH is to reuse the protocol flows 
of [4] to implement a public-key based enrollment scheme in the future. This 
seems to be what [5] aims for, if I try and read in between the [still 
unwritten] lines, and the impression I got from some people. From looking at 
the protocol details, though, I do not understand how this can be done in 
practice. This begs the question what I am missing here.

Hence, my question of March 4th on details of use case scenarios still stands. 
In fact, I do not see how one could implement EDHOC on top of [4], even if one 
only uses symmetric-key only variant of EDHOC.

If you could shed some light on this, this would help. Or, should we simply 
abandon that use case as being unrealistic at this point?

6TiSCH minimal security [4] specifies how a Pledge joining a new network 
communicates using CoAP with the JRC via a Join Proxy and over additional hops. 
The proxy operations in the Join Proxy incurs certain overhead in the 
communication between Proxy and JRC. The exact procedure for the zero-touch is 
not yet defined, but it is expected to reuse features of the Join Proxy in the 
minimal security setting. The benchmark in [2] is based on this setting but 
replacing the OSCORE protection of CoAP with the AKE protocol messages carried 
over CoAP. Is it more clear now?

Finally, your email [1] suggests "reports of massive breaches with PSK 
provisioning systems". If so, I would strongly suggest having another look at 
[4] and commenting on this.

I’m not sure exactly what you want me to comment on. Clearly there are weakness 
with PSK based systems w/o PFS. But PSK w/o PFS is still used for various 
reasons, including inability to deploy better security. This inability may be 
real due to performance limitations or only perceived, for example due to 
unawareness of intermediary provisioning schemes between PSK and certificates, 
but in any case PSK w/o PFS is clearly a better alternative than no security at 
all. One purpose of the work we discuss here is to lower the threshold for PFS.

You mentioned in a previous mail other limitations in the multi-hop setting 
besides message sizes, and that is indeed true - this is just one benchmark. Is 
there some specific characteristic you want to highlight in this context?

RS>> My 10-hop enrollment use case was aimed to force consideration of
not just abstract "protocol flow arrows", but also effects on the
network and its actors. A simple byte-count is not enough...
<https://mailarchive.ietf.org/arch/msg/ace/On0iIFAb_OWeBqLjlryi1rBHwhk
[2] Slides on EDHOC during SecDispatch meeting of March 5, 2019. 
Seehttps://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
[3] Pitch for EDHOC, email Goran Selander of March 14, 2019. 
Seehttps://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
[4] draft-ietf-6tisch-minimal-security-09
[5] draft-ietf-6tisch-dtsecurity-zerotouch-join-03



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

Re: [Ace] FW: WGLC comments on draft-ietf-ace-dtls-authorize

[Göran Selander]

Hi Jim,

Thanks for comments. 

On 2019-03-03, 02:44, "Jim Schaad"  wrote:

I am responding to the review below in regards to the most recent version 
-06.

> -Original Message-
> > Section 3.3 - Figure 4 - Where is the 'alg' parameter defined at 
that level?
> 
> See next comment.
> 
> [GS]  alg parameter included
> 
> > Section 3.3 - I am always bothered by the fact that PSK should 
really be
> PSS
> > at this point.  The secret value is no longer a key and thus does 
not
> > necessarily have a length.  There is also a problem of trying to 
decide
> what
> > the length of this value would be based on the algorithm.  If the 
client
> > offers TLS_PSK_WITH_AES_128_CCM_8 and
> TLS_PSK_WITH_AES_256_CCM_8  (I may
> > have gotten these wrong but the intent should be understandable) 
then
> what
> > length is the PSK supposed to be?
> 
> I think what you are saying is that for the shared secret (k) in the
> COSE_Key structure in Fig. 4, the AS needs to tell C what to do with
> that shared secret? This was the intention of the alg parameter (which
> has a not-so-useful value in this example).

Some of what is done here makes sense and some of it makes no sense at all.

Happy with the removal of the "alg" parameter in the root map.  

Happy with the addition of the kid parameter in the COSE_Key object since 
this is required for doing DTLS w/o sending the token as the identifier.

I have no idea what the algorithm is doing here?  This is not currently a 
COSE algorithm, it is a TLS algorithm and thus would not make a great deal of 
sense.  

GS: I admit this does not make sense, neither here nor in Fig. 6.

The terms of what the PSK length should be would be better covered by a 
statement along the lines of "When offering and/or accepting a TLS 
cryptographic suite, the length of the PSK should be at least as long as the 
symmetric encryption algorithms that are offered." This may already be pointed 
to in the TLS documents and thus can be referenced to rather than stated 
explicitly.

GS: 
1. If the PSK is not uniformly random, the security level is not given by the 
length. I note in the ACE framework: "The AS generates a random symmetric PoP 
key." Perhaps we should add 'uniform' to this text?

2. About the proposed text, how about making it into a consideration: "Note 
that the security level depends both of the length of PSK and the security of 
the TLS cipher suite and key exchange algorithm." I didn't find any text in TLS 
that I could reference.

When looking at the KDF option that you are providing.  I don't understand 
why you don't just make the KDF function and the length of the secret to be 
derived as pre-configured properties.  There is absolutely nothing that 
prevents this from being a 141 byte value.  

GS: I'm not sure exactly what is requested. 
* HKDF-SHA-256 is mentioned as an example of a KDF, indeed this entire part of 
the section is an example. Do you want to remove the example using 
COSE_KDF_Context entirely, or just assume that selected components are 
preconfigured.
* I agree that keyDataLength is restrictive, should we replace that with a 
consideration on security levels, like the text on PSK above?


I am not seeing anything in the security considerations about protecting 
this secret and what all will be available to an attacker in the event that 
this secret is leaked.  Specifically, it allows for any previously recorded 
session to be decrypted if the KID is leaked, such as using the KID as the key 
identifier in the handshake protocol rather than sending across the CWT 
(assuming that it is encrypted).  
It will allow for an impersonation attack to occur in the event that the 
KID for a client in the event that the KID is leaked as the attacker would be 
able to create the same token that is passed to the client.

GS: I agree that a security consideration about protecting the key derivation 
key is needed. But this is another key shared between AS and RS, wouldn't the 
security considerations be similar? I don't understand what is the meaning of 
"KID is leaked".



> 
> > Section 3.3 - Figure 5 - Is this defining a new set of entries for 
cnf or is
> > there a missing layer someplace?
> 
> This is indeed a new set of entries. An internal discussion between 
the
> draft authors led to the opinion that we cannot use a COSE_Key 
structure
> in the cnf structure as this would have different semantics as 
intended
> here. We came to the conclusion that for key derivation, listing the
> required fields directly in the cnf structure is the cleanest 
solution.
> 
> [GS] new layer added, called ACE_Salt.

This does not seem to be what was implemented in the current draft.

GS: The example in s

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Valery,

On 2019-02-19, 19:02, "Valery Smyslov"  wrote:

> When done over CoAP, the message would be sent with CONfirmable, so it
> would be ACK'ed.  I would make the first message CONfirmable too.
> 
> That makes it much like IKEv2 is, where all messages are ACKed and the
> initiator is responsible for all retransmits.

Sure, there must be no problems with COAP or other reliable transport.

> If someone wants to run EDHOC over another transport, then they would
> need to take this into account.

That was my point.

Thanks, we will include a consideration about this.

Best regards
Göran


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

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Valery,

On 2019-02-18, 08:07, "Valery Smyslov"  wrote:

Hi,

> Richard Barnes  wrote:
> > Finally, to be totally honest, I find the EDHOC spec pretty 
inscrutable. A
> > little more prose to explain what's going on would go a long way 
toward
> > helping this discussion be productive.
> 
> Sure.
> Find a WG to adopt it, and we can make the text beautiful.
> The packets are all there, and the references pretty much explain all the 
crypto.
> This stuff is not any newer than IKEv2.

I have only a quick look over the draft, but one thing strikes me - the 
protocol 
is claimed not to bound to a particular transport (so I assume that 
implementing
it on top of pure UDP is fine), and it has an odd number of messages.
That's OK from cryptographic point of view, but it's a headache for 
implementations if the transport protocol is unreliable, since in this case 
retransmissions 
must be sent by both parties. We learned this lesson from IKEv1 (Aggressive 
and Quick modes) 
and in IKEv2 the number of messages in any exchange is always even, 
that simplifies implementations and makes protocol more reliable.
Of course if only reliable transports are considered, then this doesn't 
matter.


Current version of EDHOC is 3-pass to allow traffic data after one round trip, 
which reduces latency in many applications. 
A 4-pass version has also been discussed: 
https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ

When EDHOC is used as key exchange for OSCORE, and also in other settings, 
EDHOC will commonly run on top of CoAP. For example, in 6tisch the join 
protocol relies on CoAP proxy functionality. CoAP is defined for reliable 
transport (RFC 8323) as well as UDP (RFC 7252), the latter handles 
retransmissions by client and server. An example of using EDHOC with CoAP is 
given in appendix D.1:
 https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1

It sounds like we should add some considerations for the setting you outline. 
Do you have an example or pointer explaining the specific problem in more 
detail? 

Thanks,
Göran


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

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Michael,

On 2019-02-18, 02:35, "Ace on behalf of Michael Richardson" 
 wrote:

Richard Barnes  wrote:
> Finally, to be totally honest, I find the EDHOC spec pretty 
inscrutable. A
> little more prose to explain what's going on would go a long way 
toward
> helping this discussion be productive.

Sure.
Find a WG to adopt it, and we can make the text beautiful.

I believe this is what the SecDispatch chairs are considering. I know of others 
sharing your impatience too.

The packets are all there, and the references pretty much explain all the 
crypto.
This stuff is not any newer than IKEv2.
   
EDHOC is neither TLS 1.3 nor IKEv2. The similarity with other AKEs comes from 
being based on same SIGMA protocol. Current version of EDHOC is based on 
Sigma-I, but the Sigma-R version discussed in a parallel thread is similar to 
IKEv2:
https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ


Göran


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

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Richard,

From: Richard Barnes 
Date: Friday, 15 February 2019 at 17:19
To: Göran Selander 
Cc: "secdispa...@ietf.org" , "ace@ietf.org" 
Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports



On Fri, Feb 15, 2019 at 7:13 AM Göran Selander 
mailto:goran.selan...@ericsson.com>> wrote:
Hi Richard,

Thanks, that is a fair question to ask on behalf of those who are new to the 
subject.

The short answer is: Yes, we have counted every byte of the TLS handshake and, 
no, we don’t think it is possible to support the same radio technologies as 
EDHOC do, unless you change some assumption which impacts the security analysis 
of TLS.

This is the part that worries me.  It would be helpful to be very crisp about 
what assumptions are being changed here, and why it's OK for them to be 
changed.  Especially given that the Bruni et al. paper seems to have found 
flaws. Your point about CBOR isn't relevant here.  Re-encoding is fine; it's 
changing the AKE that necessitates a whole bunch of new analysis.

Perhaps I was unclear: We are not proposing any changes to (D)TLS 1.3. We 
believe that making (D)TLS 1.3 AKE fit into small frames requires changing some 
assumption of the protocol which, as you say, would necessitate a new analysis 
of TLS. The point about reencoding is about inefficiency or incompatibility, 
which are both relevant for the overall discussion, but not about security.

The paper you mention analyzed version -08 of EDHOC and, essentially, the 
expected security properties hold. All comments from this analysis are 
addressed in the updated version of the protocol. Section 4 of the paper 
describes the security properties. Their main concern was related to the 
application data sent by party V in message #2 (APP_2 in -08) being encrypted, 
which may mislead application developers that it is protected for the intended 
party U, but party U is not authenticated at the time of sending message #2. 
Later versions of the draft emphasize how to handle data which is not protected 
(see Section 8.4 in -11) and the APP_2 message field is renamed UAD_2 
(Unprotected Application Data).

Finally, to be totally honest, I find the EDHOC spec pretty inscrutable.  A 
little more prose to explain what's going on would go a long way toward helping 
this discussion be productive.

What part of the draft did you find difficult to understand?

Göran




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

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Richard,

Thanks, that is a fair question to ask on behalf of those who are new to the 
subject.

The short answer is: Yes, we have counted every byte of the TLS handshake and, 
no, we don’t think it is possible to support the same radio technologies as 
EDHOC do, unless you change some assumption which impacts the security analysis 
of TLS.

The longer answer is embedded in the previous mails, for convenience I 
reiterate some of the items.


  1.  A property like energy consumption is not binary, but the smaller the 
message overhead the better, primarily because it makes the messages fit into 
smaller frame sizes but also because of per byte power consumption which is 
noticeable in some radio technologies. Fitting into frame size means avoiding a 
step up in power consumption due to transmission overhead not related to the 
payload, and also having fewer packets that may be corrupted and result in 
retransmission with additional power consumption. For example, LoRaWAN has a 
packet size for DR0-2 (51 bytes, in practice a few bytes less), in which we can 
fit all messages with EDHOC PSK ECHDE. While EDHOC messages are small, we 
certainly would welcome an even smaller handshake with the same functionality 
to better handle other radio technologies and fragmentation schemes with even 
smaller frame sizes, but we’re not interested in something less optimal.


  1.  As Hannes and I agree, this is not only about message overhead. Memory 
and code size in a device are also important, specifically what is added on top 
of CoAP and OSCORE, which are already implemented in the targeted device. This 
is the reason why EDHOC builds on CBOR and certain COSE objects. Downsizing an 
existing protocol still means new code is needed, as using a subset of the 
protocol does not decrease the size of existing implementations. Furthermore, 
changing encoding may lead to incompatible handshake message formats: Over what 
are signatures made; the original encoding or the compact? If the original, 
then the constrained device must re-encode in order to verify the signature, 
which adds even more to memory and flash. If the signature is on the compact 
encoding, then it is not backwards compatible with since legacy implementations 
cannot verify. In either case a major point with profiling is lost.


  1.  As a final point for people entering the discussion late, this is not a 
draft coming out of the blue; there is a history to consider. After the first 
in-room rough consensus for adoption in ACE at IETF 98 
https://datatracker.ietf.org/doc/minutes-98-ace/ the progress of EDHOC went 
into offline mode, during which the authors were tasked to work on formal 
verification (see below) and make comparison with TLS handshake. We showed that 
there are significant differences in overhead: 
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-E.4

We have also shown that these differences have an impact on energy consumption 
and latency, and on what radio technologies can be supported (see below in this 
mail). These properties are the results of having constrained IoT as an 
explicit target for the protocol. As this was not the case for the TLS 
handshake it should not come as a surprise that it may be difficult to retrofit 
without changing some basic assumptions used in the security analysis, like 
removing the nonces. We are happy to deploy the result of an optimized DTLS but 
we don’t think it is fair that such work should hold up the progress of this 
draft any longer.

As for the formal verification, we were fortunate that the IT University of 
Copenhagen volunteered and has now proved properties like injective agreement, 
secrecy and forward secrecy to be discussed more in the interim meeting. An 
analysis of a previous version of the draft is here:
https://www.springerprofessional.de/en/formal-verification-of-ephemeral-diffie-hellman-over-cose-edhoc/16284348
(a link to the paper will be available in the agenda)

We are aware of that more security analysis is needed, but would like to think 
that the properties listed above are good enough for adoption. That is also one 
factor that would significantly increase the motivation for people to make 
further analysis of the security of EDHOC.


Göran


From: Richard Barnes 
Date: Thursday, 14 February 2019 at 16:42
To: Göran Selander 
Cc: Hannes Tschofenig , "secdispa...@ietf.org" 
, "ace@ietf.org" 
Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports

Göran: When these metrics talk about DTLS 1.3, do they mean that protocol 
directly, unmodified?

One alternative approach people have had in mind is the idea of re-encoding / 
profiling down DTLS so that although it is syntactically different and maybe 
has fewer options, it encodes the same underlying AKE.  Has that path has been 
explored?

On the one hand, if it succeeds in slimming down DTLS to an acceptable point, 
it would obviate the need for a whole bunch of new analysis.

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Hannes,

On 2019-02-14, 11:50, "Hannes Tschofenig"  wrote:

Hi Göran,

I will obviously not be able to convince you to change your research 
strategy. So, I will not even try.

This is not just a research topic, but if this means that you respect that 
different companies may have different strategies and want to be able to choose 
between solutions with different properties, then I'm grateful for that. Also, 
thanks for the pointers comparing ARM processors.

Göran

Anyway, thanks for the performance measurements your co-workers created in 
the Excel sheets. I will take a closer look at them.

One item worthwhile to respond is the choice of the MCU. You wrote:
[GS] Nice application of LwM2M. The showcased device didn't seem very 
constrained though, ARM Cortex M4?

The Cortex M4 offers a larger instruction set, including DSP/SIMD 
capabilities, compared to something like the M0+. You can see the differences 
at https://en.wikipedia.org/wiki/ARM_Cortex-M
In this blog post, see 
https://community.arm.com/processors/b/blog/posts/armv6-m-vs-armv7-m---unpacking-the-microcontrollers,
 Chris Shore shows the difference in the instruction set graphically.

Using these extra instructions code can be executed faster. This faster 
execution time is already ensured by compilers but if you additionally use 
hand-crafted Assembly code then you will get an extra performance improvement. 
My co-workers from the Mbed TLS team have written hand-crafted Assembly to 
speed up bignum computations, see 
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/bn_mul.h#L645

https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/bn_mul.h#L582

Executing code faster gives the device the ability to enter a low power 
state quicker.

Additionally, if you use sensor fusion then having floating point support 
in hardware will make your life easier (and the code faster).

Ciao
Hannes

-Original Message-----
From: Göran Selander 
Sent: Montag, 4. Februar 2019 18:41
To: Hannes Tschofenig ; secdispa...@ietf.org; 
ace@ietf.org
Subject: Re: [Secdispatch] FW: [secdir] EDHOC and Transports

Hi Hannes, secdispatch, and ace,

(It seems Hannes original mail only went to secdispatch.)

Apologies for a long mail, and late response. I had to ask some people for 
help with calculations, see end of this mail.

On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" 
 wrote:

Fwd to SecDispatch since it was only posted on the SecDir list

-Original Message-
From: Hannes Tschofenig 
Sent: Freitag, 25. Januar 2019 14:07
To: Hannes Tschofenig ; Jim Schaad 
; sec...@ietf.org
Subject: RE: [secdir] EDHOC and Transports

A minor follow-up: I mentioned that I am aware of a company using the 
energy scavenging devices and it turns out that this information is actually 
public and there is even a short video on YouTube. The company we worked with 
is called Alphatronics and here is the video: 
https://www.youtube.com/watch?v=JHpJV_CPYb4

As you can hear in the video we have been using our Mbed OS together 
with our device management solution (LwM2M with DTLS and CoAP) for these types 
of devices.

[GS] Nice application of LwM2M. The showcased device didn't seem very 
constrained though, ARM Cortex M4?

-Original Message-
From: secdir  On Behalf Of Hannes Tschofenig
Sent: Freitag, 25. Januar 2019 13:52
To: Jim Schaad ; sec...@ietf.org
Subject: Re: [secdir] EDHOC and Transports


   [Hannes]  what we are doing here is making an optimization. For some 
(unknown reason) we have focused our attention to the over-the-wire 
transmission overhead (not code size, RAM utilization, or developer usability*).

[GS] Exactly my point, it is not enough with reducing transmission 
overhead. We should also look at additional memory, flash, and configuration 
effort. These parameters are of course implementation dependent but can to some 
extent be inferred by bulk of specification and what pre-existing code can be 
reused.

   [Hannes]  We are doing this optimization mostly based on information 
about what other people tell us rather than based on our experience. The 
problem is that we have too few people with hands-on knowledge and/or 
deployment experience and if they have that experience they may not like to 
talk about it. So, we are stepping around in the dark and mostly perceived 
problems.

[GS] I don't think this rhetoric is very helpful. Who are "us"? The 
co-workers you quote below, are they "us" or the "other people"? The people 
active in 6tisch, lpwan or 6lo who are supporting the work on an optimized key 
exchange, are they "us&

Re: [Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-authz

[Göran Selander]

> 11 feb. 2019 kl. 19:29 skrev Jim Schaad :
> 
> 
> 
>> -Original Message-
>> From: Ace  On Behalf Of Ludwig Seitz
>> Sent: Monday, February 11, 2019 6:23 AM
>> To: ace@ietf.org
>> Subject: [Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-
>> authz
>> 
>> Hello all,
>> 
>> I would like to call the group's attention to this message of mine (it was
>> probably drowned out in the shepherd's review thread):
>> 
>>> On 31/01/2019 10:40, Ludwig Seitz wrote:
>>> Hello,
>>> 
>>> we have an unresolved review comment by Steffi that got lost in the
>>> holiday season:
>>> 
>>> 
>> https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U
>>> 
>> https://mailarchive.ietf.org/arch/msg/ace/NrQWetugoy0TWp9eg3lwtSictc8
>>> 
>>> 
>>> The issue is the following (my words):
>>> 
>>> The AS provides the client with key material used by the RS. This can
>>> either be a common symmetric pop-key, or an asymmetric key used by the
>>> RS to authenticate towards the client.
>>> 
>>> Since there is (currently) no metadata associated to those keys, the
>>> client has no way of knowing if these keys are still valid. This may
>>> lead to situations where the client sends requests containing
>>> sensitive information to the RS using a key that is expired and
>>> possibly in the hands of an attacker, or accepts responses from the RS
>>> that are not properly protected and could possibly have been forged by an
>> attacker.
>>> 
>>> 
>>> The options to resolve this that I currently see are this:
>>> 
>>> 
>>> 1. If the client has no additional data it MUST assume that the key is
>>> valid as long as the access token together with which it received that
>>> key. Since the access token is opaque to the client, the client MUST
>>> now determine how long the token is valid:
>>> 
>>> Option 1.1 The client is provisioned in advance with a default
>>> validity time for tokens issued by the AS. This could be done when the
>>> client is registered at the AS.
>>> 
>>> Option 1.2 The AS informs the client using the "expires_in" parameter
>>> in the Access Information.
>>> 
>>> This means that we need to implement a check whether the client knows
>>> a default validity, and if that is not the case reject an access token
>>> that does not come together with an "expires_in" parameter.
> 
> This is my personal preference.  Telling the client that the RS key expires 
> in a long time is only reasonable if you are planning to do client anonymous 
> TLS connections.  It also has the problem that you no longer have a way to 
> revoke that key.
> 

+1

Reusing ”expires_in” seems like a good solution. 

Göran


> Jim
> 
>>> 
>>> 2. We can define a new parameter that informs the client specifically
>>> about the validity of the keys the RS uses, if that differs from the
>>> validity of the token. Note that this is a realistic use case, since
>>> the RS might use an asymmetric key for authentication that is valid
>>> for a significantly longer period than some access token.
>>> 
>>> 
>>> I would need some feed-back from the group to proceed here.
>>> 
>>> /Ludwig
>>> 
>> 
>> 
>> /Ludwig
>> 
>> --
>> 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


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

Re: [Ace] [Secdispatch] FW: [secdir] EDHOC and Transports

[Göran Selander]

Hi Hannes, secdispatch, and ace,

(It seems Hannes original mail only went to secdispatch.)

Apologies for a long mail, and late response. I had to ask some people for help 
with calculations, see end of this mail.

On 2019-01-25, 15:15, "Secdispatch on behalf of Hannes Tschofenig" 
 wrote:

Fwd to SecDispatch since it was only posted on the SecDir list

-Original Message-
From: Hannes Tschofenig 
Sent: Freitag, 25. Januar 2019 14:07
To: Hannes Tschofenig ; Jim Schaad 
; sec...@ietf.org
Subject: RE: [secdir] EDHOC and Transports

A minor follow-up: I mentioned that I am aware of a company using the 
energy scavenging devices and it turns out that this information is actually 
public and there is even a short video on YouTube. The company we worked with 
is called Alphatronics and here is the video: 
https://www.youtube.com/watch?v=JHpJV_CPYb4

As you can hear in the video we have been using our Mbed OS together with 
our device management solution (LwM2M with DTLS and CoAP) for these types of 
devices.

[GS] Nice application of LwM2M. The showcased device didn't seem very 
constrained though, ARM Cortex M4? 

-Original Message-
From: secdir  On Behalf Of Hannes Tschofenig
Sent: Freitag, 25. Januar 2019 13:52
To: Jim Schaad ; sec...@ietf.org
Subject: Re: [secdir] EDHOC and Transports


   [Hannes]  what we are doing here is making an optimization. For some 
(unknown reason) we have focused our attention to the over-the-wire 
transmission overhead (not code size, RAM utilization, or developer 
usability*). 

[GS] Exactly my point, it is not enough with reducing transmission overhead. We 
should also look at additional memory, flash, and configuration effort. These 
parameters are of course implementation dependent but can to some extent be 
inferred by bulk of specification and what pre-existing code can be reused.

   [Hannes]  We are doing this optimization mostly based on information about 
what other people tell us rather than based on our experience. The problem is 
that we have too few people with hands-on knowledge and/or deployment 
experience and if they have that experience they may not like to talk about it. 
So, we are stepping around in the dark and mostly perceived problems.

[GS] I don't think this rhetoric is very helpful. Who are "us"? The co-workers 
you quote below, are they "us" or the "other people"? The people active in 
6tisch, lpwan or 6lo who are supporting the work on an optimized key exchange, 
are they "us" or the "other people"?


   [Hannes]  Having said that I would like to provide a few remarks to your 
list below:

  [Jim]   1.  Low-power devices that either are battery based or scavenge 
power, these devices pay a power penalty for every byte of data sent and thus 
have a desire for the smallest messages possible.

[Hannes] Low power is a very complex topic since it is a system issue and 
boiling it down to the transmission overhead of every byte is an 
oversimplification. You are making certain assumptions of how power consumption 
of radio technologies work, which will be hard to verify. I have been working 
on power measurements recently (but only focused on power measurements of 
crypto, see 
https://community.arm.com/arm-research/b/articles/posts/testing-crypto-performance-and-power-consumption).
 

[GS] These kind of power measurements of crypto are part of the explanation for 
why transmission overhead is important to reduce. Optimizations and hardware 
support make the crypto contribution to power consumption possible to handle, 
so that there is no reason to deviate from the use of current best practice 
crypto in security protocols even for constrained devices. The energy cost for 
transmission, however, is a strongly coupled to the laws of physics which sets 
a limit for how much they can be optimized.

[Hannes] I doubt that many people on this list nor in the IETF have a lot of 
experience in this field to use this as a basic for an optimization.

[GS] There are people in 6tisch, lpwan and 6lo who knows about power 
consumption and constrained characteristics. Some of them were supporting EDHOC 
in ACE when you were chair.

[Hannes]   My co-workers, who are active in this space, tell me that there is 
nothing like a "per byte" linear relationship (for small quantities of data) in 
terms of energy cost. Obviously if you trigger "an additional transmission", 
which requires you to ramp up a PLL, turn on radio amplifiers, send lengthy 
preambles etc then the incremental cost of sending 64 bytes in that packet vs 
16 bytes might be immeasurable small. The critical thing appears to be how long 
the RF amplifiers are powered on. Hence, you will often see publications that 
tell you that waiting for incoming packets is actually the most expensive task 
(in terms of power consumption).

[GS] Energy consumption generally increases with message overhead in wireless 
sys

Re: [Ace] [Secdispatch] EDHOC

[Göran Selander]

Hi Ben,

I replied to some of your comments in my previous mail to the list. Additional 
comments inline.

On 2019-01-18, 18:27, "Benjamin Kaduk"  wrote:

On Fri, Jan 18, 2019 at 11:54:58AM -0500, Richard Barnes wrote:
> Let me provide some additional context.  When the chairs and ADs 
discussed this in BKK, it seemed pretty clear that EDHOC is not within the 
current charter of ACE — after all, ACE is targeted at authentication and 
authorization, not key exchange.  Since ACE would need to recharter to accept 
this work in any case, and because EDHOC overlapped with the interests of other 
working groups, it seemed to make sense to have the conversation in a broader 
venue.

ACE's charter is ... messy.  More below.

> Göran: Your email starting this thread seems like an abbreviated summary 
of the past discussion of this draft.  Since this is a new audience, it would 
be helpful if you could start from the underlying requirements (“we need an AKE 
with certain constraints”) and lay out why new protocol work is needed, vs. 
profiling existing protocols (as has been done, e.g., in DICE).


There seem to be several interleaved issues at play, here, and I agree that
some clear/consolidated background would be helpful.  I particularly call
out the security proof that has been presented elsewhere, which I think
would be interesting to several readers (but I don't have the link handy).

Referenced in Roman's previous mail to secdispatch. I agree that asserting the 
formal security properties is key.

Some thoughts of my own...

There is clear demand for a lightweight key-exchange protocol for use in
IoT protocols, especially OSCORE.  EDHOC has been around for a while, and
even discussed in ACE with some frequency.  That said, there are several
reasons to prefer asking secdispatch to just calling for adoption in ACE
directly, including but not limited to:

(a) designing secure authenticated key exchange protocols is hard!  It takes
a lot of energy from smart people to design and analyze a protocol to have
confidence that it is secure and fulfils the advertised functions.
Starting from well-known/well-analyzed foundations like SIGMA is a great
start, but hardly a guarantee of success.  Secdispatch gets us some better
visibility, and insight into where work can be done that will have
sufficient expertise (both within and outside the IETF, as well as what has
been done already vs. what remains to be done) to be confident in the
result.

This sounds like an excellent support function. Thanks.

(b) ACE has a pretty complicated charter, that seems to place restrictions
on how it can adopt new protocol work without rechartering.  We find things
in the charter like "existing authentication and authorization protocols
will be evaluated and used where applicable [...].  Some functionality,
however, may not be available in existing protocols, in which case the
solution may involve new protocol work."  This would seem to require a
clear criteria for how to determine whether or not existing technology is
applicable, plus evidence that existing protocols do not meet the bar.  In
particular, "make the key exchange messages as small as possible" is not a
clear criterion, as that would always argue for a new protocol over an
existing one, as we come up with new ways to eke out space.

I don't know how important it is to fit into the existing ACE charter but the 
comparison between EDHOC and TLS/DTLS handshake showed a reduction in message 
overhead with up to 75%, which can be translated into power consumption. I 
would say that "power efficient key exchange" is functionality not available in 
the existing protocols we looked at.

(c) A clear and substantial difference between key exchange/handshake size
between EDHOC and even minimized DLTS could be compelling enough for
secdispatch to decide that the work is usable, and find an appropriate
home, independently of the question of rechartering ACE and meeting the
additional barrier described in the previous point.

The WG is not crucial, but involvement from the user community is valuable as 
well as the security expertise. 

Jim and several others have done some good work looking into tabulating
message overheads in various scenarios (e.g.,
https://www.diva-portal.org/smash/get/diva2:1156483/FULLTEXT01.pdf,

https://jimsch.github.io/randomDrafts/draft-schaad-ace-tls-cbor-handshake.html)
that will be helpful as we consider this topic.

In addition to just comparing the byte count for handshake/key exhchange
messages in various methods, it would probably also be good to think about
things in terms of the constraints in the current ACE charter.  That is,
someone could (1) pick a (class of) device(s), (2) show that it has wide
deployment/potential

Re: [Ace] [Secdispatch] EDHOC

[Göran Selander]

Hi Richard, Roman, all


Thanks for kind welcome and for progressing the discussion. Apologies for a 
long email.

From: Richard Barnes 


Summing up where I believe the conversation stands now, it seems like what 
folks are asking for is either:


  1.  An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., 
IKE or TLS), or

2. An argument that a new AKE is necessary (vs. a re-encoding of an existing 
AKE)

Göran et al: Do you have thoughts on those points?

Yes. I’ll get back to this later in this email.

It seems like it could be a productive use of an hour or two of virtual interim 
time to help the group understand one of those lines of argument.

Agree.

--Richard


As requested in a previous email, here is a background.



The work on EDHOC is motivated by the need for an authentication and key 
exchange protocol for OSCORE (draft-ietf-core-object-security) optimized for 
constrained-node networks (RFC 7228). OSCORE is applied within the IETF, e.g. 
in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security), but also 
requested by other SDOs and industry fora such as OMA Specworks, Open 
Connectivity Foundation and Fairhair Alliance. The properties of OSCORE 
motivating its use include: support for CoAP forward proxies, support for 
change of underlying transports including non-IP, low overhead, low additional 
footprint and memory to existing CoAP implementations, support for multicast 
security, security for end-to-end REST.



Given the large interest in OSCORE already before it has become an RFC we 
anticipate a wide range of deployments. For example, we see an interest for 
OSCORE in Cellular IoT with traffic running over the cellular air interface 
control channel, where we can have end-to-end CoAP, but not necessarily 
end-to-end IP between an application server and a cellular device. Or between 
an application server and a device behind a cellular gateway. Comparing just 
these two cases, the difference in capabilities of the devices can be 
significant which makes it difficult to point at some sort of “reference 
devices” for benchmarking.



In order to support the low end use cases the AKE must be performant in low 
bandwidth deployments with battery powered devices restricted in RAM and ROM. 
Message sizes and round trips have a direct impact on latency, power 
consumption and battery lifetime, and can be calculated which is the reason for 
this being a commonly used metric. While it may be more difficult to compare 
memory and storage requirements, the ability to reuse existing code is an 
important indication. If a device can support a CoAP stack (in the sense of 
memory and flash, etc) it is expected to also be able to support OSCORE. 
Similarly, it is desirable that a device with CoAP and OSCORE implemented 
should be able to support an additional AKE. Considering that EDHOC reuses CBOR 
and COSE primitives from OSCORE the additional code for EDHOC can be very 
limited.



From a security point of view OSCORE requires that the endpoints have agreed on 
a Master Secret with a good amount of randomness, and each other’s Sender IDs, 
and those must be different for a given Master Secret.



Now returning to the questions.


  1.  An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., 
IKE or TLS)


Considering EDHOC is a new protocol it should be thoroughly analysed and 
verified against all currently known issues of AKEs. Roman sent a mail to the 
secdispatch list referencing a paper presented at SSR 2018 which could be used 
as a starting point. How do folks want to digest this: Do they want to study 
the model themselves or should we ask the authors if they could present their 
work at the interim?

2. An argument that a new AKE is necessary (vs. a re-encoding of an existing 
AKE)



We have done this comparison with TLS/DTLS for some time now, and what once 
seemed like a reasonable question has turned out to be never ending exercise. I 
do not want to get into IETF archeology but for those who have not followed the 
discussion some data points could be relevant.



Not long ago, the design of security protocols did not take into account 
constrained IoT devices. With OSCORE we showed that the message overhead could 
be reduced by a factor 3 compared to DTLS 1.2 records. Before this comparison 
it was believed that the record layer was performing well, then the difference 
in overhead was characterized as insignificant, and then finally a compact 
format was designed for DTLS 1.3.



With EDHOC we showed that the message overhead of the key exchange can be 
reduced with up to a factor 4 compared to the current version of DTLS 1.3 (see 
Appendix E in EDHOC). Before this exercise it was believed that the TLS/DTLS 
handshake was performing well, then the difference in overhead was 
characterized as insignificant, and now the discussion has shifted to 
downsizing the TLS handshake or other protocol.



We are not against optimizations to the TL

Re: [Ace] [Secdispatch] EDHOC

[Göran Selander]

Hi Kathleen,

Good question. Thanks for bringing continuity to this almost 2 years long 
offline discussion. Indeed, lack of comparison with other protocols and formal 
verification were at the time the arguments for not following up the in-room 
consensus with an email confirmation. And, as you noted, that is not the case 
anymore.

Meanwhile the ACE chairs and AD have changed. My understanding is that the 
argument now is about attracting more people with a certain security competence 
for which perhaps another WG could potentially be better, hence the request to 
Secdispatch. But I'll pass the question on and include the ACE WG for 
transparency.

From the authors' humble point of view we believe that the main missing thing 
that would enable the required further discussion is that the IETF endorses 
this work, no matter how, so that people dare invest more time in 
implementation and analysis. 

Best regards,
Göran


On 2019-01-03, 00:58, "Kathleen Moriarty"  
wrote:

Hi,

I’ve read earlier versions of this draft and appreciate all the work you 
have done with the security proof and comparing to existing standardized 
protocols.  If ACE is interested, why is this going to SECDispatch? It might 
help to understand that better.  Is it that a recharter would be needed?

Thank you & happy new year!
Kathleen 

Sent from my mobile device

> On Jan 2, 2019, at 5:56 PM, Göran Selander  
wrote:
> 
> Dear Secdispatch,
> 
> We have been advised to ask secdispatch to consider EDHOC: 
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe
> 
> Those that follow the ACE WG should be familiar with this draft. The 
problem statement and motivation for EDHOC is described in section 1. In brief, 
the target is a lightweight key exchange protocol suitable for IoT 
applications, which:
> a) has small message size and reuses existing IoT primitives to enable 
low overhead and small code footprint; 
> b) is not bound to a particular transport, to enable end-to-end security 
in IoT deployments with varying underlying layers; and
> c) can be used to key OSCORE (draft-ietf-core-object-security) that is 
lacking a harmonizing key exchange protocol.
> 
> These requirements are motivated by constrained IoT device deployments, 
but the protocol is applicable to other end-to-end security settings where the 
overhead due to security needs to be low. EDHOC addresses these requirements 
and builds on the SIGMA construction for Diffie-Hellman key exchanges. EDHOC, 
like OSCORE, is built on CBOR (RFC 7049) and COSE (RFC 8152) and the protocol 
messages may be transported with CoAP (RFC 7252).  
> 
> There has been a number of reviews of different versions of the draft; 
both by people who want to deploy it and by people analysing the security. A 
formal verification was presented at SSR 2018. There are a few implementations 
of different versions of the draft. The ACE WG has expressed interest in this 
work in several f2f meetings.
> 
> Please let us know if some information is missing for secdispatch to 
consider this draft, or how we can help out in the process.
> 
> Best regards
> Göran, John, Francesca
> 
> 
> ___
> Secdispatch mailing list
> secdispa...@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch


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

Re: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining

[Göran Selander]

+1

Göran

From: Ace  on behalf of "Wouter van der Beek (wovander)" 

Date: Friday, 7 December 2018 at 17:38
To: "ace@ietf.org" 
Subject: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining

Hi

+1
This is needed to overcome the current industry issue not having a secure 
multicast mechanism.


Kind Regards,
Wouter van der Beek
Technical Steering Committee Chair
Open connectivity foundation
https://openconnectivity.org/

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

Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm

[Göran Selander]

I support adoption. This draft is a component in the group key management 
solution requested by different industry consortia.

Göran

From: Ace  on behalf of Peter van der Stok 

Organization: vanderstok consultancy
Reply-To: "consulta...@vanderstok.org" 
Date: Thursday, 6 December 2018 at 10:39
To: Roman Danyliw 
Cc: "ace@ietf.org" 
Subject: Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm

I support the adoption of this draft.
It is the right solution to our secure group communication wishes.

Peter

Roman Danyliw schreef op 2018-11-30 22:58:
Hello!

This is the start of a two week call for input on the WG adoption of the 
document:

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

The document has been presented and discussed at the last few meetings; and 
revisions have been made based on WG feedback.  At the IETF 103 meeting, there 
was support for adoption; and volunteers to review and implement the draft.

Please provide feedback to the list/chairs if you believe that this document 
should be adopted as a WG document.The adoption call will end on December 
14 2018.

Regards,
Roman and 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] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession

[Göran Selander]

Correction!

I am NOT aware of any IPR related to this draft. 


(Thanks Roman for spotting the unfortunate missing words !)

Göran

> 30 nov. 2018 kl. 16:42 skrev Göran Selander :
> 
> 
> I aware of any IPR related to this draft.
> 
> BR
> Göran
> 
> On 2018-11-27, 15:44, "Ace on behalf of Roman Danyliw"  on behalf of r...@cert.org> wrote:
> 
>Hello draft-ietf-ace-cwt-proof-of-possession authors,
>(Hi Mike, Ludwig, Goeran, Samuel and Hannes,)
> 
>As the shepherd for draft-ietf-ace-cwt-proof-of-possession, I'd like to 
> confirm with the authors that all IPR disclosures have occurred per RFC6702:
> 
>--[ shepherd questions ]--
> 
>(7) 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. If not, explain why?
> 
>--[end question]--
> 
>Can you please respond to the list answering this question (e.g., "As a 
> co-author, I don't hold any IPR nor am I aware of any related to this draft").
> 
>Thanks,
>Roman
> 
>___
>Ace mailing list
>Ace@ietf.org
>https://www.ietf.org/mailman/listinfo/ace
> 
> 
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace


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

Re: [Ace] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession

[Göran Selander]

I aware of any IPR related to this draft.

BR
Göran

On 2018-11-27, 15:44, "Ace on behalf of Roman Danyliw"  wrote:

Hello draft-ietf-ace-cwt-proof-of-possession authors,
(Hi Mike, Ludwig, Goeran, Samuel and Hannes,)

As the shepherd for draft-ietf-ace-cwt-proof-of-possession, I'd like to 
confirm with the authors that all IPR disclosures have occurred per RFC6702:

--[ shepherd questions ]--

(7) 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. If not, explain why?

--[end question]--

Can you please respond to the list answering this question (e.g., "As a 
co-author, I don't hold any IPR nor am I aware of any related to this draft").

Thanks,
Roman

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


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

Re: [Ace] EDHOC support

[Göran Selander]

Hello Ben,

Thanks for comments!

On 2018-11-08, 05:56, "Ace on behalf of Damm, Benjamin"  wrote:

Hello ace,

We've done an internal review of EDHOC and support its movement towards
RFC.  A few questions:

* It isn't clear (to us) how EDHOC's message 2 achieves proof of
  possession prior to use. NIST SP-800-56A seems fairly clear that proof
  of possession is required before confirmation of a derived key, but
  message 2 seems to force U to derive and use a key before PoP can be
  done.  A pointer to why this is considered safe would be appreciated.

I'm not sure I understand the concern. Having received message 2, the U can 
verify the signature by V (over e.g. the ephemeral key of U) and thus prove 
that the communicating party possesses the private key. Is it the derivation of 
the encryption key needed to decrypt the signature that is your concern? Note 
that this is by construction of the Sigma-I protocol, see page 19 of
http://webee.technion.ac.il/~hugo/sigma-pdf.pdf

* The requirement to support curve x25519 is an odd one for us because
  our device fleet is using P-256. This is not a request to require
  P-256, but rather, that a required curve is not needed. Instead of a
  MUST I'd like to see this be a SHOULD.

By some Best Common Practice (RFC7696 I think) we have to specify at least one 
algorithm that a mandatory to implement. Curve25519 is superior terms of 
security and performance so that seemed a natural choice  since we have to pick 
one curve. If others have the same problem we could of course have a discussion 
around this.


* Given the spectre of PQC we think providing for some flexibility in
  algorithms a must. We use P-256 today but might use P-384 or other
  higher-order curves tomorrow. Transition periods mandate algorithm
  flexibility.


We definitely want to keep the algorithm negotiation in the protocol. The 
change which is proposed is to move from negotiating individual protocols to 
negotiate cipher suites, which reduces overhead further, and makes the protocol 
even simpler. 

We're looking forward to applying EDHOC/OSCORE to secure end-to-end CoAP
application traffic that is transiting multiple proxies.

Thanks for your support!

Göran


   


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

Re: [Ace] EDHOC standardization

[Göran Selander]

Hi Ben,

On 2018-11-03, 22:16, "Ace on behalf of Benjamin Kaduk"  wrote:

On Sat, Nov 03, 2018 at 05:51:55AM +0700, Michael Richardson wrote:
> 
> John Mattsson  wrote:
> > of negotiation is still needed. The current plan for the next 
version
> > is to introduce cipher suites and to let the cipher suite with 
value 0
> > indicate that algorithms have been negotiated out-of-band.
> 
> I agree with the idea that some common default should be very easy to
> refer to, but I don't like the idea that the gateway has to remember what
> the out-of-band "default" is on a per-device basis.  I would say that we 
need
> at least 0/1, so that we can say that it's the current vs the "new" 
default.
> 
> If you consider the case where the sensor is on very low bandwidth
> connection (I would say LoRaWAN, but I am not well qualified in that 
space).
> The sensor gets visited every two or three years by a technician (if only 
to
> make sure that the sensor is still where it is supposed to be).  While 
there
> new firmware updates are applied, and as a result the algorithm defaults 
are
> updated.  During the cycle, some devices are updated and some are still 
old.

Are you proposing that the management of the 0/1-to-algorithm mapping be
managed on a per-deployment basis or by the IETF?

Michael may give his view, but the authors' proposal is to have a IANA register 
enumerating ciphersuites, and where value 0 is reserved for "pre-established 
ciphersuite". 

BR
Göran


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

[Ace] FW: New Version Notification for draft-selander-ace-cose-ecdhe-09.txt

[Göran Selander]

Dear ACE WG,

We submitted an update of EDHOC before the cutoff. At the surface there
are two main changes in the new version:

- Further reducing the message sizes substantially. An example
illustrating this is given as Appendix D.

- Minor changes following a formal verification of -08 made by the IT
University of Copenhagen.

Comments are most welcome. If there is time on the ACE WG agenda we would
like to give an update.


Göran




On 2018-07-03, 01:06, "internet-dra...@ietf.org"
 wrote:

>
>A new version of I-D, draft-selander-ace-cose-ecdhe-09.txt
>has been successfully submitted by John Mattsson and posted to the
>IETF repository.
>
>Name:  draft-selander-ace-cose-ecdhe
>Revision:  09
>Title: Ephemeral Diffie-Hellman Over COSE (EDHOC)
>Document date: 2018-07-02
>Group: Individual Submission
>Pages: 30
>URL:
>https://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-09.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
>Htmlized:   
>https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-09
>Htmlized:   
>https://datatracker.ietf.org/doc/html/draft-selander-ace-cose-ecdhe
>Diff:   
>https://www.ietf.org/rfcdiff?url2=draft-selander-ace-cose-ecdhe-09
>
>Abstract:
>   This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a
>   compact, and lightweight authenticated Diffie-Hellman key exchange
>   with ephemeral keys that can be used over any layer.  EDHOC messages
>   are encoded with CBOR and COSE, allowing reuse of existing libraries.
>
>  
>
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat
>

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

[Ace] FW: New Version Notification for draft-selander-ace-coap-est-oscore-00.txt

[Göran Selander]

All,
 
We have rewritten the application layer security based certificate
enrolment protocol for constrained devices, replacing
draft-selander-ace-eals.

This new draft, entitled "Protecting EST payloads with OSCORE”
(EST-OSCORE), follows closely EST (RFC 7030) in general and the newly
adopted EST-CoAPs (draft-ietf-ace-coap-est) in particular. The main
difference between EST-OSCORE and EST-CoAPs is that the EST payloads are
protected with OSCORE instead of DTLS (which was the main review comment
at the last ACE interim meeting).

Comments are most welcome. If there is 5 minutes on the ACE agenda I could
present it.

Best regards
Göran


On 2018-03-06 00:00, "internet-dra...@ietf.org" 
wrote:

>
>A new version of I-D, draft-selander-ace-coap-est-oscore-00.txt
>has been successfully submitted by Goeran Selander and posted to the
>IETF repository.
>
>Name:  draft-selander-ace-coap-est-oscore
>Revision:  00
>Title: Protecting EST payloads with OSCORE
>Document date: 2018-03-05
>Group: Individual Submission
>Pages: 9
>URL:
>https://www.ietf.org/internet-drafts/draft-selander-ace-coap-est-oscore-00
>.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-selander-ace-coap-est-oscore/
>Htmlized:   
>https://tools.ietf.org/html/draft-selander-ace-coap-est-oscore-00
>Htmlized:   
>https://datatracker.ietf.org/doc/html/draft-selander-ace-coap-est-oscore-0
>0
>
>
>Abstract:
>   This document specifies public key certificate enrollment procedures
>   protected with application-layer security protocols suitable for
>   Internet of Things (IoT) deployments.  The protocols leverage payload
>   formats defined in Enrolment over Secure Transport (EST) and existing
>   IoT standards including the Constrained Application Protocol (CoAP),
>   Concise Binary Object Representation (CBOR) and the CBOR Object
>   Signing and Encryption (COSE) format.
>
>  
>
>
>
>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] Working group adoption of draft-vanderstok-ace-est

[Göran Selander]

Sorry for being late- I also support adoption of this draft as it is a
natural optimization of EST making use of existing IoT device stacks.

Göran



On 2018-01-30 21:23, "Ace on behalf of Jim Schaad"  wrote:

>This is the start of a two week call for input on the adoption of the WG
>of
>the document draft-vanderstok-ace-est.  The document has been presented at
>the last two meetings and has some significant recent updates to respond
>to
>feedback.  There seemed to be support at the last F2F to adopt.
>
>Please provide feedback to the list/chairs if you believe that this
>document
>should be adopted as a WG document.The adoption call will end on Feb
>13
>2018.
>
>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] Removal of the Client Token from ACE-OAuth draft

[Göran Selander]

Hi Hannes,

The paper you are referring to was the only new data point you included when 
you started this thread. I’m not questioning the correctness of your analysis, 
just saying that we are now taking action without having seen the analysis.

As I replied to you in our discussion here at the OMA meeting the lack of 
authentication from RS to the AS may actually carry over to the Access Token. 
Should we then remove the Access Token as well?

My personal view on this is that we should try to support the use case with 
offline Clients (i.e. which cannot communicate directly with the AS) which does 
not have a previous security association with the RS (e.g. during device 
deployment). This would encompasses the authorization of Client and key 
provisioning to the RS. This is the Access Token. It additionally requires key 
provisioning to the Client, and, if desired, the "authorization" of RS - i.e. 
the conditions under which the Client should actually make the request. How do 
we get that information from the AS to the Client?

Göran




From: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Date: Thursday 8 February 2018 at 10:38
To: Göran Selander 
mailto:goran.selan...@ericsson.com>>, 
"ace@ietf.org<mailto:ace@ietf.org>" mailto:ace@ietf.org>>
Subject: RE: [Ace] Removal of the Client Token from ACE-OAuth draft

Hi Göran,

I haven’t posted the write-up yet since it is a submission to the workshop and 
the papers are currently in review. As mentioned to you at the OMA meeting we 
are currently attending the analysis revealed two issues, namely the lack of 
stated goals (which makes any security analysis challenging) and the lack of 
authentication from the client to the AS.

IMHO it is, however, only a small data point in this discussion.

I believe the more important question is whether there are people in interested 
in this scenario or not. I have started my opinion about this already at 
earlier meetings.

There is also the IPR disclosure that some folks may take into account, which 
was posted to the list: 
https://www.ietf.org/mail-archive/web/ace/current/msg02572.html

Since you have not posted your view on this topic yet you may want to think 
about whether you consider the feature important for Ericsson. If you believe 
it is important then maybe you could, as Carsten suggested, continue working on 
the functionality in an independent document.

If you want to spend your time on it then I would recommend to do two things, 
namely (a) specify what goals the mechanism is supposed to accomplish and (b) 
build it on top of existing authentication and key exchange protocol. The 
latter part is quite easy since lots of research was done on 3-party security 
protocols and there are various protocols that fit the desired message 
communication pattern. This could give higher confidence in the work.

Ciao
Hannes

From: Göran Selander [mailto:goran.selan...@ericsson.com]
Sent: 08 February 2018 09:22
To: Hannes Tschofenig; ace@ietf.org<mailto:ace@ietf.org>
Subject: Re: [Ace] Removal of the Client Token from ACE-OAuth draft

Hi Hannes,

From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Date: Thursday 1 February 2018 at 13:59
To: "ace@ietf.org<mailto:ace@ietf.org>" mailto:ace@ietf.org>>
Subject: [Ace] Removal of the Client Token from ACE-OAuth draft

Hi all,

the Client Token is a new mechanism in the ACE-OAuth that aims to solve a 
scenario where the Client does not have connectivity to the Authorization 
Server to obtain an access token while the Resource Server does.

The solution is therefore for the Client to use the Resource Server to relay 
messages to the Authorization Server.

While this sounds nice it does not follow the OAuth model and we, at ARM, have 
not seen anyone requesting this feature. It is also not fully specified in the 
spec: since I have been doing a formal analysis of this protocol variant for 
the OAuth Security Workshop I had to notice that it is not secure. (I will post 
the paper to the list asap.)

Have you posted this? I couldn’t find it my Inbox.

Göran
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

Re: [Ace] Removal of the Client Token from ACE-OAuth draft

[Göran Selander]

Hi Hannes,

From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Date: Thursday 1 February 2018 at 13:59
To: "ace@ietf.org" mailto:ace@ietf.org>>
Subject: [Ace] Removal of the Client Token from ACE-OAuth draft

Hi all,

the Client Token is a new mechanism in the ACE-OAuth that aims to solve a 
scenario where the Client does not have connectivity to the Authorization 
Server to obtain an access token while the Resource Server does.

The solution is therefore for the Client to use the Resource Server to relay 
messages to the Authorization Server.

While this sounds nice it does not follow the OAuth model and we, at ARM, have 
not seen anyone requesting this feature. It is also not fully specified in the 
spec: since I have been doing a formal analysis of this protocol variant for 
the OAuth Security Workshop I had to notice that it is not secure. (I will post 
the paper to the list asap.)

Have you posted this? I couldn’t find it my Inbox.

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

Re: [Ace] Doodle for ACE virtual interim meeting in Oct

[Göran Selander]

Hi Mike,

Inline

On 2017-09-29 19:25, "Ace on behalf of Michael StJohns"
 wrote:

>On 9/28/2017 1:42 PM, Kathleen Moriarty wrote:
>> Hi Mike,
>>
>> I had specifically reached out to the chairs asking for a virtual
>>interim on the profiles and was surprised by that not being listed.
>>This was a result of agreement at the face to face.  It's not that one
>>is being held hostage, Kepeng has already offered to run 2 separate
>>sessions within the same week.  Maybe you missed a message?
>>
>> Best,
>> Kathleen
>
>Hi Kathleen -
>
>No - I hadn't missed the message.  In fact it's part of the chain
>below.  I think that doing two sessions is a reasonable resolution.
>
>Hannes had already suggested two sessions when Goran made his comment.
>I was responding to Goran's.While I appreciate Goran's frustration
>with the slow pace of things in ACE, I also appreciate that we can only
>do what people are willing to spend time doing

Does that include what chairs are willing to spend time doing?

> and I was also giving
>voice to my perception that there really isn't a good common
>understanding of what's acceptable as an ACE work item.
>
>The original ACE charter was somewhat compact and I would have been
>happy had the group completed the last two items on the currently
>approved charter and closed up shop.  Instead the group as a whole
>decided to adopt a bunch more items without amending the charter setting
>somewhat of a precedent.  Now we've started down the path of profiles
>which are also non-charter items.

>  I'm confused as to why these are any
>different with respect to working group consideration than an item on
>certificate enrollment? (I'm not sure I would buy the argument that the
>profiles are "mechanisms suitable for resource access in constrained
>environments"  and that "certificate enrollment" is not)

The ACE framework (draft-ietf-ace-oauth-authz) does not specify an
complete solution, only the part how OAuth 2.0 is adapted to IoT. The ACE
profiles are providing the missing part, namely how client and resource
server communicate and process the messages, but these depend on the
technology supported by the devices, and in case of IoT we have to accept
that different deployment settings may require different protocols bring
used. This is the reason for the profiles.

In other words we are simply not done with what this WG is chartered for.
The “Authentication and Authorization Solution” is not identical with the
ACE framework. The discussion now is not if profiles should be adopted,
but which profiles and in which order.



Göran

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

Re: [Ace] Doodle for ACE virtual interim meeting in Oct

[Göran Selander]

Hi Mike,

I don’t disagree with your general reasoning, applied to a normally
working WG.

How familiar are you with the inner working and progress of the
authorization-related work in ACE since, say, IETF 96, and the role of the
chair during this time?

(And now I’m not talking about the multicast security discussion, but the
fact that that discussion took place actually also fits into the bigger
picture.)

It is one of the beauties with the IETF is that people can come into the
discussion and share their experience, thanks for that.

It would be even more helpful if we can focus on the specific issues of
this WG. Welcome to bring your terrier into the pit or learn about the
mongrels already there.

Thanks
Göran



On 2017-09-28 19:21, "Ace on behalf of Michael StJohns"
 wrote:

>On 9/27/2017 1:29 PM, Kathleen Moriarty wrote:
>> Goran has a good point here.
>
>Actually - I don't think he does.   If there is a sufficiently
>interested group of people that want to talk certificate enrollment and
>there is a chair available and willing then do an interim on that.  If
>there is a group of sufficiently interested group of people that want to
>talk about the roadmap then do an interim on that.  If ACE doesn't want
>to have such an interim then perhaps it still gets done as a virtual
>BOF.  But this has as much legitimacy as any of the other ACE work items.
>
>Virtual interims have another more common name - teleconferences.
>They're cheap to hold.
>
>Don't hold the certificate stuff hostage to the roadmap stuff and don't
>confuse a F2F interim with a virtual interim with respect to providing a
>false either or choice.
>
>The IETF is bottom up - we work on what the members are interested in
>working on.  It's not a great idea holding one idea hostage as a means
>of trying to get work done on something else.
>
>Later, Mike
>
>>
>> Kathleen
>>
>> On Wed, Sep 27, 2017 at 1:04 PM, Göran Selander
>>  wrote:
>>> As I mentioned in a previous mail, I’m completely against giving
>>>priority
>>> to non-charter items. Therefore the first interim meeting should be
>>> focused on the ACE roadmap - the output from the Wiki activity. If we
>>>have
>>> time to discuss certificate enrolment, that is fine. If we want a later
>>> interim for the certificate enrolment discussion that is fine too, as
>>>long
>>> as there is sufficient time is given to decide on the ongoing work.
>>>
>>> Göran
>>>
>>>
>>> On 2017-09-27 18:34, "Ace on behalf of Hannes Tschofenig"
>>>  wrote:
>>>
>>>> Fair enough.
>>>>
>>>> We either need to make it longer or pick two dates. I prefer the
>>>>latter.
>>>>
>>>> On 09/27/2017 06:23 PM, Kathleen Moriarty wrote:
>>>>> Sure, my response was to make it clear the wiki was to be discussed
>>>>> though.  Will this all be on one call or two?  The announcement
>>>>>wasn't
>>>>> clear and I'd like ot make sure the WG is ready for the profiles
>>>>> discussion.
>>>>>
>>>>> Best,
>>>>> Kathleen
>>>>>
>>>>> On Wed, Sep 27, 2017 at 12:09 PM, Hannes Tschofenig
>>>>>  wrote:
>>>>>> I agree with Kepeng that we also wanted to discuss the certificate
>>>>>> enrollment in addition to the Wiki.
>>>>>>
>>>>>> On 09/27/2017 05:23 PM, Kathleen Moriarty wrote:
>>>>>>> Hello Kepeng,
>>>>>>>
>>>>>>> The interim should also be to discuss the profiles as that was a
>>>>>>> priority from the WG session in Prague.  Goran pulled together the
>>>>>>> wiki, now it's up to the WG participants to check the wiki and
>>>>>>>amend
>>>>>>> as needed to allow for a productive session.  Or did you plan on
>>>>>>>two
>>>>>>> interims?  Timing is tight for that though.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Kathleen
>>>>>>>
>>>>>>> On Tue, Sep 26, 2017 at 9:44 PM, Kepeng Li
>>>>>>>  wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> According to our IETF 99 meeting minutes, we will hold an interim
>>>>>>>> meeting on
>>>>>>>> certificate enrolment in constrained environments.
>>>>>>>> https://datatracker.ietf.org/meeting/99/materials/minutes-99-ace/
>>>>>>>>
>>>>>>>> We proposed three options for the meeting time:
>>>>>>>> 1. 17th Oct, Tuesday, GMT 13:00 ~ 14:00.
>>>>>>>> 2. 18th Oct, Wednesday, GMT 13:00 ~ 14:00.
>>>>>>>> 3. 19th Oct, Thursday, GMT 13:00 ~ 14:00.
>>>>>>>>
>>>>>>>> Please indicate your available time from the doodle poll:
>>>>>>>> https://doodle.com/poll/ig3bhr7tfb2xh4u4
>>>>>>>>
>>>>>>>> Hannes and I will prepare the agenda and send out later. We may
>>>>>>>>add
>>>>>>>> other
>>>>>>>> topics to the agenda.
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>> Kind Regards
>>>>>>>> Kepeng & Hannes
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>> ___
>>>> Ace mailing list
>>>> Ace@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ace
>>
>>
>
>___
>Ace mailing list
>Ace@ietf.org
>https://www.ietf.org/mailman/listinfo/ace

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

Re: [Ace] Doodle for ACE virtual interim meeting in Oct

[Göran Selander]

As I mentioned in a previous mail, I’m completely against giving priority
to non-charter items. Therefore the first interim meeting should be
focused on the ACE roadmap - the output from the Wiki activity. If we have
time to discuss certificate enrolment, that is fine. If we want a later
interim for the certificate enrolment discussion that is fine too, as long
as there is sufficient time is given to decide on the ongoing work.

Göran


On 2017-09-27 18:34, "Ace on behalf of Hannes Tschofenig"
 wrote:

>Fair enough.
>
>We either need to make it longer or pick two dates. I prefer the latter.
>
>On 09/27/2017 06:23 PM, Kathleen Moriarty wrote:
>> Sure, my response was to make it clear the wiki was to be discussed
>> though.  Will this all be on one call or two?  The announcement wasn't
>> clear and I'd like ot make sure the WG is ready for the profiles
>> discussion.
>> 
>> Best,
>> Kathleen
>> 
>> On Wed, Sep 27, 2017 at 12:09 PM, Hannes Tschofenig
>>  wrote:
>>> I agree with Kepeng that we also wanted to discuss the certificate
>>> enrollment in addition to the Wiki.
>>>
>>> On 09/27/2017 05:23 PM, Kathleen Moriarty wrote:
 Hello Kepeng,

 The interim should also be to discuss the profiles as that was a
 priority from the WG session in Prague.  Goran pulled together the
 wiki, now it's up to the WG participants to check the wiki and amend
 as needed to allow for a productive session.  Or did you plan on two
 interims?  Timing is tight for that though.

 Best regards,
 Kathleen

 On Tue, Sep 26, 2017 at 9:44 PM, Kepeng Li
 wrote:
> Hi all,
>
> According to our IETF 99 meeting minutes, we will hold an interim
>meeting on
> certificate enrolment in constrained environments.
> https://datatracker.ietf.org/meeting/99/materials/minutes-99-ace/
>
> We proposed three options for the meeting time:
> 1. 17th Oct, Tuesday, GMT 13:00 ~ 14:00.
> 2. 18th Oct, Wednesday, GMT 13:00 ~ 14:00.
> 3. 19th Oct, Thursday, GMT 13:00 ~ 14:00.
>
> Please indicate your available time from the doodle poll:
> https://doodle.com/poll/ig3bhr7tfb2xh4u4
>
> Hannes and I will prepare the agenda and send out later. We may add
>other
> topics to the agenda.
>
> Thanks.
>
> Kind Regards
> Kepeng & Hannes
>



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

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

Re: [Ace] ACE Roadmap Wiki (Was: Re: Volunteer to set up the wiki)

[Göran Selander]

Hi again, 

One more thing: If we have missed some criteria for comparing the
profiles, just add another column.

Göran

On 2017-09-27 13:46, "Göran Selander"  wrote:

>Hi all,
>
>Here is a first attempt to draw a table outlining and comparing the
>proposed ACE profiles:
>
>https://trac.ietf.org/trac/ace/wiki/WikiStart
>
>The table is not complete and some of the values I filled in quickly, so
>profile authors are invited to verify and change/add to this table. In
>order to edit the page you need to log in using your IETF datatracker
>account. Please make your contribution before the end of next week
>(October 6th).
>
>The purpose of this exercise is to get an overview of the drafts targeting
>the current charter and how they depend to each other. If you have any
>comments, please let me know.
>
>Best regards,
>Göran
>
>
>On 2017-09-18 18:44, "Göran Selander"  wrote:
>
>>Hi Kathleen, and all,
>>
>>Yes, I started today but got interrupted. I added your items to the list
>>just now. 
>>
>>All: If you are missing some comparison criteria please add directly to
>>the Wiki or respond to this mail
>>
>>
>>Best regards,
>>Göran
>>
>>
>>On 2017-09-18 18:31, "Kathleen Moriarty"
>> wrote:
>>
>>>Hi Goran,
>>>
>>>I see you've started working on the wiki template, thank you!  You may
>>>already have this as a planned addition, but I'd like to see
>>>implementation and use cases listed as comparison points too.  This
>>>might assist the working group with prioritization.
>>>
>>>Thanks, again!
>>>Kathleen
>>>
>>>On Thu, Sep 14, 2017 at 9:57 AM, Göran Selander
>>> wrote:
>>>> Hi Cigdem,
>>>>
>>>> From: Cigdem Sengul 
>>>> Date: Tuesday 12 September 2017 at 18:49
>>>> To: Göran Selander 
>>>> Cc: Kathleen Moriarty ,
>>>>"ace@ietf.org"
>>>> 
>>>> Subject: Re: [Ace] Volunteer to set up the wiki
>>>>
>>>> Hello,
>>>>
>>>> +1 for row and column information. For completeness sake,
>>>> I was thinking whether the column information should be the  coming
>>>>from the
>>>> list in draft-ietf-ace-oauth-authz-07,  Appendix C.  Requirements on
>>>> Profiles.
>>>>
>>>>
>>>> Yes, that’s a good starting point.
>>>>
>>>> Thanks,
>>>> Göran
>>>>
>>>>
>>>> Thanks,
>>>> --Cigdem
>>>>
>>>>
>>>> On Tue, Sep 12, 2017 at 4:41 PM, Göran Selander
>>>>  wrote:
>>>>>
>>>>> Hi Kathleen,
>>>>>
>>>>> As I remember the reason to set up the Wiki was to generate a roadmap
>>>>>for
>>>>> the ACE work. We noted dependencies and potential overlap between
>>>>> different profiles and some content rather belonging to the framework
>>>>>than
>>>>> individual profile. A starting point for deciding on the roadmap
>>>>>could
>>>>>be
>>>>> a table with rows for each profile and where the columns could be
>>>>>some
>>>>> distinguishing features of each profile such as: the scope of the
>>>>>profile,
>>>>> nodes (if other than client and RS), protocols used between nodes
>>>>> (including security protocols), dependence on other profiles,
>>>>>candidate
>>>>> framework functionality described in the draft, etc.
>>>>>
>>>>> If people agree with this I can help setting up the table, and those
>>>>> proposing profiles could fill in the rows.
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Göran
>>>>>
>>>>>
>>>>>
>>>>> On 2017-09-12 16:16, "Ace on behalf of Kathleen Moriarty"
>>>>> 
>>>>> wrote:
>>>>>
>>>>> >Hello,
>>>>> >
>>>>> >In Prague, we agreed as a next step we would pull together a
>>>>> >comparison chart for profiles using the WG wiki.  Can I get a
>>>>> >volunteer to set up the wiki page?  You should first get agreement
>>>>> >(light agreement as we need to move on this) as to what we want to
>>>>> >compare.  The list for comparison does not appear in the minutes,
>>>>>but
>>>>> >was discussed in the meeting, so the recording might be helpful.
>>>>> >
>>>>> >Here is a link to the wiki:
>>>>> >https://trac.ietf.org/trac/ace
>>>>> >--
>>>>> >
>>>>> >Best regards,
>>>>> >Kathleen
>>>>> >
>>>>> >___
>>>>> >Ace mailing list
>>>>> >Ace@ietf.org
>>>>> >https://www.ietf.org/mailman/listinfo/ace
>>>>>
>>>>> ___
>>>>> Ace mailing list
>>>>> Ace@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/ace
>>>>
>>>>
>>>>
>>>> ___
>>>> Ace mailing list
>>>> Ace@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ace
>>>>
>>>
>>>
>>>
>>>-- 
>>>
>>>Best regards,
>>>Kathleen
>>
>

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

[Ace] ACE Roadmap Wiki (Was: Re: Volunteer to set up the wiki)

[Göran Selander]

Hi all,

Here is a first attempt to draw a table outlining and comparing the
proposed ACE profiles:

https://trac.ietf.org/trac/ace/wiki/WikiStart

The table is not complete and some of the values I filled in quickly, so
profile authors are invited to verify and change/add to this table. In
order to edit the page you need to log in using your IETF datatracker
account. Please make your contribution before the end of next week
(October 6th).

The purpose of this exercise is to get an overview of the drafts targeting
the current charter and how they depend to each other. If you have any
comments, please let me know.

Best regards,
Göran


On 2017-09-18 18:44, "Göran Selander"  wrote:

>Hi Kathleen, and all,
>
>Yes, I started today but got interrupted. I added your items to the list
>just now. 
>
>All: If you are missing some comparison criteria please add directly to
>the Wiki or respond to this mail
>
>
>Best regards,
>Göran
>
>
>On 2017-09-18 18:31, "Kathleen Moriarty"
> wrote:
>
>>Hi Goran,
>>
>>I see you've started working on the wiki template, thank you!  You may
>>already have this as a planned addition, but I'd like to see
>>implementation and use cases listed as comparison points too.  This
>>might assist the working group with prioritization.
>>
>>Thanks, again!
>>Kathleen
>>
>>On Thu, Sep 14, 2017 at 9:57 AM, Göran Selander
>> wrote:
>>> Hi Cigdem,
>>>
>>> From: Cigdem Sengul 
>>> Date: Tuesday 12 September 2017 at 18:49
>>> To: Göran Selander 
>>> Cc: Kathleen Moriarty ,
>>>"ace@ietf.org"
>>> 
>>> Subject: Re: [Ace] Volunteer to set up the wiki
>>>
>>> Hello,
>>>
>>> +1 for row and column information. For completeness sake,
>>> I was thinking whether the column information should be the  coming
>>>from the
>>> list in draft-ietf-ace-oauth-authz-07,  Appendix C.  Requirements on
>>> Profiles.
>>>
>>>
>>> Yes, that’s a good starting point.
>>>
>>> Thanks,
>>> Göran
>>>
>>>
>>> Thanks,
>>> --Cigdem
>>>
>>>
>>> On Tue, Sep 12, 2017 at 4:41 PM, Göran Selander
>>>  wrote:
>>>>
>>>> Hi Kathleen,
>>>>
>>>> As I remember the reason to set up the Wiki was to generate a roadmap
>>>>for
>>>> the ACE work. We noted dependencies and potential overlap between
>>>> different profiles and some content rather belonging to the framework
>>>>than
>>>> individual profile. A starting point for deciding on the roadmap could
>>>>be
>>>> a table with rows for each profile and where the columns could be some
>>>> distinguishing features of each profile such as: the scope of the
>>>>profile,
>>>> nodes (if other than client and RS), protocols used between nodes
>>>> (including security protocols), dependence on other profiles,
>>>>candidate
>>>> framework functionality described in the draft, etc.
>>>>
>>>> If people agree with this I can help setting up the table, and those
>>>> proposing profiles could fill in the rows.
>>>>
>>>>
>>>> Best regards,
>>>> Göran
>>>>
>>>>
>>>>
>>>> On 2017-09-12 16:16, "Ace on behalf of Kathleen Moriarty"
>>>> 
>>>> wrote:
>>>>
>>>> >Hello,
>>>> >
>>>> >In Prague, we agreed as a next step we would pull together a
>>>> >comparison chart for profiles using the WG wiki.  Can I get a
>>>> >volunteer to set up the wiki page?  You should first get agreement
>>>> >(light agreement as we need to move on this) as to what we want to
>>>> >compare.  The list for comparison does not appear in the minutes, but
>>>> >was discussed in the meeting, so the recording might be helpful.
>>>> >
>>>> >Here is a link to the wiki:
>>>> >https://trac.ietf.org/trac/ace
>>>> >--
>>>> >
>>>> >Best regards,
>>>> >Kathleen
>>>> >
>>>> >___
>>>> >Ace mailing list
>>>> >Ace@ietf.org
>>>> >https://www.ietf.org/mailman/listinfo/ace
>>>>
>>>> ___
>>>> Ace mailing list
>>>> Ace@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>>
>>>
>>> ___
>>> Ace mailing list
>>> Ace@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ace
>>>
>>
>>
>>
>>-- 
>>
>>Best regards,
>>Kathleen
>

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

Re: [Ace] Volunteer to set up the wiki

[Göran Selander]

Hi Kathleen, and all,

Yes, I started today but got interrupted. I added your items to the list
just now. 

All: If you are missing some comparison criteria please add directly to
the Wiki or respond to this mail


Best regards,
Göran


On 2017-09-18 18:31, "Kathleen Moriarty"
 wrote:

>Hi Goran,
>
>I see you've started working on the wiki template, thank you!  You may
>already have this as a planned addition, but I'd like to see
>implementation and use cases listed as comparison points too.  This
>might assist the working group with prioritization.
>
>Thanks, again!
>Kathleen
>
>On Thu, Sep 14, 2017 at 9:57 AM, Göran Selander
> wrote:
>> Hi Cigdem,
>>
>> From: Cigdem Sengul 
>> Date: Tuesday 12 September 2017 at 18:49
>> To: Göran Selander 
>> Cc: Kathleen Moriarty , "ace@ietf.org"
>> 
>> Subject: Re: [Ace] Volunteer to set up the wiki
>>
>> Hello,
>>
>> +1 for row and column information. For completeness sake,
>> I was thinking whether the column information should be the  coming
>>from the
>> list in draft-ietf-ace-oauth-authz-07,  Appendix C.  Requirements on
>> Profiles.
>>
>>
>> Yes, that’s a good starting point.
>>
>> Thanks,
>> Göran
>>
>>
>> Thanks,
>> --Cigdem
>>
>>
>> On Tue, Sep 12, 2017 at 4:41 PM, Göran Selander
>>  wrote:
>>>
>>> Hi Kathleen,
>>>
>>> As I remember the reason to set up the Wiki was to generate a roadmap
>>>for
>>> the ACE work. We noted dependencies and potential overlap between
>>> different profiles and some content rather belonging to the framework
>>>than
>>> individual profile. A starting point for deciding on the roadmap could
>>>be
>>> a table with rows for each profile and where the columns could be some
>>> distinguishing features of each profile such as: the scope of the
>>>profile,
>>> nodes (if other than client and RS), protocols used between nodes
>>> (including security protocols), dependence on other profiles, candidate
>>> framework functionality described in the draft, etc.
>>>
>>> If people agree with this I can help setting up the table, and those
>>> proposing profiles could fill in the rows.
>>>
>>>
>>> Best regards,
>>> Göran
>>>
>>>
>>>
>>> On 2017-09-12 16:16, "Ace on behalf of Kathleen Moriarty"
>>> 
>>> wrote:
>>>
>>> >Hello,
>>> >
>>> >In Prague, we agreed as a next step we would pull together a
>>> >comparison chart for profiles using the WG wiki.  Can I get a
>>> >volunteer to set up the wiki page?  You should first get agreement
>>> >(light agreement as we need to move on this) as to what we want to
>>> >compare.  The list for comparison does not appear in the minutes, but
>>> >was discussed in the meeting, so the recording might be helpful.
>>> >
>>> >Here is a link to the wiki:
>>> >https://trac.ietf.org/trac/ace
>>> >--
>>> >
>>> >Best regards,
>>> >Kathleen
>>> >
>>> >___
>>> >Ace mailing list
>>> >Ace@ietf.org
>>> >https://www.ietf.org/mailman/listinfo/ace
>>>
>>> ___
>>> Ace mailing list
>>> Ace@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ace
>>
>>
>>
>> ___
>> Ace mailing list
>> Ace@ietf.org
>> https://www.ietf.org/mailman/listinfo/ace
>>
>
>
>
>-- 
>
>Best regards,
>Kathleen

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

Re: [Ace] Volunteer to set up the wiki

[Göran Selander]

Hi Cigdem,

From: Cigdem Sengul mailto:cigdem.sen...@gmail.com>>
Date: Tuesday 12 September 2017 at 18:49
To: Göran Selander 
mailto:goran.selan...@ericsson.com>>
Cc: Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>>, 
"ace@ietf.org<mailto:ace@ietf.org>" mailto:ace@ietf.org>>
Subject: Re: [Ace] Volunteer to set up the wiki

Hello,

+1 for row and column information. For completeness sake,
I was thinking whether the column information should be the  coming from the 
list in draft-ietf-ace-oauth-authz-07,  Appendix C.  Requirements on Profiles.

Yes, that’s a good starting point.

Thanks,
Göran


Thanks,
--Cigdem


On Tue, Sep 12, 2017 at 4:41 PM, Göran Selander 
mailto:goran.selan...@ericsson.com>> wrote:
Hi Kathleen,

As I remember the reason to set up the Wiki was to generate a roadmap for
the ACE work. We noted dependencies and potential overlap between
different profiles and some content rather belonging to the framework than
individual profile. A starting point for deciding on the roadmap could be
a table with rows for each profile and where the columns could be some
distinguishing features of each profile such as: the scope of the profile,
nodes (if other than client and RS), protocols used between nodes
(including security protocols), dependence on other profiles, candidate
framework functionality described in the draft, etc.

If people agree with this I can help setting up the table, and those
proposing profiles could fill in the rows.


Best regards,
Göran



On 2017-09-12 16:16, "Ace on behalf of Kathleen Moriarty"
mailto:ace-boun...@ietf.org> on behalf of 
kathleen.moriarty.i...@gmail.com<mailto:kathleen.moriarty.i...@gmail.com>> 
wrote:

>Hello,
>
>In Prague, we agreed as a next step we would pull together a
>comparison chart for profiles using the WG wiki.  Can I get a
>volunteer to set up the wiki page?  You should first get agreement
>(light agreement as we need to move on this) as to what we want to
>compare.  The list for comparison does not appear in the minutes, but
>was discussed in the meeting, so the recording might be helpful.
>
>Here is a link to the wiki:
>https://trac.ietf.org/trac/ace
>--
>
>Best regards,
>Kathleen
>
>___
>Ace mailing list
>Ace@ietf.org<mailto:Ace@ietf.org>
>https://www.ietf.org/mailman/listinfo/ace

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

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

Re: [Ace] draft-selander-ace-eals vs. draft-vanderstok-ace-coap-est

[Göran Selander]

Hi Hannes, 

It is interesting to note that during the last 6 months there seems to be
very little activity to encourage discussion or reviews of the drafts
which actually are in scope of the current ACE charter. For example, what
do people think about the overlaps between the two publish-subscribe
profiles (draft-sengul-kirby-ace-mqtt-tls-profile vs.
draft-palombini-ace-coap-pubsub-profile)? Instead, you as co-chair of ACE
encourage the WG to discuss two drafts about certificate enrolment, a
topic which is not even mentioned in the current charter.

As co-author of one of the drafts in the subject of this mail I of course
welcome the discussion, but it is important that this thread does not to
distract the ACE WG from working according to its charter on its missed
milestones.

Now for the topic of comparing the certificate enrolment drafts.
draft-vanderstok-ace-coap-est proposes a very natural and significant
optimization of EST adapted to the established security setup for CoAP,
and I fully support that. There are overlapping authors between the
drafts, so clearly the drafts should not be seen in opposition to each
other.

My view of the potential contribution with draft-selander-ace-eals (which
is a first sketch we made in the spring, and which I recently stepped in
revision just to keep alive) is twofold:

1. It discusses the generalisation of EST to application layer security.
The enrolment procedure in EST is in principle not dependent on what layer
authentication takes place, provided there is security end-to-end between
the endpoint making the enrolment request and the endpoint providing the
certificate. As we know, there are common IoT settings where security on
transport layer does not go end-to-end because of gateways or proxies or
because of change of underlying layers, which is the reason for proposing
this complement on the application layer. As to the actual enrolment
procedure, it may well be the same in both cases of transport layer
security or application layer security.

2. In a second independent component (section 3.2), the ACE framework is
applied to authorise and provide keys to the endpoints involved in the
enrolment, after which the very same enrolment procedure can take place.
This shows a more lightweight key establishment than with a key exchange
protocol (such as the DTLS handshake or EDHOC) with fewer and smaller
messages, and less public key operations, all of which are favourable
properties in constrained environments.

The implicit question posed by draft-selander-ace-eals is the following:
If we are considering one IoT variant of EST
(draft-vanderstok-ace-coap-est) should we also consider other variants
using the same enrolment procedure, which can be applied to a wider range
of IoT use cases and/or which are more favourable in settings with
constrained IoT devices?



Göran




On 2017-09-13 17:42, "Ace on behalf of Hannes Tschofenig"
 wrote:

>Hi all,
>
>in previous IETF meetings we had presentations on these two documents
>and it appears that there is an overlap. So far we haven't had a lot of
>discussions on these proposals on the list but since there seems to be
>interest from the folks attending the IETF meetings I am recommending to
>have a discussion about the direction we should go with this work.
>
>Any thoughts?
>
>Ciao
>Hannes
>
>___
>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] Volunteer to set up the wiki

[Göran Selander]

Hi Kathleen,

As I remember the reason to set up the Wiki was to generate a roadmap for
the ACE work. We noted dependencies and potential overlap between
different profiles and some content rather belonging to the framework than
individual profile. A starting point for deciding on the roadmap could be
a table with rows for each profile and where the columns could be some
distinguishing features of each profile such as: the scope of the profile,
nodes (if other than client and RS), protocols used between nodes
(including security protocols), dependence on other profiles, candidate
framework functionality described in the draft, etc.

If people agree with this I can help setting up the table, and those
proposing profiles could fill in the rows.


Best regards,
Göran



On 2017-09-12 16:16, "Ace on behalf of Kathleen Moriarty"
 wrote:

>Hello,
>
>In Prague, we agreed as a next step we would pull together a
>comparison chart for profiles using the WG wiki.  Can I get a
>volunteer to set up the wiki page?  You should first get agreement
>(light agreement as we need to move on this) as to what we want to
>compare.  The list for comparison does not appear in the minutes, but
>was discussed in the meeting, so the recording might be helpful.
>
>Here is a link to the wiki:
>https://trac.ietf.org/trac/ace
>-- 
>
>Best regards,
>Kathleen
>
>___
>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 Minutes

[Göran Selander]

Dear chairs,

There has been no progress since the Chicago meeting on which profiles to
standardise (except for meta-progress during the recent meeting in the
decision to set up a Wiki). Therefore I propose we schedule an interim to
make some real progress. Considering that this is a charter item I think
such an interim should have higher priority - i.e. happen before - any
other interim meeting of this working group. The filled in Wiki can be
good input to such a meeting.

Göran



On 2017-07-26 20:38, "Ace on behalf of Hannes Tschofenig"
 wrote:

>Hi all,
>
>here are the meeting minutes:
>https://datatracker.ietf.org/doc/minutes-99-ace/
>
>Thanks to John Mattsson for taking notes.
>
>Feedback is appreciated!
>
>Ciao
>Hannes
>
>___
>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] [core] Question about AEAD nonce uniqueness

[Göran Selander]

Hi Mohit,

(Also including ACE since EDHOC belongs there.)

Thanks for taking the time and reviewing OSCOAP and EDHOC.

Again, Jim was quicker to answer, and in fact this is one of the features of 
EDHOC that was proposed by him. Let me give a background, maybe that helps.

One of the main design criteria for OSCOAP and EDHOC is to make the protocol 
messages small, since many performance aspects are related to message sizes.

Whereas EDHOC is only expected to be run once in a while (maybe just once), 
OSCOAP may potentially be used with in every CoAP message, so in particular for 
OSCOAP we have tried to turn over every byte. The current overhead of OSCOAP 
for a typical CoAP message exchange is 13 bytes in the request and 9 bytes in 
the response and that includes the 8 bytes of MAC in each message. This message 
size calculation includes a Sender ID of 1 byte. Hence to get low overhead in 
particular requires a short Sender ID. See 
https://tools.ietf.org/html/draft-mattsson-core-security-overhead-00#section-2.11

Note that the Sender ID is only significant for a particular master secret and 
the use of short identifiers (addressing your comment on "minimum length") is 
described in the OSCOAP section I referenced below.

If the Sender ID coincides with a Sender ID used with another security context 
that is not a security issue, but a device receiving a message for which it has 
multiple security contexts with the same Sender ID would have to try more than 
once before finding the right (addressing your comment on "concrete effects”).  
Jim doesn’t have a problem with that, we wanted to try to avoid it. But, just 
in case, we should describe the processing handling this, I note that as an 
issue.

For two peers autonomously establishing a security context, neither of the 
nodes have knowledge about the identifiers used by the peer in its various 
OSCOAP contexts with other parties. Therefore, in EDHOC, as described by Jim, 
each party can select its own locally unique short session identifier, and when 
EDHOC is used with OSCOAP this session identifier becomes the Sender ID, see
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-05#appendix-B.2
(addressing your comment on "how it is generated")

Having short session identifiers also optimises the EDHOC messages, since they 
short (of course) but also since the nonces N_U, N_V (which are longer) only 
need to be sent once, in comparison with a protocol combining the function of 
nonce and session identifier.

If there is a trusted third party such as the Group Manager in a multicast 
setting (as referenced below) then the assignment of identifiers in the set of 
devices sharing a common context can be unilaterally decided by the GM and the 
size of identifiers optimised (addressing your comment on "out of scope" - 
which in my mail only referred to this case). Note that there is no additional 
complication in making this assignment since it just has to be locally unique 
for that group.

Did that make things more clear? Do you think further clarifications are needed 
in the drafts?


Thanks
Göran




From: 6tisch <6tisch-boun...@ietf.org<mailto:6tisch-boun...@ietf.org>> on 
behalf of Jim Schaad mailto:i...@augustcellars.com>>
Date: Thursday 13 April 2017 at 16:39
To: Mohit Sethi 
mailto:mohit.m.se...@ericsson.com>>, Göran Selander 
mailto:goran.selan...@ericsson.com>>, 'Core' 
mailto:c...@ietf.org>>, 
"6ti...@ietf.org<mailto:6ti...@ietf.org>" 
<6ti...@ietf.org<mailto:6ti...@ietf.org>>
Cc: 'Christian Amsüss' 
mailto:c.amsu...@energyharvesting.at>>
Subject: Re: [6tisch] [core] Question about AEAD nonce uniqueness

The selection of S_X is done by party X.  This means that all they need to do 
is to generate – either randomly or deterministically – some identifier which 
is currently unique for them.

The easiest way to do this is to have an array of N security contexts.  Choose 
the first slot in the array which is empty and use that index as your 
identifier.  If the array is full, then either grow the array or scavenge a 
security context which has not been used in a while and use that slot.  This 
allows for identifiers that are unique to the party and still very small.

The only time that one would need large random identifiers is when the keying 
material is generated by a third party such as the PSK version of EDHOC where 
the common PSK needs to be identified for both parties.

I also do not have the same problems with collisions that Göran and others 
have.  I am willing to try multiple keys in the event of a collision and only 
the correct one will work.  This is not unusual in some cases already in other 
environments.

Jim


From: Mohit Sethi [mailto:mohit.m.se...@ericsson.com]
Sent: Thursday, April 13, 2017 2:46 AM
To: Göran Selander 
mailto:goran.selan...@ericsson.com>>; 'Core' 
mai

Re: [Ace] HKDF useage in ace-cose-ecdhe-05

[Göran Selander]

Hello Dan,

Thanks for commenting.

The encryption of K_1 in the symmetric case is an open issue, we should
have mentioned that in the meeting. Jim Schaad has also provided arguments
to remove it.

Your expression “opportunistic” is a good characterisation. We included
encryption and integrity protection of message_1 in the symmetric version
mainly because we can, in contrast to in the asymmetric version. But as
you point out, if we keep encryption of message_1 then we should derive
K_1 in a different way, and then the key derivation in the asymmetric and
symmetric versions of the protocol would probably not be the same, which
was another design objective.

I haven’t talked with my co-authors yet, but we will either omit
encryption of message_1 in the symmetric case or change the derivation of
K_1.

Regards,
Göran


On 2017-03-29 23:55, "Ace on behalf of Dan Harkins"  wrote:

>
>   Hello,
>
>   I want to expand on my comments I made at the mic on Monday regarding
>key derivation with symmetric key authentication in draft-selander-ace-
>cose-ecdhe-05. When doing authentication with symmetric keys message 1 is
>encrypted using K_1 and K_1 is generated by passing (as far as I can tell,
>and I did admit at the mic that it's a little fuzzy) the PSK as salt and
>an empty key to HKDF. This poses some problems I think.
>
>   - The only source of entropy in K_1 is the PSK and this makes the
>protocol
> susceptible to a passive dictionary attack[1] that would,
>otherwise, not
> be possible.
>
>   - It seems somewhat unhygienic, from a crypto point of view, to pass
> a NULL key to a key derivation function.
>
>   - Use of the PSK in messages 2 and 3 authenticate the particular key
> used in the AEAD and decryption/verification provides authentication
>of
> the sender to the receiver. But for message 1 is different. There is
> no benefit to the key exchange provided by encryption of message 1.
>
>   The sole benefit of encrypting in message 1 seems to be that EXT_1 gets
>encrypted. But EXT_1 in the asymmetric case is not encrypted so there
>doesn't really seem there can be much that needs protection; seems like
>this is more of an opportunistic thing. That being the case, there is
>little upside and considerable downside to generating K_1 and encrypting
>a portion of message 1. I recommend that being removed from the draft.
>
>   regards,
>
>   Dan.
>
>[1] a dictionary attack is defined as one where the attacker gains an
>advantage from computation as opposed to interaction. The size of the
>dictionary (e.g. all numbers between 0 and 2^256) only affects the
>probability of success of the attack not whether it is a dictionary
>attack or not.
>
>
>
>
>___
>Ace mailing list
>Ace@ietf.org
>https://www.ietf.org/mailman/listinfo/ace

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

Re: [Ace] Call for presentations for IETF98

[Göran Selander]

Hi ACE chairs and all,

Here are some proposed agenda items for ACE:

* ACE profiles.

A number of drafts have been submitted as profiles of the ACE framework. The 
drafts vary somewhat in scope and in degree of detail what they specify. Some 
functionality is overlapping between the drafts. Some functionality described 
in one ACE profile is applicable to all profiles and may either be copied over 
or included in the framework.

Time: 20 minutes
Objective: Ask for the WG's view on coordinating content in the ACE profiles. 
Are the requirements on profiles described in the ACE framework sufficient? 
(https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-06#appendix-C)


* EDHOC

https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-05

Following the last round of reviews we have updated this application layer key 
exchange protocol which is used e.g. in the OSCOAP profile of ACE and in the 
6TiSCH minimal security framework. We think this is now ready to move forward.

Time: 15 min
Objective: Call for adoption


* EALS

https://www.ietf.org/internet-drafts/draft-selander-ace-eals-00.txt

This is a strawman on certificate enrolment using the new IoT application layer 
security protocols. If certificate enrolment for IoT devices is on the agenda 
then we would like to present this.

Time: 10 min
Objective: Ask for review


Göran




From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Kepeng Li mailto:kepeng@alibaba-inc.com>>
Date: Wednesday 15 March 2017 at 05:21
To: "Ace@ietf.org" mailto:Ace@ietf.org>>
Subject: [Ace] Call for presentations for IETF98

Hi everyone,

So far, the chairs have had two requests for presentations at the ACE meeting 
of IETF98, which we will be accommodating along with discussion on the current 
draft progress.

We’re putting the agenda together now, and we would like to know if anyone else 
has a topic that they’d like to present and discuss at the upcoming face to 
face.

Please send feedback to Hannes and me before the end of 17th Mar, including 
draft name, presenter, how much time, objectives.

Thanks.

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

Re: [Ace] edhoc section 4: N_U/N_V question

[Göran Selander]

Michael, 

This has already been updated in the latest version on the Github:
https://ericssonresearch.github.io/EDHOC/


As I mentioned we will submit to the IETF a new version next week, pending
some expected review comments.

Göran


On 2017-02-24 14:15, "Michael Richardson"  wrote:

>
>N_U, N_V, E_V, Alg_V, Enc(K_VE; ID_V, Sig(V; Mac(K_VM; prot_2)))|
>| <---+
>| message_2
>|
>|
>|
>| |
>|N_U, N_V, Enc(K_UE; ID_U, Sig(U; Mac(K_UM; prot_3)))
>
>Why is N_U echoed back to U in message 2?
>Why are N_U and N_V included in message 3?
>
>If the nonce acts as a defense against off-path attacks, then at least
>N_U does not need to be in message 3.  Including N_U in message 2 defends
>an off-path attacker racing V to reply to message_1, which seems unlikely.
>
>
>--
>Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>

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

Re: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

[Göran Selander]

I’m in favour of adopting a profile of the ACE framework [1] providing the 
functionality outlined in this draft.

It was acknowledged in the latest ACE interim that this draft will be 
transformed into an ACE profile, but currently the mapping to ACE is not very 
clear:

- Many of the "Requirements on Profiles” (Appendix C of [1]) are not fulfilled, 
e.g. how is the "resource server" of the ACE framework mapped? Is it the KDC?
- Will the proposed ACE-DTLS profile [2] be used or will we have different 
methods for authorising DTLS in different profiles?

There has been a lot of discussion of this draft, whereas "non-controversial” 
profiles of ACE ([2], [3], [4]) has been disregarded in the process. If one 
profile is being adopted without consideration of other profiles it may lead to 
duplication of specification, or different mechanisms being defined doing the 
same thing.

Chairs: What is the plan for coordinating the functionality in the different 
ACE profiles being adopted?


Göran


[1]  https://tools.ietf.org/html/draft-ietf-ace-oauth-authz
[2] https://tools.ietf.org/html/draft-gerdes-ace-dtls-authorize
[3] https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile
[4] https://tools.ietf.org/html/draft-sengul-kirby-ace-mqtt-tls-profile




From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Kepeng Li mailto:kepeng@alibaba-inc.com>>
Date: Thursday 23 February 2017 at 10:48
To: "Ace@ietf.org" mailto:Ace@ietf.org>>
Cc: Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>>, 
Hannes Tschofenig mailto:hannes.tschofe...@gmx.net>>
Subject: [Ace] Call for adoption for draft-somaraju-ace-multicast-02

Hello all,



This note begins a Call For Adoption for draft-somaraju-ace-multicast-02 [1] to 
be adopted as an ACE working group item, and added in the charter. The call 
ends on Mar 7, 2017.


Keep in mind that adoption of a document does not mean the document as-is is 
ready for publication. It is merely acceptance of the document as a starting 
point for what will be the final product of the ACE working group. The working 
group is free to make changes to the document according to the normal consensus 
process.



Please reply on this thread with expressions of support or opposition, 
preferably with comments, regarding accepting this as a work item.


Thanks,



Kind Regards

Kepeng (ACE co-chair)

[1] https://datatracker.ietf.org/doc/draft-somaraju-ace-multicast/
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] edhoc section 4.3.2

[Göran Selander]

Hi Michael,

Please see the latest version of EDHOC:
https://ericssonresearch.github.io/EDHOC/

The draft has gone through a number of reviews and is in many ways
rewritten. We will submit a new version next week. Inline:

On 2017-02-24 03:08, "Michael Richardson"  wrote:

>
>It says:
>>4.3.2.  message_1 -> V
>>
>>   Party V processes the received message_1 as follows:
>>
>>   o  Party V SHALL verify that the nonce has not been received before.
>> If the verification fails, the message MUST be discarded.
>> Otherwise, Party V SHALL store a representation of the nonce
>> for future verifications.
>
>Please clarify "has not been received before". Ever? Or within some
>interval?  In IKE, we care about the nonces not being reused during the
>time
>that the node continues to use the same keypair at its end. (In DH,
>this means the same y value for g^y). But, you specify a fresh keypair
>each
>time.

Verification of nonces is now optional (e.g. section 4.2.3). Nonces are
not allowed to be reused but it is noted that replay of message_1 cannot
be detected unless unless previous nonces are stored (see security
considerations).


In issue 16 it was requested to allow multiple uses of ephemeral keys and
it was added in the security considerations. I think it makes sense to
mandate the verification of nonce uniqueness during reuse of ephemeral
keys and have reopened issue 16:


https://github.com/EricssonResearch/EDHOC/issues/16


>
>Can two nodes U1 and U2 both use the same nonce (by random chance!)
>Or must it be unique among all peers?
>
>Storing such nonces is impossible for a constrained node...
>Even a non-constained node V won't be able to store many nonces received,
>once you count adding indexes to search for the list efficiently.

Agree.

Göran








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

Re: [Ace] Summary of ACE Group Communication Security Discussion

[Göran Selander]

Kathleen and all,

I believe all necessary drafts for a solution based on asymmetric keys are 
already in place.

With "a solution based on asymmetric keys” I understand a solution where each 
member of the group can sign messages with its private key for source 
authentication but where confidentiality is protected with a symmetric key 
shared between the members of the group.

[1] describes how to distribute and use symmetric keys, using a KDC for 
distributing the symmetric keys, and references OSCOAP for securing the group 
communication. [2] shows how to secure group communication for CoAP based on 
asymmetric keys as described above. As far as I understand, the only thing 
missing is a mechanism for distributing the public keys of the members, but it 
seems natural to extend the KDC with this functionality.

[1] https://tools.ietf.org/html/draft-somaraju-ace-multicast-01
[2] https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-00



However, I don’t agree with all conclusions of the asymmetric key proponents.

It is not news that asymmetric key techniques are feasible for use in many 
embedded device applications, but it is good that the knowledge is being 
spread. But execution times and message sizes may still be prohibitive for some 
applications. To address Rene’s question "is 64B too much?": Adding the 
countersignature to COSE messages such as those used in multicast OSCOAP would 
increase the size from the order of 20 bytes to the order of 85-90 bytes which 
in turn may add significant latency depending on link layer technology used, 
independently of processor capacity.


Without neglecting the issues raised, I do think that there is a role for 
symmetric key based group communication for the class of actuators in scope of 
[1]. I agree it is an issue if compromising one device and extracting one key 
let's you turn off 1000 lamps (not saying it has to, but just as an example). 
But that doesn't automatically turn the lightbulbs into bots.  The security 
considerations in this case should e.g. include things like restricting 
capabilities associated with the possession of a shared key.


Independent of this discussion, symmetric key solutions for these use cases 
will continue to be deployed. I fear we may create greater damage by not 
analysing and providing guidance to these use cases when applied in a symmetric 
key setting, at the same time as specifying an asymmetric key solution.


Göran



From: Ace mailto:ace-boun...@ietf.org>> on behalf of 
Kathleen Moriarty 
mailto:kathleen.moriarty.i...@gmail.com>>
Date: Friday 18 November 2016 at 04:59
To: "Tirumaleswar Reddy (tireddy)" mailto:tire...@cisco.com>>
Cc: Michael StJohns mailto:mstjo...@comcast.net>>, Rene 
Struik mailto:rstruik@gmail.com>>, 
"ace@ietf.org" mailto:ace@ietf.org>>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion



On Thu, Nov 17, 2016 at 10:56 PM, Tirumaleswar Reddy (tireddy) 
mailto:tire...@cisco.com>> wrote:
Kathleen,

I will put up a proposal before the Chicago meeting.

Thank you.

-Tiru

From: Ace [mailto:ace-boun...@ietf.org] On Behalf 
Of kathleen.moriarty.i...@gmail.com
Sent: Friday, November 18, 2016 5:30 AM
To: Rene Struik mailto:rstruik@gmail.com>>
Cc: Michael StJohns mailto:mstjo...@comcast.net>>; 
ace@ietf.org
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

Is anyone willing to work on a draft to be ready in advance of the Chicago 
meeting so we have a concrete proposal for asymmetric keys?

Thanks,
Kathleen

Please excuse typos, sent from handheld device

On Nov 17, 2016, at 11:26 PM, Rene Struik 
mailto:rstruik@gmail.com>> wrote:
Dear colleagues:

Just a reminder re perceived technical hurdles for using signatures:
a) time latency of signing:
One can pre-compute ephemeral signing keys, so as to reduce online key 
computation to a few finite field multiplies.
Please see my email to the list of July 26, 2016: 
https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0
b): further speed-ups/tricks, etc:
One can try and be smarter by clever implementations.
Please see my email to the list of July 21, 2016: 
https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI

This seems to take the time latency argument away. The only other technical 
hurdles I can see are
(i) signature size {is 64B too much?};
(ii) cost of public key crypto implementations {quite some small, nifty designs 
out there (NaCl etc.}.

As to (i) - one should view signature sizes in perspective: as an example, key 
sizes in the key pre-distribution scheme HIMMO (as promoted by Philips) has key 
sizes of 6.25 kB and up, according to Table 3 of the paper that massages 
parameters to thwart new attacks on their scheme, see 
http://eprint.iacr.org/2016/152.

So, security arguments that favor asymmetric solutions aside, there also do not 
see

Re: [Ace] Review of draft-selander-ace-cose-ecdhe-02

[Göran Selander]

Hi Jim,

Coming back to your previous review, inline below are some comments on how
we took your comments into account. (Some were not applicable with the
change of base protocol.)

Further comments are welcome!

Göran


On 2016-08-31 15:44, "Göran Selander"  wrote:

>Hi Jim,
>
>Thanks very much for good comments, replies inline.
>
>
>On 2016-08-04 00:37, "Ace on behalf of Jim Schaad" on behalf of i...@augustcellars.com> wrote:
>
>>This may be a bit scatterbrained as I did this review in several sessions
>>and the thoughts might not be consistent.
>>
>>1.  In section #1, I would put in the fact that the derived key would
>>only
>>be used for a period of time, after which a new ECDH key exchange would
>>be
>>run again.
>
>Agree.

Put into the security considerations

>
>>
>>2.  It is not clear, but based on how the value of kid_ev is defined, it
>>might be reasonable to state that there is an expectation that generally
>>U
>>will be a client and V a server.
>
>Correct, but there is also the desire to use the context for client and
>server switching roles, and more generally sender and listener in a group.
>This relates to your comments on OSCOAP.

NA

>
>>
>>3.  I would like to see the PSK half of the world setup so that it is not
>>required that the same key/kid pair be used in both directions.  Using a
>>different key in each direction makes things cleaner for some issues.
>>Both
>>cases of the same and different pairs should be permitted.
>
>OK.

We did only different key in each direction as prescribed by the new
protocol.
 

>
>>
>>4.  I see no reason to say that what one is negotiating is a hash
>>function.
>>What you are negotiating is a "Key Agreement w/ KDF" algorithm.  I don't
>>see
>>that you are using the hash function by itself anywhere.
>
>For simplicity changed to negotiation of KDF, OK?


We did go for negotiation of "Key Agreement w/ KDF" algorithm



>
>>
>>5.  In section 2, you should give a reason for including or not including
>>the nonces in the protocol.  Since they are optional when would they be
>>useful?
>
>It is explained in [RFC5869] which is referenced but we can add that.

Nonces are now prescribed by the protocol.

>
>>
>>6. In section 2, do you expect that TCA is restricted to CEK or would MAC
>>algorithms be usable as well?
>
>Changed to "AEAD or MAC".

Considering the use cases, we decided to restrict to AEAD.
>
>>
>>7.  In section 2, I missed where the replay parameter was included in the
>>COSE_Header - it seems to be in the key for party U and non-existant for
>>party V.  The closest that one comes it the use of the message_1
>>signature
>>as AAD.
>
>Yes, replay is mainly an issue for party V.

NA 

>
>>
>>8.  In figure 3, I would prefer to see two different traffic keys being
>>derived.  It is not an issue in Figure 2 as that just says keying
>>material.
>>Using different keying material in each direction prevents reflection
>>attacks.
>
>I think we are just copying TLS 1.3 terminology here. “traffic_secret_0”
>is the “base key” used to derive the different client and server keys you
>request.

NA

>
>>
>>9.  In section 2.1, you talk about authentication methods but do not
>>discuss
>>authorization methods.  Does this need to be built into message_1 or are
>>there other methods that will be functional here.  May need to refer to
>>how
>>some of them might work since this will also potentially affect how the
>>distribution of the keys in advance works.  For example, if an OAUTH
>>token
>>is published to a well-known location that contains both authorization
>>and
>>authentication information.
>
>Good catch. There is a story for how EDHOC works with ACE but we forgot to
>mention it here and make the reference: See figure 1 of
>https://tools.ietf.org/html/draft-seitz-ace-oscoap-profile-00

Done

>
>>
>>10.  In section 3.1, I am not sure that you really want to have only a
>>single algorithm in this specification.  I would make it more generation
>>in
>>terms of how a COSE_Key is built and then have a statement elsewhere
>>rather
>>than spread throughout the document about what algorithms are mandatory
>>to
>>support.
>
>Yes, this was just to be concrete. Good proposal.

We actually only have one mandatory algorithm, so we didn’t change this.

>
>>
>>11.  In section 3.4.2 - I think that you need to have a more
>>comprehensive
>>external_AAD structure that what is here.  I am not sure

[Ace] FW: New Version Notification for draft-selander-ace-cose-ecdhe-04.txt

[Göran Selander]

Dear all,

We have submitted a new version of EDHOC. This version is built on the
SIGMA family of key exchange protocols, thereby aligning with state of the
art security protocols. EDHOC is not bound to protocol layer, but a
binding to CoAP is provided and we show how to integrate it to provide
keys for use with OSCOAP such that key establishment and secure resource
request/response on application layer can fit into 2 round-trips.

Comments are welcome.


Göran


On 2016-10-31 13:03, "internet-dra...@ietf.org" 
wrote:

>
>A new version of I-D, draft-selander-ace-cose-ecdhe-04.txt
>has been successfully submitted by Francesca Palombini and posted to the
>IETF repository.
>
>Name:  draft-selander-ace-cose-ecdhe
>Revision:  04
>Title: Ephemeral Diffie-Hellman Over COSE (EDHOC)
>Document date: 2016-10-31
>Group: Individual Submission
>Pages: 44
>URL:
>https://www.ietf.org/internet-drafts/draft-selander-ace-cose-ecdhe-04.txt
>Status: 
>https://datatracker.ietf.org/doc/draft-selander-ace-cose-ecdhe/
>Htmlized:   
>https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-04
>Diff:   
>https://www.ietf.org/rfcdiff?url2=draft-selander-ace-cose-ecdhe-04
>
>Abstract:
>   This document specifies authenticated Diffie-Hellman key exchange
>   with ephemeral keys, embedded in messages encoded with CBOR and using
>   the CBOR Object Signing and Encryption (COSE) format.
>
>  
>
>
>
>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] [core] Fwd: New Version Notification for draft-tiloca-core-multicast-oscoap-00.txt

[Göran Selander]

Hi Sandeep,

While it is possible to merge the drafts, OSCOAP is already a long draft and we 
preferred to separate the general secure group communication into a separate 
text, which may be applied in other contexts beside the "low latency" setting. 

Göran

> On 12 okt. 2016, at 14:17, Kumar SS, Sandeep  
> wrote:
> 
> I agree with Hannes. The changes need to OSCOAP was quite straightforward and 
> clear from the beginning, we were waiting for OSCOAP to be stable. The minor 
> changes could have been directly taken into OSCOAP with an optional SenderID 
> field. If that is not possible, then it can be done directly in the ACE 
> draft. I do not see any value in an additional draft to solve this minor 
> sub-issue.
> 
> Sandeep
> 
>> -Original Message-
>> From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Hannes Tschofenig
>> Sent: Wednesday, October 12, 2016 1:51 PM
>> To: Göran Selander ; Marco Tiloca
>> ; Ace@ietf.org
>> Subject: Re: [Ace] [core] Fwd: New Version Notification for 
>> draft-tiloca-core-
>> multicast-oscoap-00.txt
>> 
>> Hi Goeran,
>> 
>> there was never any doubt that we can use COSE to design a security
>> solution using the already existing building blocks.
>> 
>> Btw, in the meanwhile we have actually concluded the discussion in ACE on
>> the group communication security topic, see https://www.ietf.org/mail-
>> archive/web/ace/current/msg01967.html
>> 
>> Ciao
>> Hannes
>> 
>> PS: You cannot decouple the question of adoption of
>> draft-somaraju-ace-multicast-01 from the question of source authentication
>> since this was the core issue of the debate.
>> 
>>> On 10/12/2016 01:31 PM, Göran Selander wrote:
>>> 
>>> Hi Hannes,
>>> 
>>> I’m a bit surprised at your reaction. If you have followed the
>>> discussion on OSCOAP you know that one recurring request has been on
>>> support for multicast. This draft is addressing that request.
>>> 
>>> draft-somaraju-ace-multicast-01 is referring to OSCOAP for secure
>>> group communication and we propose this draft to be the way to extend
>>> OSCOAP for that purpose.
>>> 
>>> In the "controversial, long, and tough” discussion you refer to, one
>>> central issue relates to the use of symmetric keys only in group
>>> communication. Our draft mandates the use of asymmetric keys since
>>> that provides source authentication. Should it be agreed that source
>>> authentication for some purpose is not necessary, it is a simple
>>> modification of this draft - simply making the counter signature in
>>> the COSE object non-mandatory.
>>> 
>>> It was our hope that we in this way can decouple the question of
>>> adoption of draft-somaraju-ace-multicast-01 from the question of
>>> source authentication.
>>> 
>>> Göran
>>> 
>>> 
>>> 
>>> 
>>> On 2016-10-12 10:40, "Ace on behalf of Hannes Tschofenig"
>>>  wrote:
>>> 
>>>> Hi Marco, Hi Francesca, Hi Goeran,
>>>> 
>>>> I am a bit surprised about your document submission since you guys
>>>> have been pretty silent in the group communication security
>>>> discussion, which was quite controversial, long, and tough. That's
>>>> where your support would have been needed. Adding the few small bits
>>>> to the already written draft isn't the problem.
>>>> 
>>>> Ciao
>>>> Hannes
>>>> 
>>>>> On 10/12/2016 10:12 AM, Marco Tiloca wrote:
>>>>> Dear CoRE/ACE,
>>>>> 
>>>>> We have submitted a draft on secure group communication for CoAP
>>>>> addressing security for the setting of a multicast CoAP request with
>>>>> unicast responses as described in RFC7390.
>>>>> 
>>>>> This draft builds on the recently updated version of OSCOAP,
>>>>> extended with mandatory Sender ID and multiple Recipient Contexts.
>>>>> It also enables source authentication with asymmetric signatures
>>>>> implemented as counter signatures included with the COSE objects
>> defined by OSCOAP.
>>>>> 
>>>>> We hope that by submitting now we could get some first discussion to
>>>>> allow updates before the cutoff.
>>>>> 
>>>>> This draft provides the missing link between
>>>>> https://tools.ietf.org/html/draft-somaraju-ace-multicast and OSCOAP.
>>>&