Yes, LGTM On Wed, Mar 24, 2021 at 6:08 AM Göran Selander <[email protected]> wrote:
> Hello Martin, > > Thanks for the review. Please see proposed updates below. > > On 2021-03-21, 06:27, "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! > > [GS] > > The ACE framework (draft-ietf-ace-oauth-authz-38) mandates integrity > protection of access token, and in the case it contains a symmetric key, > encryption: > > 6.1. Protecting Tokens > > "If the access token contains the > symmetric key, this symmetric key MUST be encrypted by the > authorization server so that only the resource server can decrypt it." > > In oscore-profile, the access token is recommended to be CWT which are > COSE objects, but the requirement to encrypt in case the access token > contains the OSCORE master secret should of course be explicitly stated. > Here is a proposed change: > > Section 3.2 > > OLD > "This profile RECOMMENDS the use of CBOR web token (CWT) as specified in > [RFC8392]." > > NEW > "The OSCORE master secret MUST be encrypted by the authorization server so > that only the resource server can decrypt it (see Section 6.1. of > [I-D.ietf-ace-oauth-authz]). This profile RECOMMENDS the use of CBOR web > token (CWT) protected with COSE_Encrypt/COSE_Encrypt0 as specified in > [RFC8392]." > > Does this address the comment? > > Thanks > Göran > > >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
