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

[Cigdem Sengul <[e-mail]>]

Hello Ben,


> Hopefully you have not gotten too far along on the few items where I reply
> and say that your proposed change may not be needed; I had hoped to write
> this message several days ago.  (That said, there really are only a few
> such places; the bulk of your proposals look good.)
>

No worries at all. I have been swamped and this time it served a good
purpose that I could not start
immediately addressing the issues raised. :) Hope to do so soon.

I am glad we have cleared out some misunderstandings regarding
token lengths, and MQTT operation.  Majority of required changes are clear
now,
I will have a more detailed e-mail showing how your review comments were
addressed.
Below, there are a few where I ask for some further clarifications, or
express my agreement, if I haven't done so already.

>
>
> >   The Broker MUST support "TLS:Anon-MQTT:ace".  To support Clients with
> > >    different capabilities, the Broker MAY provide multiple client
> > >    authentication options, e.g. support "TLS:Known(RPK)-MQTT:none" and
> > >    "TLS:Anon-MQTT:None", to enable RPK-based client authentication, but
> > >    fall back to "TLS:Anon-MQTT:ace" if the Client does not send a
> client
> > >    certificate (i.e. it sends an empty Certificate message) during the
> > >    TLS handshake.
> > >
> > > [Just a potential nit about the wording: "fall back" implies some
> > > ordering requirements, but IIRC use of RPK requires sending the token
> to
> > > authz-info before starting the new TLS connection, which doesn't quite
> > > match the steps as ordered in this description.]
> > >
> >
> > [CS: True that is not well-written. That was added because to
> potentially handle the Brokers having optional
> > client authentication for TLS. So, client authentication in TLS doesn't
> work, the broker would expect a
> > token in CONNECT; But it doesn't look needed as we do have a MUST for a
> token to be provided
> > for TLS-level client authentication. ]
>
> I think that makes sense to not require the broker to support TLS-level
> client authentication, yes.
>

[CS: OK. So, this should be rewritten not to say fall back?
Such as:
The Broker MUST support TLS:Anon,MQTT:ace.  To support Clients with
 different capabilities, the Broker MAY provide multiple client
authentication options, e.g. support TLS:Known(RPK) MQTT:none and
TLS:Anon,MQTT:None, to enable RPK-based client authentication, but
 if the Client does not send a client certificate (i.e. it sends an empty
Certificate message) during the
TLS handshake, the Broker MAY look for a token in MQTT CONNECT, using the
TLS:Anon,MQTT:ace
combination.
]


>
> >    Note that, according to the MQTT standard, the Broker uses the Client
> > >    identifier to identify the session state.  In the case of a Client
> > >    identifier collision, a client may take over another client's
> > >    session.  [...]
> > >
> > > Just to confirm: the ACE token is not used to provide authorization to
> > > use a given client identifer; the client identifier is just used as an
> > > unauthenticated identifier?  We might consider calling that out
> > > explicitly.
> > >
> >
> > [OK. Yes, the MQTT client id is considered different than the Client
> > Identifier that may be in the token.]
>
> They are clearly different identifiers, yes.  I was trying to ask about
> something slightly different, though.  One might imagine treating MQTT
> Client Identifiers as resources in their own right, and having the AS grant
> authorization to use them.  In that case the Client Identifier could be
> encoded in the token and the broker could reject attempts to use a client
> identifier that were not accompanied by a token authorizing use of that
> identifier.  However, such an architecture seems to have some layering
> issues and could be messy to implement, so I was assuming that we were not
> proposing to do so.
>

[CS: No, indeed, we have not considered client-identifiers as a resource. I
think it is an interesting proposal,
but may have further issues with client id collisions, which MQTT handles
best-effort.
Collision-free IDs would be desired but hard to achieve, when tokens given
out by multiple ASes, I assume. ]


>
> >    a CONNACK with the appropriate response code.  The client cannot
> > >    reauthenticate using this method during the same session ( see
> > >    Section 4).
> > >
> > > Depending on what "session" means, this restriction may be too strict.
> > > We should probably be more clear about what "session" means...if it's
> > > the MQTT session, I think it's okay to use this method when
> > > re-connecting to take over the session.
> > >
> >
> > [CS: This is the MQTT session - I believe we discussed this before, and
> the
> > agreement was that this should not be allowed.
> > The reasoning was the client was not necessarily proving anything new
> with
> > the challenge from TLS-Exporter already used.]
>
> I agree that re-using the same challenge value from a TLS-Exporter is
> problematic for that reason.
>
> But consider the case where a client makes a new TCP+TLS connection and
> then sends MQTT CONNECT with Clean Start=0.  The new TLS connection, even
> if using TLS session resumption, will have [*] a different TLS exporter
> value than any other TLS connection, so it would be a safe way to
> authenticate, but this text seems to prohibit us from using it.
> (I guess I commented on basically the same thing later on, too...)
>
> [*] modulo things like the "triple-handshake attack" that motivated the
> extended master secret extension of RFC 7627.  See also my comment that we
> should incorporate current TLS best practices, which will include mandating
> the use of extended master secret.
>

[CS: True, if there is MQTT session continuation, this can be allowed. I
will revise.]


> >
> >    If the Broker accepts the connection, it MUST store the token until
> >    the end of the connection.  On Client or Broker disconnection, the
> >    Client is expected to transport a token again on the next connection
> >    attempt.
> >
> > This seems to deviate somewhat from the framework, that expects the RS
> > to be prepared to store at least one token for future use, and
> > recommends storing one token per PoP key.
> > [CS: OK I will need to update the draft if I cannot have a deviation.
> > Then,I  need to think about how to implement it - I assume PoP will be
> done
> > again
> > if the client connects without a token, but RS believes there is a token
> > associated with it?]
>
> It may be okay to have a deviation, but I don't want to just "silently"
> have a deviation -- it should be noted as such, which indicates that we've
> actually thought about it.
> (The framework text seems to be "MUST be prepared to store at least one
> access token", not "MUST store at least one access token"...)
>

[CS:
OK.
Let me consider what happens if the Broker stores a token for future use.
Then, different from the public clients, which connect TLS:none,MQTT:none,
the client still connects to TLS:none,MQTT:ace, i.e. it gives the
authentication method as ACE, but
doesn't provide a token. We previously used this to signal optional AS
discovery.
If there is no token, but the method is ace, the first thing the Broker can
do is to look for a token associated with the client.
Then it does the AUTH challenge to do PoP of the token for this client.
If this fails, or there is no token, then it sends a CONNACK not
authorised, and does optional AS discovery.

I think flow-wise this can work - it is not a security issue if the client
ids collide, and the broker considers a wrong token for the client because
of the PoP challenge.

If this is acceptable, I will revise.
]


> >
> > >                                                              The Broker
> > >    SHOULD also use a cache time out to introspect tokens regularly.
> > >
> > > We will surely be asked to provide guidance on what timescale
> > > "regularly" indicates, if we do not proactively provide some guidance.
> > >
> > > [CS: I would expect that is based on the dynamicity of the application
> and
> > risk associated, but I was considering
> > ranges like every 12 hours; every 24 hours]
>

[CS: Or should we shy away from being specific, and just say it's
application dependent, and
maybe give an example application?]


> >
> >  If the Will Flag is set, then the Broker MUST check that the token
> > >    allows the publication of the Will message (i.e. the Will Topic
> > >    filter is in the scope array).
> > >
> > > We might want to say a little more about when this check happens.  My
> > > intuition is that it occurs during the CONNECT processing where the
> > > actual Will message is provided, and that the connection would be
> > > rejected if the Will message is unauthorized.  But this section is
> > > titled "Authorizing PUBLISH and SUBSCRIBE Messages", so one might be
> > > forgiven for assuming that CONNECT is out of scope...
> > >
> >
> > [CS: I assumed the check will happen when the Will message needs to be
> > published (information about the Will topic is in the CONNECT).
> > And the Broker will refuse to publish if it is not covered in the token.
> > This can be changed to checking in CONNECT but then, we add "Will message
> > not authorised" as a reason to refuse Connection with the rationale that
> > even if it is not an actual publication, it may result in publishing a
> > message (the will) in future.
> > (I've written more on this in "Will do" section below, because it came up
> > in multiple places, and I did not want to repeat the same discussion)]
>
> (Definitely don't repeat the same discussion in the same email!)
>
> I think my assumption was that the client sets a Will message and assumes
> that it will always go out if the client goes away uncleanly, functioning
> as a sort of "dead-man's switch".  If the client disconnects and the broker
> prepares to send the Will message only to discover that it's unauthorized,
> there's no way to indicate the error to the client, and so the client's
> assumption that the message will go out is broken.  Maybe I'm wrong about
> what Will messages are used for, though, and this is not actually a problem
> in practice.  However, if there is a need to provide some "guarantee of
> future delivery" for the Will message, we need to check authorization while
> the client is still around, and at CONNECT time seems to be the natural (or
> even only?) option for when to do that.  If we do move the checking to
> CONNECT, I think we would also want to mention that "Will message not
> authorised" can happen at the periodic re-authorisation checks that we
> already talk about.
>

[CS: I agree. This check needs to happen during CONNECT, and fail the
connection with Not Authorised.
Brokers can use a reason string to give more diagnostic information.
Similarly, Server does include Will-Topic check to re-authorisation, and
triggers DISCONNECT if it cannot fulfill the Will.

I must have gotten myself confused as this should have been the intention
from the beginning as I have the following text in the draft:
"If the Will Flag is set, then the Broker MUST check that the token allows
the publication of the Will message (i.e. the Will Topic filter is in the
scope array)." - which is in the wrong place, and should be in CONNECT.
Still, it was under-specified, ie. if the check fails, it leads to Not
Authorised etc.
]


>
> > Section 6.2
> > >
> > >    o  RS-Client PUBLISH authorization failure: When RS is forwarding
> > >       PUBLISH messages to the subscribed Clients, it may discover that
> > >       some of the subscribers are no more authorized due to expired
> > >       tokens.  These token expirations SHOULD lead to disconnecting the
> > >       Client rather than silently dropping messages.
> > >
> > > (I'm not actually sure how much the MQTT spec says about this type of
> > > scenario, and thus whether the "SHOULD" is the right term to use.)
> > >
> >
> > [CS: MQTT v3.1 would not consider the clients losing authentication in
> the
> > middle of a session. I am not sure we can find guidance there on this.]
>
> It makes sense that we won't get much guidance, given that v3.1 was
> basically assuming password auth, which is "one and done" for the whole
> connection.  I should have been more clear, though -- I think this is a
> candidate for "MUST lead to disconnecting the client rather than silently
> dropping messages", and I wanted to know if you had a reason to make it
> optional.
>

[CS: Yes, MUST is better.I think SHOULD was for some reason if the broker
doesn't want to drop
connections abruptly, but silent errors are worse]


>
> >
> >
> > > This document seems to mostly use British English.  AFAIR, that's okay,
> > > but if it's inconsistent the RFC Editor will prefer American English.
> I
> > > didn't attempt to check for this (though there are tools like
> > > https://github.com/larseggert/ietf-reviewtool that will do so).
> > >
> >
> > [CS: Will check and Americanize. :) ]
>
> I *think* you don't have to Americanize :)
> It's just that if you have a mix, the RFC Editor will pick American every
> time.  If it's consistently British they will leave it alone, is my
> understanding.
>

[CS: Unfortunately, having studied in the US, and living in Britain, I mix
things all the time.
So, I will make it consistent, one way or the other :) ]

>
>
> > >
> > >                                       If the RS supports the public
> > >    "authz-info" topic, described in Section 2.2.2, then this may be
> > >    vulnerable to a DDoS attack, where many Clients use the "authz-info"
> > >    public topic to transport fictitious tokens, which RS may need to
> > >    store indefinitely.
> > >
> > > We do say that the RS only stores "valid" tokens, which includes being
> > > generated by a trusted AS and having RS as the audience.  So it's not
> > > clear that this statement is accurate if the attack is to involve
> > > "fictitious" tokens.  Similar attacks are possible, though.
> > >
> >
> > [CS: OK,  We accept it can still be DOS'ed? fictitious doesn't sound
> right.
> > my intention was to say tokens not meant to be used.]
>
> Yes, this is still vulnerable to DDoS, but the pool of potential attackers
> is somewhat restricted.  In particular, if the AS only issues a small
> number of tokens with the RS as the audience, that bounds the amount of
> state that the RS has to maintain (but it could still be subject to
> resource exhaustion of resources like CPU when processing a bunch of
> invalid tokens).  So "may need to store indefinitely" might be the main
> thing I was commenting about here.
>

[CS: OK, will word more clearly.]

 Thanks a lot for your responses.
Kind regards,
--Cigdem