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

[Daniel Migault]

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 
mailto:40ericsson@dmarc.ietf.org>>
 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://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


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

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

[Daniel Migault]

great, so I suggest we publish the update before next interim meeting.

Yours,
Daniel

From: Olaf Bergmann 
Sent: Wednesday, February 3, 2021 12:58 PM
To: Francesca Palombini 
Cc: ace@ietf.org ; Benjamin Kaduk ; Daniel Migault 

Subject: Re: [Ace] draft-ietf-ace-dtls-authorize

On 2021-01-29, Francesca Palombini 
 wrote:

> So my preference would update the text in the DTLS profile:
>
> NEW:
>The use of CoAP
>and DTLS for this communication is RECOMMENDED in this profile, other
>protocols fulfilling the security
>requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be
>used instead.

I can live with that.

Grüße
Olaf
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Olaf Bergmann]

On 2021-01-29, Francesca Palombini 
 wrote:

> So my preference would update the text in the DTLS profile:
>
> NEW:
>The use of CoAP
>and DTLS for this communication is RECOMMENDED in this profile, other
>protocols fulfilling the security
>requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be
>used instead.

I can live with that.

Grüße
Olaf

___
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

[Pedro Moreno-Sanchez]

Hello, 

my name is Pedro Moreno-Sanchez. As this is my first post to this list, let me 
give some background about myself. I am the main developer of PANATIKI 
(https://www.mdpi.com/1424-8220/13/11/14888 
), a lightweight version of PANA as 
EAP Lower Layer intended for constrained devices. Moreover, I have also 
implemented the integration mechanism of PANA and PCP as described here 
https://tools.ietf.org/html/draft-ohba-pcp-pana-04 
 and discussed in the 
IETF84 PCP WG (https://www.ietf.org/proceedings/84/slides/slides-84-pcp-3.pdf 
)

I have been recently informed about the call for adoption of the draft 
(https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07 
)
and I am writing this email to express my opinion that I believe this document 
should be adopted. I base this opinion in the following three points:

* I have analyzed the technical details of the draft. I attach my analysis at 
the end of this email. I find the specification technically correct and the 
rationale behind the architecture design well founded. Moreover, the 
specification has taken special consideration on maintaining the requirements 
of an EAP Lower Layer.

* EAP is the standard that has been successfully and widely used for 
authentication in several other scenarios such as 802.1X. Therefore, IMHO 
having EAP-based authentication in ACE is definitely interesting.

* From my experience as the main developer of PANATIKI,  the approach of taking 
a general purpose EAP Lower Layer like PANA (let alone a more complex one) and 
“prune” it to make it compatible to constrained devices is a rather challenging 
task and error prone. The design of CoAP as EAP Lower Layer in this document 
not only has the advantages that (i) CoAP is already suitable for constrained 
devices  and (ii) it fulfills the requirements as EAP Lower Layer; but also the 
fact that the design has been carefully thought with performance in mind and it 
already contains the performance enhancements that we discovered while building 
PANATIKI. 

Best regards,
Pedro Moreno-Sanchez.

===

==

* Architecture: I find the design of the architecture one of the most 
interesting points and yet well-motivated ones. At a first glance, one would 
imagine that EAP peer would be colocated with CoAP client whereas EAP 
authentication would be colocated with CoAP server. However, indeed the fact 
that EAP requests flow from the EAP authenticator highly motivates to co-locate 
it with the CoAP client. Then the EAP peer and CoAP server will be naturally in 
charge of processing incoming requests and create the corresponding responses. 
Perhaps, the only aspect that I am not fully convinced about this architecture 
is that it seems to be the case that the CoAP server needs to discover the CoAP 
client to start the authentication in the first place. If this is the case, the 
CoAP client would need to implement some kind of listening process where 
“discovery requests” are sent, perhaps to a certain IP address and port that 
need to be announced (and standardize?) before, etc. Moreover, I am wondering 
whether such behavior/functionality is part of the standardize description of 
CoAP in the first place. In any case, it would be interesting that authors 
expand on how the CoAP Server discovers the CoAP client and what are the 
possible modifications/consequences of the design of that part.

* Data protected with OSCORE (or DTLS) context: The OSCORE Context is used to 
protect the exchanged data earlier than I was expecting. In particular, the EAP 
Success message is already protected with the key material derived from the 
authentication. This means that the EAP peer should have been able to derive 
the MSK before the arrival of message 7 so that it is able to authenticate such 
message. This situation leads to two questions: (i) Is the EAP success also 
protected when an EAP Lower Layer other than CoAP is used?; and (ii) is it 
possible that the EAP Success (and thus the corresponding ACK can be omitted)? 
In particular, with regards to the latter question, it seems to me that after 
message 6 in Figure 2, whenever the EAP peer receives a message that is 
protected by the OSCORE context, the EAP peer knows that the authentication was 
successful if it can successfully verify the authenticated incoming message. If 
that is the case, then the message 6 can be used to send directly authenticated 
application data instead of the EAP Success. In any case, it would be 
interesting that the authors elaborate in this aspect of their design.

* Comments regarding the use case scenario (Section 5): I find this section 
highly useful and enlightening to bring the proposed design and methodology to 
a real world use case. I have identified two points that I beli