Re: [Ace] AD Evaluation of draft-ietf-ace-mqtt-tls-profile-12

[Benjamin Kaduk <[e-mail]>]

Hi Cigdem,

It seems I have let my todo list get the better of me once again :(
On the grounds of "better late than never", more inline...

On Fri, Dec 10, 2021 at 08:24:07PM +0000, Cigdem Sengul wrote:
> Hello Ben,
> No worries. It's been a very busy period for me as well.
> My responses are below. Thank you, as always, for your feedback.
> 
> On Tue, Dec 7, 2021 at 8:14 PM Benjamin Kaduk <[e-mail]> wrote:
> 
> > Hi Cigdem,
> >
> > Oof, has it really been two months since you sent this?  I am sorry to have
> > let it linger for so long.
> >
> > I've gone through the published -13 and have a handful or two of comments
> > left (which I will send separately), but let me just reply here to a few
> > things first (inline).
> >
> > On Mon, Oct 18, 2021 at 03:23:12PM +0100, Cigdem Sengul wrote:
> > > Hello Ben,
> > > I thought I should comment on your original review to have the same order
> > > you initially planned.
> > > I went through all the comments, and our discussions of it.
> > > The comparison with Editor's copy and github draft is here
> > > <
> > https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-mqtt-tls-profile.txt&url2=https://ace-wg.github.io/mqtt-tls-profile/draft-ietf-ace-mqtt-tls-profile.txt
> > >
> > > .
> > >
> > > In summary, I made the following changes:
> > > (1) Kepts dtls profile informative (going through it, I brought all that
> > > applied to this draft but kept out the ones that didn't apply). For
> > that, I
> > > introduced new sections that explains how we support TLS - PSK and RPK
> > for
> > > client authentication (2.2.3.1 and 2.2.3.2). Aimed to clarify all
> > > TLS-related stuff e.g. added recommended references for using TLS in
> > > constrained environments, followed the cipher suite requirements from
> > these
> > > references.
> >
> > I think I see what you're trying to do here, and it makes sense in a
> > certain way ... but if I go and compare side-by-side the text we have here
> > and what's in the DTLS profile, the DTLS profile goes into a lot more
> > detail.  In particular, the DTLS profile mentions some things that
> > implementations need to do in order to avoid vulnerabilities, and I'm not
> > sure that we want to go into so much detail in this document when it's
> > already recorded elsewhere.  I'm willing to let the document advance to
> > IETF LC and IESG review with this part as-is (but will not be surprised if
> > other reviewers raise the topic), but just wanted to check if there's a
> > particular reason to want the DTLS profile to not be a normative reference.
> > I think I don't understand that part of things very well, so to me there's
> > not much harm in making it a normative reference -- maybe I'm missing
> > something!
> >
> 
> [Cigdem: I wasn't sure if I could make DTLS profile normative when I was
> using TLS, and then there were
> a few MUSTs in the DTLS profile that I felt didn't apply. But, given there
> is a new short draft that says the profile applies to TLS,
> things are in a better place (
> https://datatracker.ietf.org/doc/draft-ietf-ace-extend-dtls-authorize/).

(For what it's worth, I think it's entirely permissible to cherry-pick
specific sections of a normative reference without pulling in the whole
thing.  That is, something like "for <this purpose>, follow the procedures
of Section <X> of <reference>" would not make any dependency on sections
other than <X>.)

> However, I need input on the following issues before I revise to make DTLS
> profile normative, and reorganise the
> sections accordingly based on that change i.e., refer more to DTLS sections
> in the newly introduced sections,
> and shorten them.
> 
> The DTLS profile expectedly talks about CoAp, CBOR, COSE (some examples
> below).
> Also, token expiration is handled differently with MQTT.
> Can those be revised for MQTT-TLS profile?
> "If the "ace_profile" parameter is present, it is set to "coap_dtls".
> "This specification uses CBOR web tokens to convey claims within an access
> token issued by the server."

Yes, we can revise them.  That would be something like "follow the
procedures of [DTLS-PROFILE], with the exceptions that the 'ace_profile'
parameter is set to 'mqtt_tls' and JSON Web Tokens can be used (CBOR Web
Token can also be used)."

> For PSK mode:
> "The authorization server adds a "cnf" parameter to the access information
> carrying a "COSE_Key" object that informs the client about the shared
> secret that is to be used between the client and the resource server. If
> the access token carries a symmetric key, the access
>    token MUST be encrypted using a "COSE_Encrypt0" structure (see section
> 7.1 of [RFC8392])."
> DTLS channel setup:
>  "To do so, it MUST create a "COSE_Key" structure with the "kid" that was
> conveyed in the "rs_cnf" claim in the token response from
>    the authorization server and the key type "symmetric".

Hmm, so this would have to discuss both the JOSE and COSE formulations...

> Token expiration:
> "As specified in Section 5.10.3 of [I-D.ietf-ace-oauth-authz], the resource
> server MUST notify the client with an error response with
>    code 4.01 (Unauthorized) for any long running request before terminating
> the association."
> (The error response for MQTT would be different.)

That should be pretty straightforward to override, but yes.

> Also, for PSK,
> "If a resource server receives a ClientKeyExchange message that contains a
> "psk_identity" with a length greater than zero, it MUST
>  parse the contents of the "psk_identity" field as CBOR data structure"
> I think this is defined differently in TLS with pre_shared_key extension
> etc.
> ]

pre_shared_key vs "psk_identity" is a TLS 1.2 vs 1.3 thing, rather than a
DTLS-profile vs TLS+MQTT profile thing.  We do let the token be transferred
as a PSK identity, though, so maybe we can get away with a generic
statement about "nonempty PSK identities in TLS are used to convey JWT or
CWT tokens".

>  [SNIP]

(It looks like this was all resolved; let me know if I missed something.)

Sorry again for the slow reply.

-Ben