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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jul 01, 2020 at 10:25:27AM +0200, Olaf Bergmann wrote:
> Hi Jim,
> 
> Jim Schaad <[e-mail]> 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?

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