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" <ludwig.se...@combitech.se> 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 <francesca.palomb...@ericsson.com>
Sent: den 5 maj 2020 15:37
To: Ace Wg <ace@ietf.org>; Benjamin Kaduk <ka...@mit.edu>; Jim Schaad
<i...@augustcellars.com>
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 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
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
