Hi Martin,
On Thu, Mar 18, 2021 at 11:44:53AM -0700, Martin Duke via Datatracker wrote:
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> In sec 3.1 it says the AS SHOULD reject req_cnf if the key is symmetric. But
> in
> Sec 5 it presents a totally reasonable use case where the C and RS hold a
> previously established (symmetric?) key. These observations are somewhat
> contradictory. Should 3.1 include a qualifier. Would the AS know about this
> key
> a priori so that it can ignore the recommendation? If not, how can this be
> done
> safely?
I think there is a subtle distinction between the two cases, if I am
remembering correctly. In particular, in Section 3.1 it says that "[i]t is
RECOMMENDED that an AS reject a request containing a symmetric key value",
and the last word ("value") is important! This is saying, if the client
tries to propose to the AS the actual symmetric key to be (encapsulated in
the token and) used to secure C/RS communications, the AS typically should
reject it, since a constrained client is likely to have a much worse RNG
than the AS. If, on the other hand, some out-of-band management system has
provisioned a symmetric key shared by C and RS, that key is presumed to be
strong, but in the scenario depicted in Section 5 it is "the key-identifier
of a previously established key between C and RS" that "req_cnf" conveys.
Note that this scenario is only the identifier, not the key value itself.
This is clearly a pretty subtle distinction to make, and if you have any
suggestions for how to word things to make it more obvious, we'd love to
have them.
Thanks,
Ben
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
