Subject: [Ace] draft-ietf-ace-mqtt-tls-profile connections

From: Jim Schaad <[email-masked]>
Date: Sat, 18 May 2019 22:41:04 -0700

I am having a problem understanding the flow of authentication.  This may
just be a problem with my preconceptions, but in that case it still needs to
get clarified in the document.

* So as a client I get a token from the AS.  For the first run, assume that
it has a RPK in it.
* I now connect to the server using TLS.  
   	Question #1 - Am I doing client authentication at this point in TLS?
This is what is happening for all of the current profiles, but it is not
clear that this is happening for this profile.  The answer appears to be
both yes and no.

* The connect message holds the token and an authentication value.  The
sentence starting "The client MAY apply ..." in the next to last paragraph
is totally confusing.  Do I get a choice to create a value or not?  Do I get
a choice as to which method I use (which would seem to be dictated by the
token type and not by client choice).

* I am flummoxed by the statement that there is sufficient randomness in the
payload when authenticating.  I presume that all that is being used for the
authentication input is the CONNECT message.  Given that the exact same
input would be used for two different logons, I do not understand how this
could be the case.  Impersonation would seem to be an issue in the event
that the connect message is ever captured (including by the server).  I
would strongly suggest that there is a requirement to include a value from a
tls-exporter to tie the authentication to a specific session.

*  Appendix B says that the broker will accept MQTT PUBLISH messages, does
it have to do a connect before doing the publish or not?  If the connect is
required then what is used for authentication?

Jim

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 21 May 2019 21:35:03 +0100

Thank you for your comments.  I see that we tried to cover too many options
in the draft, and things got mixed up. I tried to clarify inline.

> clear that this is happening for this profile.  The answer appears to be

The basic method we were thinking:

   1. We have not assumed client-side certificates for authenticating
   clients during TLS handshake. RS uses a server-side certificate.
   2. After the TLS session is set-up, the client passes token and
   authentication data inside the CONNECT message.
   3. RS does proof-of-possession for a key owned by the client - so, RS
   authenticates the token.
   4. From MQTT point of view, the clean session flag in the CONNECT
   indicates, there is no session state. The CONNECT payload includes a Client
   id, this should be sufficiently random (not explained clearly in the
   current draft) and unique across clients.
   5. From ACE point of view, we assumed the client has registered with the
   AS, has established keys; the RS has registered with the AS, has
   established keys. So, using PoP, the RS checks that the client has
   authenticated with AS and was able to acquire a token.

In addition to this,  we state other options in the draft as well: the
client and the RS can use the keys in the token to set-up the TLS session
(then the token is not in CONNECT message, and may need to be pushed via
“authzinfo”)

I checked how client authentication is done in other profiles. I see that
draft-ietf-ace-coap-est has “authentication of the client MUST be with a
client certificate”.  In draft-ietf-ace-oscore-profile/ C-RS authentication
is done implicitly by the possession of a common OSCORE security context.
The latter is closer to what we were trying to achieve.

> token type and not by client choice).

That is a mistake - the MAY should have been removed (in an earlier version
of the draft, it stated that “MAY apply it to entire or part of the CONNECT
message”).
Indeed the choice of symmetric/asymmetric would depend on the token type.

> tls-exporter to tie the authentication to a specific session.

It is because we assumed that client ids (23B) in the CONNECT payload would
provide randomness. We do not keep session state (clean session flag is set
across different connects) and hence, there is no incentive for client ids
to be consistent across network sessions. But, you are right, a client may
still repeat client ids across different CONNECTs or it may not select
sufficiently random ids, and an attacker may be able to push the same token
if it was able to capture it.
Will remove the MAY part and add your suggestion to the draft.

> required then what is used for authentication?
This is the part where we have tried to incorporate autzinfo - taking our
cue from the core draft, we have not assumed that it can be protected - so
no, authentication. Not very comfortable about this - so, open to
suggestions for fixes.

Before publishing or subscribing anything, clients still need to CONNECT.
If they publish to authzinfo - the payload contains a token (as usual
encrypted for RS by the AS). So, I guess, an attacker may try to push a
token that it captured.  But to use it, it will need to disconnect, connect
with TLS, and do PoP.

We definitely need to put more clarifications and fix the randomness issue
in the next iteration.

Please let me know if I have missed or misunderstood something.

 --Cigdem

>
>
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace
>

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 23 May 2019 08:28:51 +0200

On 21/05/2019 22:35, Cigdem Sengul wrote:
> Thank you for your comments.  I see that we tried to cover too many 
> options in the draft, and things got mixed up.I tried to clarify inline.
> 

One quick question: If I understand it correctly there is a variant of 
MQTT using UDP (MQTT-SN). Since TLS and TCP are not exactly 
"constrained-friendly", would it make sense to look at that as well to 
define a "MQTT-SN-over-DTLS-based" profile?

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Cigdem Sengul <[email-masked]>
Date: Thu, 23 May 2019 09:33:44 +0100

Hello Ludwig,

This was MQTT-SN-over-DTLS was on our agenda when first we started out.
However, at that time there was not much take-up of MQTT-SN  in practice
(not sure that changed). If there is sufficient interest in the group,
would make sense to do that as well, and theoretically, it would be a more
natural fit to ACE.
Thanks,
--Cigdem