Thanks for taking my vague confusion and turning it into constructive action!
On Sat, Mar 20, 2021, 22:26 Benjamin Kaduk <[email protected]> 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 >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
