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.



Best,
/Marco

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

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.

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 <http://aka.ms/LearnAboutSenderIdentification>

        

Hi all,



Best,
Marco


1. Unhandled cursor value out of bounds

In Appendix B.4.3, there is one unhandled case:

That is, the requester specifies an out-of-bound index.




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

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

Please, see below my comments to draft-ietf-ace-revoked-token-notification-00. The AS receives a request with P > MAX_INDEX, where MAX_INDEX is the index of the latest TRL update for the requester. 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).  2. Send a 2.05 CONTENT Response, specifying within the CBOR map the parameters: 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



* Current third bullet point

OLD:


NEW:



* Current third bullet point

OLD:


NEW:



* Current fourth bullet point

OLD:


NEW:


<==

Indeed, thanks! I've made the following three changes, so the text should now correctly address also the two corner cases you mention. 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. 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). 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. 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. 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. 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








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













Thanks again!
<==

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.    - 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.

_______________________________________________
Ace mailing list
Ace@ietf.org
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)

OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key

OpenPGP_signature
Description: OpenPGP digital signature

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