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

[Martin Duke <[e-mail]>]

Yes, LGTM

On Wed, Mar 24, 2021 at 6:08 AM Göran Selander <[e-mail]>
wrote:

> Hello Martin,
>
> Thanks for the review. Please see proposed updates below.
>
> On 2021-03-21, 06:27, "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!
>
> [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
>
>
>