Re: [Ace] Lars Eggert's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)

[Benjamin Kaduk]

On Thu, Mar 10, 2022 at 12:27:49AM +, Cigdem Sengul wrote:
> On Mon, 7 Mar 2022 at 09:31, Lars Eggert via Datatracker 
> wrote:
> 
> >
> > Found terminology that should be reviewed for inclusivity; see
> > https://www.rfc-editor.org/part2/#inclusive_language for background and
> > more
> > guidance:
> >
> >  * Term "master"; alternatives might be "active", "central", "initiator",
> >"leader", "main", "orchestrator", "parent", "primary", "server".
> >
> 
> [CS:  I would like to indeed avoid this work, but it appears as a result of
> using "Extended Master Secret".
>  Has this been replaced with an alternative?]

It looks like it's in the process of being renamed to
"extended_main_secret" (per draft-ietf-tls-rfc8446bis, work-in-progress).

-Ben

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

Re: [Ace] Review of draft-ietf-ace-revoked-token-notification-00

[Marco Tiloca]

Hi Marco,

Thanks a lot for this review! Please find my replies in line.

Most of your comments have been addressed in the latest version -01.

On your last comment, I thought of a slightly alternative proposal, 
which takes into account whether the AS supports the cursor pattern or 
not. This change can be done together with merging the current Appendix 
B into the document body, which I plan for the next revision of the draft.


Best,
/Marco

On 2022-02-18 15:30, Marco Rasori wrote:



Vissa som fått det här meddelandet får inte ofta e-post från 
marco.ras...@iit.cnr.it. Se varför det är viktigt 




Hi all,

Please, see below my comments to 
draft-ietf-ace-revoked-token-notification-00.


Best,
Marco


1. Unhandled cursor value out of bounds

In Appendix B.4.3, there is one unhandled case:
The AS receives a request with P > MAX_INDEX, where MAX_INDEX is the 
index of the latest TRL update for the requester.

That is, the requester specifies an out-of-bound index.
I believe that this should be treated as a malicious activity as the 
requester deliberately chooses an index value with no rationale at all.


Differently —and as already addressed in B.4.3— if the requester 
specifies as cursor value a positive integer L lower than the minimum 
index that the AS has available, we may assume that the series with 
index L has been removed from the history of updates for that requester.
This request is considered legit and is handled elegantly (‘diff’: 
empty CBOR array; ‘cursor’: Null; ‘more’: True).


However, if P > MAX_INDEX, I see two options for the AS response:
 1. Send a 4.00 BAD REQUEST Response to the requester; or
 2. Send a 2.05 CONTENT Response, specifying within the CBOR map the 
parameters:

    - ‘diff’: empty CBOR array;
    - ‘more’: False.

Since the requester specified a cursor value on no basis, I believe an 
error should be returned.


The 4.00 Response could have the content format 
application/ace-trl+cbor and include:
 - ‘error’: with value an integer indicating the class of error, e.g., 
INVALID_CURSOR_PARAMETER
 - ‘error_description’: optional, with value a text string giving more 
details
 - ‘cursor’: with value a positive integer indicating the index of the 
latest trl update for the requester (MAX_INDEX), or Null if the 
history of updates for the requester is empty.
This would require registering ‘error’ and ‘error_description’ as 
additional parameters under the content format application/ace-trl+cbor.


==>MT
Yes, that is now handled as a bad request from the Client/RS. In particular:

* Appendix B.0 now defines LAST_INDEX (i.e., what you referred to as 
MAX_INDEX), see the fourth from last paragraph.


* The bad input you mention is now handled in Appendix B.4.3, see the 
current second bullet point. The response is a 4.00 (Bad Request). As to 
the 'error' value for this particular case, I named it "Out of bound 
cursor value".


* The 'error' and 'error_description' parameters used in the response 
have been registered, see Sections 11 and 14.3.


* As related to this and other comments, a new IANA registry has also 
been defined, aimed to include values for the 'error' parameter. See 
Sections 12 and 14.4.

<==





2. Off-by-one error

Again, in Appendix B.4.3, I think I found two corner cases that have 
to be addressed. Let the requester specify P as cursor value:


 i) The oldest TRL update at the AS for the requester is the series 
item having value P+1.
The AS should consider this request legit and return the series items 
starting from P+1.


 ii) The latest TRL update at the AS for the requester (MAX_INDEX) is 
the series item having value P.
The AS should consider this request legit and return a combination of 
parameters to signal the requester that it does not have series more 
recent than P to send.


==>MT
Indeed, thanks! I've made the following three changes, so the text 
should now correctly address also the two corner cases you mention.



* Current third bullet point

OLD:
If no series item X with 'index' having value P is found in the 
collection associated to the requester, then that item has been 
previously removed from the history of updates for that requester (see 
Appendix A).  In this case, the Authorization Server returns a 2.05 
(Content) diff query response.


NEW:
The Authorization Server returns a 2.05 (Content) diff query response 
formatted as follows, in case the series item X with 'index' having 
value P and the series item Y with 'index' having value P+1 are both not 
found in the collection associated with the requester. This occurs when 
the item Y (and possibly further ones after it) has been previously 
removed from the history of updates for that requester (see Appendix A).



* Current third bullet point

OLD:
With the combination ... not empty, but that some series items have been 
lost due to their removal, including the item with 'index' value P that 
the requester wished