[Ace] Update of access rights

[Francesca Palombini <[e-mail]>]

Hi Ace chairs, DTLS authors, Ace framework authors, Ben,

TL;DR: we propose some changes on the OSCORE profile for the "update of access rights" scenario. We have comments for the DTLS profile and the ACE framework regarding this scenario, and we ask for feedback from ACE OSCORE implementers and Ace in general.

In an attempt to answer Jim's (https://github.com/ace-wg/ace-oscore-profile/issues/20) and Ben's (https://github.com/ace-wg/ace-oscore-profile/pull/30) review of the OSCORE profile, we have been thinking more about the case of updating access rights. This has revealed to us authors that something is missing from the document, and I believe that this part is not explicitly covered in the DTLS profile either, hence this email. 

This is the scenario, and what is currently defined in the OSCORE profile:

1. Client retrieves access token T1 from AS
2. Client posts T1 to RS, together with nonce N1
3. RS replies with 2.01 and nonce N2
4. Client and RS derive OSCORE Sec Ctx "Sec1" from T1 ("osc" object), N1, N2
5. Client uses Sec1 to protect its request to RS
6. RS uses Sec1 to verify request. Verification success => Sec1 is validated and associated with T1 (at the RS)
----
7. Client wants to update its access rights: retrieves T2 from AS. Note that this T2 has different authorization info, but does not contain input keying material ("osc"), only a reference to identify Sec1 ("kid" in "cnf")
8. Client posts T2 to RS, together with nonce N1'
9. RS replies with 2.01 and nonce N2'
10. Client and RS derive OSCORE Sec Ctx "Sec2" from T1 keying input material ("osc" object), N1', N2'
11. Client uses Sec2 to protect its request to RS
12. RS uses Sec2 to verify request. Verification success => Sec2 is validated and associated with T2 (at the RS) ; T1 is removed ; Sec1 is removed

In the document right now, we are missing the exact description of how in 8. RS identifies that this is an update of access rights for C, aiming at replacing T1. We propose to add text stating that (in 3. and 9.) RS MUST check the kid (in the "kid" in the "cnf" of the access token), and match it with existing security contexts, to realize that this is an update for an existing token associated to the sec ctx identified by kid.

Moreover, while comparing with DTLS profile, we realized there is no reason for which 8. should be sent unprotected. In fact, doing so opens up to possible attacks where an old update (token non expired) is re-injected to the RS by an adversary:

* Client sends T1 to RS  --> accepted
* Client sends update of access rights T2 --> accepted
* Client sends update of access rights T3 --> accepted
* Malicious node re-sends T2 --> accepted

Of course that could be mitigated with expiration times and with checking "issued at time" field (which is optional). But we believe even though these are good points (which might actually be worth adding to the framework), sending the token to the RS over the existing protected channel solves this issue. So we propose that 8. is protected with OSCORE and Sec Ctx Sec1. For DTLS authors: I believe Jim has extrapolated from your document that that is the case for the DTLS profile already, i.e. POST token to RS for update of access rights is over DTLS; I think it would be worth explicitly stating that in the DTLS profile.

Additionally, analogously to DTLS where the same channel is kept even if access rights are updated, I do not see any reason at this point to have the endpoints re-derive a new security context. This is the biggest change I propose, and can be summarized by replacing the points above as follows:

7. Client wants to update its access rights: retrieves T2 from AS. Note that this T2 has different authorization info, but does not contain input keying material, only a reference to identify Sec1 
8. Client posts T2 to RS, *without nonce* *protected with Sec1*
9. RS *verifies that this is an update of access right, replacing T1 (associated with Sec1) ; Sec1 is associated with T2; T1 is removed *; RS replies with 2.01 *without nonce* *protected with Sec1*
10. Client uses *Sec1* to protect its request to RS

I can already see the objection from implementers: the authz-info endpoint at the RS becomes accessible both unprotected (in case the Client is posting a token for the first time, points 1. to 6.) and protected (in case Client needs to update rights, points 7. to 10.) I believe that defining a NEW endpoint at the RS for the "update rights" mechanism would be the best solution, but I understand that would require modifications to the framework that Ludwig probably would not want to do, as it might delay the document. I think these would in practice be 2 different endpoints with the same URI, one OSCORE protected and one unprotected. But I need more input from our implementers to know if this absolutely cannot be done.

Our proposal:
An RS receiving a token (point 2 and 8) MUST check the kid of the token against existing security contexts. If a match is found, but the POST was unprotected, reject. If a match is found AND the POST was protected using that same Sec Ctx identified by kid, update access rights. If a match is not found, derive sec ctx as defined before. These 2 endpoints also require different payload: posting the token for the first time unprotected requires a nonce, posting an update using OSCORE does not (and the nonce will be discarded if sent). 

Doing so answers Ben's point about 2 tokens being saved at the RS at the same time, while Sec2 is not yet validated (between 8. and 12. above), since it removes Sec2 altogether. As soon as T2 is verified, T1 can be replaced with T2.

Final point: what happens if the Client posts a second token T2 (to unprotected authz-info) which contains a different "osc" object, different kid etc. The RS will not be able to identify this Client as someone it already has a sec association with, and it will set up a different Sec Ctx with it. I think this is OK, as for it to be accepted, the AS had to provide such a token. The framework RECOMMENDS that an RS stores only one token per proof-of-possession key, which would still be valid, as different tokens would be associated to different Sec ctxs.

Any feedback or comment is appreciated. 

Thanks,
Francesca