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
