Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

From: Olaf Bergmann <[email-masked]>
Date: Wed, 01 Jul 2020 10:25:27 +0200

Hi Jim,

Jim Schaad <[email-masked]> writes:

> If you are not doing a re-encoding of the token, then I believe that
> preferred serialization and deterministic serialization are going to
> generate the same answer.  With the map being used then this is not
> true, and it is also true that the change in map ordering will hit
> this.

There seems to be agreement on this, and therefore I will change the
text following Carsten's proposal (use bytes for the access_tocken and
state that preferred serialization and deterministic serialization
should be used for the CBOR serialization.

> This is a piece of the document that I have never implemented
> because I just don't believe that this option is a reasonable thing to
> require being done so I missed the fact that the original encoded
> token is not being used.

You haven't missed anything—the intention always was to use the original
encoded token as transferred on the wire. The issue was introduced in
this last unpublished change that should have clarified the
serialization of the data structure that is used as input for the HKDF.

> There is a possible DOS attack by a MITM changing the encoding on the
> token since it is not protected when posted to the RS.

Yes, this is inherent to the upload mechanism and unrelated to key
derivation. My intention is to access-protect the token endpoint in my
implementation such that only authorized clients can upload an access
token.

> If this is going to be changed, I would say use the binary string
> encoding from the bstr of the inner most COSE wrapping layer as the
> input to minimize this.

Now you have lost me. The innermost COSE wrapping layer would be the one
in the contents of the cnf claim, given that we do not invent claims
that also can include COSE structures?

Grüße
Olaf

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 1 Jul 2020 20:12:01 -0700

> that also can include COSE structures?

I think the intention is the "innermost COSE structure protecting the
[entire] access token", to accomodate the fact that the access token might
be COSE_Mac(), COSE_Encrypt(COSE_Mac()), etc., and not necessarily a fixed
number of layers of COSE protection between the access token ciphertext and
the CWT claim set.

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Wed, 1 Jul 2020 21:19:30 -0700

> -----Original Message-----
> From: Olaf Bergmann <[email-masked]>
> Sent: Wednesday, July 1, 2020 1:25 AM
> To: Jim Schaad <[email-masked]>
> Cc: 'Benjamin Kaduk' <[email-masked]>; 'Carsten Bormann' <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
> 
> Hi Jim,
> 
> There seems to be agreement on this, and therefore I will change the text
> following Carsten's proposal (use bytes for the access_tocken and state that
> preferred serialization and deterministic serialization should be used for the
> CBOR serialization.
> 
> > This is a piece of the document that I have never implemented because
> > I just don't believe that this option is a reasonable thing to require
> > being done so I missed the fact that the original encoded token is not
> > being used.
> 
> encoded token as transferred on the wire. The issue was introduced in this last
> unpublished change that should have clarified the serialization of the data
> structure that is used as input for the HKDF.
> 
> Yes, this is inherent to the upload mechanism and unrelated to key derivation.
> My intention is to access-protect the token endpoint in my implementation such
> that only authorized clients can upload an access token.
> 
> Now you have lost me. The innermost COSE wrapping layer would be the one in
> the contents of the cnf claim, given that we do not invent claims that also can
> include COSE structures?

Yes this is the binary string that holds the claims.  It would be possible to have multiple COSE layers - i.e. encrypt and signing layers, and you would want to make sure that you agree on where you are pulling the content.

Using the token itself however is fine and you don't need to try and deal with this.

Jim

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 02 Jul 2020 09:35:46 +0200

Jim, Ben,

[decrypted access_token as HKDF input]

> Yes this is the binary string that holds the claims.  It would be
> possible to have multiple COSE layers - i.e. encrypt and signing
> layers, and you would want to make sure that you agree on where you
> are pulling the content.

I understand. I got a bit confused because when using key derivation,
the access token does not necessarily have to be encrypted.

> Using the token itself however is fine and you don't need to try and deal with this.

Actually, I would prefer that. For some reason, I was under the
impression that the access token needs to be decrypted before key
derivation can be done. Maybe this was in the very first version where
only the kid was used as input.

Grüße
Olaf