Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11

[Benjamin Kaduk]

Hi Linda,

On Sun, Jul 19, 2020 at 08:16:17PM -0700, Linda Dunbar via Datatracker wrote:
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any other
> last call comments.
> 
> This document describes how to set specific parameters in using  the
> Authentication and Authorization for Constrained Environments (ACE) framework
> [I-D.ietf-ace-oauth-authz]. The document is written clear, except some minor
> issues:
> 
>  Section 4.1.1 states that Nonce Parameter must be sent from the client to RS.
>  What would be the problem if the client doesn't include the "NONCE"?

There's a little more discussion of the N1 in the previous section, but in
essence, this nonce is required to protect the client against replayed
responses.  Since the token contents (including key derivation material)
would be unchanged across security contexts, the nonce is used to make each
one different; it has to be client-generated so that the client is sure
that this security context is "fresh" (vs. replayed).

> Page 12: It asks RFC editor to validate the numbers listed in Figure 7.  There
> is no explanation or comments for those values. It will be very difficult for
> RFC editor to validate. It seems to me there are 4 columns but  I can't
> understand the meaning of the values under 1st, 2nd, and 3rd columns.

I think this is just a note that the RFC Editor should make sure that
someone has checked the values (i.e., the authors).  The RFC Editor does
not need to be the one actually doing the checking.

Thanks for the review,

Ben

> it is kind of difficult to validate the correctness by just reading through 
> the
> document.  It would be better to have an implementation report of the proposed
> "Profile".
> 
> Best Regards,
>  Linda Dunbar
> 
> 
> 

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

Re: [Ace] Genart last call review of draft-ietf-ace-oscore-profile-11

[Benjamin Kaduk]

On Tue, Jul 21, 2020 at 03:56:07PM -0700, Elwyn Davies via Datatracker wrote:
> Reviewer: Elwyn Davies
> Review result: Almost Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-ace-oscore-profile-11
> Reviewer: Elwyn Davies
> Review Date: 2020-07-21
> IETF LC End Date: 2020-07-20
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:  Almost ready.  There is one minor issue that needs sorting out and a
> fair number of nits.  Overall I have to say that I found it difficult to keep
> clear in my mind what messages were fully encrypted and which ones were sent 
> en
> clair and which are in some intermediate class.  The authors might wish to go
> back over the document from the point of a naive reader to ensure that it is
> clear for implementers.
> 
> Major issues:
> None
> 
> Minor issues:
> s2, para 5:  Where does the 'input salt' come from?  The term is not used
> anywhere else in this document and  isn't defined or mentioned in either
> dreft-ace-oauth-authz or RFC 8613.

Hmm, it looks like this was introduced in the -09 as a result of one of my
review comments (as the formulation in the -08 implicitly had the name
"Master Salt" refer to both the string with and without N1+N2).  I think I
forgot enough of how this works that the authors will need to chime in with
an appropriate clarification of where the original ("input") salt comes
from.

Thanks for spotting that (as well as the other comments),

Ben

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