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

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 19 Mar 2021 15:39:31 -0700

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?

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 20 Mar 2021 22:26:40 -0700

> https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/

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

---

From: Martin Duke <[email-masked]>
Date: Sun, 21 Mar 2021 09:31:29 -0700

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

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

> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Göran Selander <[email-masked]>
Date: Wed, 24 Mar 2021 13:08:33 +0000

Hello Martin, 

Thanks for the review. Please see proposed updates below.

On 2021-03-21, 06:27, "Benjamin Kaduk" <[email-masked]> wrote:

[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

---

From: Martin Duke <[email-masked]>
Date: Thu, 25 Mar 2021 11:43:12 -0700

Yes, LGTM

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

> 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
>
> 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
> "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]."
>