Hi Michael,
On 05/05/2020, 18:01, "Ace on behalf of Michael Richardson"
<[email protected] on behalf of [email protected]> wrote:
Francesca Palombini <[email protected]>
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
[
] [email protected] [
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
