Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile

[Jim Schaad]

 

 

From: Cigdem Sengul  
Sent: Thursday, May 23, 2019 4:21 AM
To: Jim Schaad 
Cc: draft-ietf-ace-mqtt-tls-prof...@ietf.org; ace@ietf.org
Subject: Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile

 

Thank you, Jim, for the comments. 

I have created issues corresponding to each one in the GitHub repository. 

 

We will start working on them, and specifically clarify the issues 1-3 around 
the CONNECT message. 

 

For 4, MQTT v5 can support a challenge-response; not possible with v3 indeed. 
Will expand the security considerations section on that. 

 

5.  We described a convention in the draft with SHOULD. Do we turn that into a 
MUST? 

 

[JLS] I missed this somehow.  What is there is fine.

 

6. We thought that the AS would dictate the token expiration time. It can also 
be done that RS times out tokens even if they have not expired. But, 
security-performance trade-off should be considered. 

Token caching is important even if the token does not need introspection. The 
only time the MQTT client can push a token is with the CONNECT message (all 
subsequent publish/subscribe messages rely on this). In MQTT v5, a client can 
push a new token via reauthentication during an ongoing session (enabled by 
MQTT v5). If RS times out the token, this means a disconnection in MQTT v3. We 
mention this  in Security considerations as "it is expected that AS follows a 
reasonable expiration strategy for access tokens" 

 

-->There may be workarounds designed especially MQTT v5 which has better 
support for request-response style communication. But need to think about it. 

 

[JLS] For introspection, but not for a published token, the token could be 
“revoked” by the RS.  In this case a new introspection check would lead to that 
information.  There may be ways to deal with this in the introspection dialog 
and not need to be called up here.  The question would be does the exi field 
mean – recheck the token or discard the token.  

 

Jim

 

 

7. That is correct. Will add the clarification. 

 

Thanks,

--Cigdem 

 

 

 

 

On Wed, May 22, 2019 at 10:58 PM Jim Schaad mailto:i...@augustcellars.com> > wrote:

Thanks for the updates from my last message.  This has helped quite a bit.

1.  A discussion of the use of raw public keys rather than certificates for
the server may be in order.  This can refer to the same RPK issues from the
current DTLS document.  It may also be that this just uses normal
certificate processing and that should be noted as well, but some discussion
of deciding if the subject name/alt name matches the token returned from the
AS.

For the connect message there are a couple of issues that need to be thought
about.

2.  What items are required to be in the connect message.  The response to
my last message suggested that a client identifier is required to be present
but that is not documented.

3.  It is not completely clear what portions of the CONNECT message are
being covered by the signature/MAC value.  As an example, is the password
field omitted entirely or is it set to a zero length password.  In addition
to this, from the couple of implementations that I have looked at the entire
packet is not passed out of the base server code for authentication
purposes.  This might need to be taken into account in terms of what is used
for the body and how it is constructed.  (As a side note, the
implementations that I have looked at so far also think that the password is
a text string rather than a binary value which is going to be a short term
issue as well.)

4.  I must admit that I am disappointed that there is no challenge response
mechanism in the MQTT specifications.  I don't know that anything can be
done at this point about it but there are some security issues that need to
be highlighted because of this in the security considerations section.  Only
the v3 seems to have this problem.  Also doing the channel binding would
deal with this problem as well.  Might just need some general discussions
around the channel binding text.

5.  Is there an intention to provide a "standard" format for the scope field
or just to leave it as ad hoc?

6.  It might be reasonable in section 2.1.3 to note that even if a result is
cached, that cached check should be limited for a specific amount of time to
recheck if the token is still active.  More of an issue in terms of how long
to cache for introspection.

7.  In section 2.1.4 - I would presume that the last paragraph should be
extended to say that the token is stored only for the length of the
connection.  That is the token always needs to be supplied every time a
connect message is sent.

Jim


___
Ace mailing list
Ace@ietf.org  
https://www.ietf.org/mailman/listinfo/ace

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile

[Cigdem Sengul]

Thank you, Jim, for the comments.
I have created issues corresponding to each one in the GitHub repository.

We will start working on them, and specifically clarify the issues 1-3
around the CONNECT message.

For 4, MQTT v5 can support a challenge-response; not possible with v3
indeed. Will expand the security considerations section on that.

5.  We described a convention in the draft with SHOULD. Do we turn that
into a MUST?

6. We thought that the AS would dictate the token expiration time. It can
also be done that RS times out tokens even if they have not expired. But,
security-performance trade-off should be considered.
Token caching is important even if the token does not need introspection.
The only time the MQTT client can push a token is with the CONNECT message
(all subsequent publish/subscribe messages rely on this). In MQTT v5, a
client can push a new token via reauthentication during an ongoing session
(enabled by MQTT v5). If RS times out the token, this means a disconnection
in MQTT v3. We mention this  in Security considerations as "it is expected
that AS follows a reasonable expiration strategy for access tokens"

-->There may be workarounds designed especially MQTT v5 which has better
support for request-response style communication. But need to think about
it.

7. That is correct. Will add the clarification.

Thanks,
--Cigdem




On Wed, May 22, 2019 at 10:58 PM Jim Schaad  wrote:

> Thanks for the updates from my last message.  This has helped quite a bit.
>
> 1.  A discussion of the use of raw public keys rather than certificates for
> the server may be in order.  This can refer to the same RPK issues from the
> current DTLS document.  It may also be that this just uses normal
> certificate processing and that should be noted as well, but some
> discussion
> of deciding if the subject name/alt name matches the token returned from
> the
> AS.
>
> For the connect message there are a couple of issues that need to be
> thought
> about.
>
> 2.  What items are required to be in the connect message.  The response to
> my last message suggested that a client identifier is required to be
> present
> but that is not documented.
>
> 3.  It is not completely clear what portions of the CONNECT message are
> being covered by the signature/MAC value.  As an example, is the password
> field omitted entirely or is it set to a zero length password.  In addition
> to this, from the couple of implementations that I have looked at the
> entire
> packet is not passed out of the base server code for authentication
> purposes.  This might need to be taken into account in terms of what is
> used
> for the body and how it is constructed.  (As a side note, the
> implementations that I have looked at so far also think that the password
> is
> a text string rather than a binary value which is going to be a short term
> issue as well.)
>
> 4.  I must admit that I am disappointed that there is no challenge response
> mechanism in the MQTT specifications.  I don't know that anything can be
> done at this point about it but there are some security issues that need to
> be highlighted because of this in the security considerations section.
> Only
> the v3 seems to have this problem.  Also doing the channel binding would
> deal with this problem as well.  Might just need some general discussions
> around the channel binding text.
>
> 5.  Is there an intention to provide a "standard" format for the scope
> field
> or just to leave it as ad hoc?
>
> 6.  It might be reasonable in section 2.1.3 to note that even if a result
> is
> cached, that cached check should be limited for a specific amount of time
> to
> recheck if the token is still active.  More of an issue in terms of how
> long
> to cache for introspection.
>
> 7.  In section 2.1.4 - I would presume that the last paragraph should be
> extended to say that the token is stored only for the length of the
> connection.  That is the token always needs to be supplied every time a
> connect message is sent.
>
> Jim
>
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Cigdem Sengul]

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

On Thu, May 23, 2019 at 7:29 AM Ludwig Seitz  wrote:

> 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.
> >
> > * 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 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.
>
>
>
> 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
>
> ___
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile

[Ludwig Seitz]

On 22/05/2019 23:58, Jim Schaad wrote:



5.  Is there an intention to provide a "standard" format for the scope field
or just to leave it as ad hoc?


I would be very much in favor of this, or at least provide guidelines to 
avoid adding to this: https://www.brandur.org/oauth-scope


/Ludwig






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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

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.


* 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 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.




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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace