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

[Martin Duke <[e-mail]>]

Thanks for taking my vague confusion and turning it into constructive
action!

On Sat, Mar 20, 2021, 22:26 Benjamin Kaduk <[e-mail]> wrote:

> 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
>