Re: [Ace] Update of access rights
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 Sent: Sunday, May 17, 2020 11:32 PM To: Jim Schaad Cc: 'Francesca Palombini' ; 'Ace Wg' Subject: Re: [Ace] Update of access rights Hi Jim, Jim Schaad 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
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 On Behalf Of Jim Schaad Sent: den 18 maj 2020 05:22 To: 'Francesca Palombini' Cc: 'Ace Wg' 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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Hi Jim, Jim Schaad 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 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
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 Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
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
On Tue, May 05, 2020 at 01:36:41PM +, Francesca Palombini wrote:
> 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 ac
Re: [Ace] Update of access rights
Francesca Palombini 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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Hi Michael,
On 05/05/2020, 18:01, "Ace on behalf of Michael Richardson"
wrote:
Francesca Palombini
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)?
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.
> 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.
FP: Thank you! I tried to be as clear as possible :)
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?
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
--
] Never tell me the odds! | ipv6 mesh
networks [
] Michael Richardson, Sandelman Software Works|IoT architect
[
] m...@sandelman.ca [
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
Francesca Palombini 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 [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Update of access rights
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" wrote:
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
Sent: den 5 maj 2020 15:37
To: Ace Wg ; Benjamin Kaduk ; Jim Schaad
Cc: draft-ietf-ace-dtls-author...@ietf.org;
draft-ietf-ace-oscore-prof...@ietf.org
Subject: Update of access rights
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://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.
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 OSC
Re: [Ace] Update of access rights
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
Sent: den 5 maj 2020 15:37
To: Ace Wg ; Benjamin Kaduk ; Jim Schaad
Cc: draft-ietf-ace-dtls-author...@ietf.org;
draft-ietf-ace-oscore-prof...@ietf.org
Subject: Update of access rights
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.
C
