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 <mu...@tislabs.com>
Date: Sat, 6 Feb 2021 16:01:00 -0500
Cc: Russ Mundy <mu...@tislabs.com>,
        Daniel Migault <daniel.miga...@ericsson.com>,
        "draft-ietf-ace-dtls-authorize....@ietf.org" 
<draft-ietf-ace-dtls-authorize....@ietf.org>
To: Olaf Bergmann <bergm...@tzi.org>

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 <bergm...@tzi.org> wrote:
> 
> Hi Russ,
> 
> On 2021-01-19, Olaf Bergmann <bergm...@tzi.org> 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 restrictive. The reason is that the ACE framework generally
> allows for different protocols to be used between the different legs of
> the communication. Usually, the ACE profiles focus specifically on the
> communication between the Client and the Resource Server. Both entities
> may communicate with the Authorization Server to retrieve the required
> information to establish this communication.
> 
> Now, if the CoAP over DTLS was required for the communication between
> the Client and the Authorization Server (or the Resource Server and the
> Authorization Server, respectively), a combinatory number of additional
> specifications was required to enable the Client and the Resource Server
> to use a different protocol for communicating with the Authorization
> Server, e.g. HTTP over TLS.
> 
> We therefore propose the following change, referring to the requirements
> set by the ACE framework document on the security of the communication
> with the Authorization Server:
> 
> OLD:
> 
>  The use of CoAP and DTLS for this communication is RECOMMENDED in this
>  profile, other protocols (such as HTTP and TLS, or CoAP and OSCORE
>  [RFC8613]) MAY be used instead.
> 
> 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.
> 
> Does this resolve your concern?
> 
> Best regards
> Olaf

-------------------- End of forwarded message --------------------

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

Reply via email to