Re: [Ace] Martin Duke's No Objection on draft-ietf-ace-oscore-profile-17: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Fri, Mar 19, 2021 at 03:39:31PM -0700, Martin Duke via Datatracker wrote:
> Martin Duke has entered the following ballot position for
> draft-ietf-ace-oscore-profile-17: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Sec 4.1. I don't understand how the OSCORE security context is secure. In Sec
> 4.1 it says the C-RS communications need not be protected. But the context is
> fully derived from parameters that go back and forth over this channel. Why
> can't an observer simply compute the OSCORE keys?

The POST to the authz-info endpoint includes just the access_token, nonce1,
and ace_client_recipientid.  I think that your concerns focuus on the
access_token itself, since that is how the various OSCORE security context
parameters are conveyed from AS to RS (via C).  Note that these parameters
need not be conveyed directly in the token, since the token could be an
opaque reference that requires the RS to use token introspection in order
to retrieve the associated parameters.  However, when introspection is not
used, the security context parameters are indeed carried directly in the
token, and this scheme does not provide security in that case unless the
token contents themselves are protected.

It seems (on a quick check, so I might have missed it) that we don't
actually say "you have to use an encrypted or opaque token" (not one that's
only signed) anywhere.  So ... good catch, and thank you!

-Ben