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

From: Marco Tiloca <[email-masked]>
Date: Mon, 14 Mar 2022 10:01:34 +0100

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 
> [email-masked]. Se varför det är viktigt 
> <http://aka.ms/LearnAboutSenderIdentification>
> 	
>
> 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 to use as reference point.

NEW:
With the combination ... not empty, but that one or more series items 
have been lost due to their removal. These include the item with 'index' 
value P+1, that the requester wished to obtain as the first one 
following the specified reference point with 'index' value P.

* Current fourth bullet point

OLD:
If the series item X with 'index' having value P is found in the 
collection associated with the requester, 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 i) the series item X with 'index' having 
value P is found in the collection associated with the requester; or ii) 
the series item X is not found and the series item Y with 'index' having 
value P+1 is found in the collection associated with the requester.

<==

>
>
>
> 3. Messages format
>
> In the third mode (Appendix B), the AS returns a CBOR map within 2.05 
> Responses, while in full query mode (Section 5.1) and diff query mode 
> (Section 5.2) the AS returns a CBOR array.
> However, if the third mode is used, the 2.05 Content Responses to both 
> full query and diff query mode requests are CBOR maps (Appendix B.2 
> and B.4).
>
> Consider having a 2.05 payload in any mode to be a CBOR map under the 
> content format application/ace-trl+cbor independently of the support 
> of the third mode.
>
> If the AS (and/or the requester) does not support the third mode, the 
> 2.05 Content Response to a full query request could be a CBOR map 
> containing only the ‘trl’ parameter with value the CBOR array of token 
> hashes (the ‘cursor’ parameter is not included).
> The same applies to the diff query mode, where the CBOR map would 
> contain the ‘diff’ parameter with value the CBOR array of diff entries.
> This results in two bytes overhead compared to the current solution, 
> i.e., the transmission of the CBOR array only.
>
> Note that error handling would introduce a reason to support a content 
> format based on maps. If so, the requester should already be capable 
> of processing CBOR maps.

==>MT
That's good input; I think we can go for something in between that and 
the current text, thus trying to avoid CBOR maps unless the AS actually 
uses the cursor pattern.

Here's how this can become in the next revision. This is also summarized 
in the "TODO" note at the beginning of Appendix B.

* We don't have to think of an actual "third mode"; what is now in 
Appendix B is really the diff-query mode defined in Section 7, with the 
additional use of the cursor pattern. Hence, I was planning to move its 
content to the document body.

    Indeed, an AS using the cursor pattern results in enhanced responses 
for both the full-query and diff-query mode (defined in Sections 6 and 
7), where the 'cursor' parameter would additionally be specified. This 
is not a problem for a Client/RS not supporting the cursor pattern 
itself, as it would simply ignore that parameter when present in a 
response from the TRL endpoint.

* Based on the previous point, responses can be formatted as follows.

    - Error responses from the TRL endpoint always have a CBOR map as 
payload, which is actually already the case.

    - If the AS supports the diff-query mode and specifically the use of 
the cursor pattern, then the AS sends all the successful responses from 
the TRL endpoint with a CBOR map as payload [0]. The content of the CBOR 
map is as specified in the current Appendix B.2 and Appendix B.4, which 
can be moved to new subsections under the current Sections 6 and 7, 
respectively.

    - If the AS does not support the cursor pattern, then the AS sends 
all the successful responses from the TRL endpoint with a CBOR array as 
payload. The content of the CBOR array is as already specified in the 
current Sections 6 and 7.

[0] An exception can apply when sending a response exactly to a 
Client/RS that the AS knows to not support the cursor pattern (e.g., 
this could have been indicated during the device original registration 
procedure at the AS). A response to that particular Client/RS can simply 
include a CBOR array as payload, just like when the AS does not support 
the cursor pattern itself.

    Actually, with such a knowledge about the Client/RS, an AS 
supporting the cursor pattern should not use it with that Client/RS in 
the first place, since the Client/RS would not be able to resume a 
transfer from where interrupted anyway.

Thanks again!
<==

>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)