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

[Olaf Bergmann <[e-mail]>]

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 <[e-mail]>
Date: Sat, 6 Feb 2021 16:01:00 -0500
Cc: Russ Mundy <[e-mail]>,
        Daniel Migault <[e-mail]>,
        "[e-mail]" <[e-mail]>
To: Olaf Bergmann <[e-mail]>

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 <[e-mail]> wrote:
> 
> Hi Russ,
> 
> On 2021-01-19, Olaf Bergmann <[e-mail]> 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 --------------------