Subject: [Ace] Update of access rights

From: Francesca Palombini <[email-masked]>
Date: Tue, 5 May 2020 13:36:41 +0000

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

---

From: Seitz Ludwig <[email-masked]>
Date: Tue, 5 May 2020 14:06:51 +0000

Hello Francesca,

I have not followed this discussion in detail so excuse me if I missed an important detail. That said: I cannot understand why you would want to negotiate a new context in step 8 by sending N1'? At that point you have a functional OSCORE context established and could just send T2 associated to the same context Sec1. That is how I assumed it would work, if that is not clear we need to add text to the profiles to clarify.

It is a bit complicated code-wise to have an endpoint that is accessible both unprotected and with OSCORE, but I think it is feasible (however not be my in the ACE-Java codebase, @Marco?).

/Ludwig

-----Original Message-----
From: Francesca Palombini <[email-masked]> 
Sent: den 5 maj 2020 15:37
To: Ace Wg <[email-masked]>; Benjamin Kaduk <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Update of access rights

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

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

Our proposal:

Thanks,
Francesca

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 5 May 2020 14:13:39 +0000

Hi Ludwig,

What you state is in fact the change proposed below, I'm happy you support making this change. The reason why it does not work that way already is because of the way authz-info is defined for the "general" case (exchange of nonces is necessary, and derivation of sec ctx). The change I am making suggests to differentiate processing between this general case and the update case, but doing so without reaching a different endpoint, (which in my opinion would have been the cleaner solution) might be slightly annoying for implementers, as you also mention.

Francesca

On 05/05/2020, 16:07, "Seitz Ludwig" <[email-masked]> wrote:

    Hello Francesca,

    /Ludwig

    -----Original Message-----
    From: Francesca Palombini <[email-masked]> 
    Sent: den 5 maj 2020 15:37
    To: Ace Wg <[email-masked]>; Benjamin Kaduk <[email-masked]>; Jim Schaad <[email-masked]>
    Cc: [email-masked]; [email-masked]
    Subject: Update of access rights

    In an attempt to answer Jim's (https://protect2.fireeye.com/v1/url?k=17a4fe0f-49044461-17a4be94-86b1886cfa64-00f9c0b2a1a8d8cb&q=1&e=8a619c43-1ab6-414f-b576-6511488153e9&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fissues%2F20) and Ben's (https://protect2.fireeye.com/v1/url?k=371c3a3f-69bc8051-371c7aa4-86b1886cfa64-9410fc645a865781&q=1&e=8a619c43-1ab6-414f-b576-6511488153e9&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fpull%2F30) 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. 

    Our proposal:

    Thanks,
    Francesca

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 May 2020 12:01:02 -0400

Francesca Palombini <francesca.palombini=[email-masked]> wrote:
    > 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"

Is there an assumption that the access rights(T2) >= access rights(T1)?

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

I agree and I see your point.
Thank you for explaining it so well.

My question is whether step 8 results in Sec Ctx sec1 being deleted?
Could Client want to keep it alive in the case that T1 and T2 actually do
different things?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 5 May 2020 17:35:51 +0000

Hi Michael,

On 05/05/2020, 18:01, "Ace on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

FP: No. But at the same time if access rights(T2) is a subset of access rights(T1), then there is no point in the client requesting T2 from the AS... These could be a disjoint sets of access rights.

FP: Thank you! I tried to be as clear as possible :)

FP: As currently defined in the document, yes, Sec1 ends up being deleted as soon as Sec2 is validated (i.e. a request is correctly decrypted by the receiving endpoint using Sec2). If T1 and T2 do different things and the client wants to (and is allowed to - T1 is not expired or revoked for some reason) keep T1 alive, then we are not in the case of "update of access rights", i.e. the case where T2 replaces T1. My "Final point" was to cover exactly the case you mention, where T1 and T2 are used to derive 2 different security contexts, where the RS does not realize they come from the same Client. It is up to the AS to make sure that T1 and T2 are disjoints: why would the AS even send 2 different tokens that cover part of or the entire same scope at the same RS to the same client? By the way, if it is not already in there, I think that that is another excellent consideration point for the Ace framework.

Thanks,
Francesca

    ]     [email-masked]     [

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 May 2020 11:58:22 -0400

Francesca Palombini <[email-masked]> wrote:
    mcr>     Is there an assumption that the access rights(T2) >= access
    mcr> rights(T1)?

    > FP: No. But at the same time if access rights(T2) is a subset of access
    > rights(T1), then there is no point in the client requesting T2 from the
    > AS... These could be a disjoint sets of access rights.

There are some cases here.

T2 is a superset of T1.  Everything makes sense.
T2 is a subset of T1.    I to think about this.
T2 is complete disjoint of T1.
T2 is the union of a subnet of T1, and some new set of rights T2B.
   That is, partial overlap, but T2 not superset of T1.

    > FP: As currently defined in the document, yes, Sec1 ends up being
    > deleted as soon as Sec2 is validated (i.e. a request is correctly
    > decrypted by the receiving endpoint using Sec2). If T1 and T2 do
    > different things and the client wants to (and is allowed to - T1 is not
    > expired or revoked for some reason) keep T1 alive, then we are not in
    > the case of "update of access rights", i.e. the case where T2 replaces
    > T1. My "Final point" was to cover exactly the case you mention, where
    > T1 and T2 are used to derive 2 different security contexts, where the
    > RS does not realize they come from the same Client. It is up to the AS
    > to make sure that T1 and T2 are disjoints: why would the AS even send 2
    > different tokens that cover part of or the entire same scope at the
    > same RS to the same client? By the way, if it is not already in there,
    > I think that that is another excellent consideration point for the Ace
    > framework.

Client could be vaguely "multi-tenant", having a common security substrate.
That's why there could be 2 different tokens.

Think intelligent speakers that can learn "skills".

One skill operates the stereo, and wants to adjust living room lighting for
appropriate mood. (/me deletes off-colour joke about South Park)

The other skill is the sleep aid, and just wants to dim all lights to near
darkness, but should not operate stereo.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 9 May 2020 20:56:15 -0700

Hi Francesca,

Thanks for assembling this very nice writeup: I think it's quite helpful
to get clarity, given that Ludwig thought this was already the case but I
couldn't come to that conclusion based on my review of the document.

I just have one (maybe nitpicky) comment: when identifying things by 'kid'
we have to account for the possibility of collisions, so probably we should
talk about the "same key".  Assuming I've retained correctly Jim's
teachings, at least...this one I've had trouble with :)

Thanks again,

Ben

---

From: Jim Schaad <[email-masked]>
Date: Sun, 17 May 2020 20:21:35 -0700

I have not had a chance to think this out and get all of the implications
right, but my understanding is that what we were trying to avoid was having
the same secret key/public key present on the RS in more than one token.
This simplifies what the RS needs to do.  However, I am now under the
impression that having the RS deal with multiple tokens with the same public
key might be less of an issue than trying to make some decisions on what
tokens are supposed to supersede other tokens.

One of the ways that this might be avoided is to push the problem to where
it, in some sense, belongs.  The AS should be able to make this type of
decision if a token is supposed to replace an existing token or not and it
has more knowledge about what tokens are associated with what keys.  If we
go back and say - the AS should include a CWTID in the token and then define
a new claim which says - This token supersedes the token(s) with CWTID
values of "x", "y" and "z".  

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 18 May 2020 08:32:21 +0200

Hi Jim,

Jim Schaad <[email-masked]> writes:

> define a new claim which says - This token supersedes the token(s)
> with CWTID values of "x", "y" and "z".

Isn't this the same as token revocation with all its implications?  I
would prefer strict token ordering combined with a sound revocation
mechanism. In both scenarios, you would still have the issue that the
client forwards the superseding token/revocation message if it has a
benefit from doing so.

Grüße
Olaf

---

From: Seitz Ludwig <[email-masked]>
Date: Mon, 18 May 2020 06:48:59 +0000

Hi Jim,

This sounds over-engineered to me. 

If we go for introducing new claims (or putting requirements on existing ones like 'cti'), I would suggest to EITHER

Use the solution recommended in the framework today: One token per pop-key, new token overwrites old token, adding a strict ordering, e.g. by requiring that the
AS uses a incremented number in the cti claim (or a new claim if we don't want to use cti for that).  This would introduce part of what Olaf suggested, i.e. a strict ordering.

OR 

Go with Olaf's full suggestion and introduce a revocation mechanism.

/Ludwig

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: den 18 maj 2020 05:22
To: 'Francesca Palombini' <[email-masked]>
Cc: 'Ace Wg' <[email-masked]>
Subject: Re: [Ace] Update of access rights

I have not had a chance to think this out and get all of the implications right, but my understanding is that what we were trying to avoid was having the same secret key/public key present on the RS in more than one token.
This simplifies what the RS needs to do.  However, I am now under the impression that having the RS deal with multiple tokens with the same public key might be less of an issue than trying to make some decisions on what tokens are supposed to supersede other tokens.

One of the ways that this might be avoided is to push the problem to where it, in some sense, belongs.  The AS should be able to make this type of decision if a token is supposed to replace an existing token or not and it has more knowledge about what tokens are associated with what keys.  If we go back and say - the AS should include a CWTID in the token and then define a new claim which says - This token supersedes the token(s) with CWTID values of "x", "y" and "z".  

Jim

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

---

From: Jim Schaad <[email-masked]>
Date: Mon, 18 May 2020 06:13:18 -0700

As I said, I have not fully thought it out.  A better way to state this might be - this token uses the same key as rather than implying overriding.

-----Original Message-----
From: Olaf Bergmann <[email-masked]> 
Sent: Sunday, May 17, 2020 11:32 PM
To: Jim Schaad <[email-masked]>
Cc: 'Francesca Palombini' <[email-masked]>; 'Ace Wg' <[email-masked]>
Subject: Re: [Ace] Update of access rights

Hi Jim,

> with CWTID values of "x", "y" and "z".

Isn't this the same as token revocation with all its implications?  I would prefer strict token ordering combined with a sound revocation mechanism. In both scenarios, you would still have the issue that the client forwards the superseding token/revocation message if it has a benefit from doing so.

Grüße
Olaf