Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

Hi folks,

I've reviewed the new version, but I don't think that the biddown
discussion makes much sense.

To recap, there are two hashes here:

- The hash which you use to store the password with (currently mostly MD5)
- The hash you use to compute the MAC (currently SHA-1).

First, let's stipulate that MD5 isn't a great choice here, though SHA-1
isn't a great choice
either for pwd hashing You want Argon or the like. With that said, there's
no sensible
biddown attack on that hash because it's a per-server feature, not a
per-transaction
feature. So, as long as the server has MD5-hashed passwords, the situation
is bad.

The second topic is the hash used to compute the MAC. However, I don't see
how
this gives you sensible biddown protection because that hash is also used
to compute
MAC over the negotiation: an attacker who has compromised a MAC which the
server
supports will quite likely be able to forge a MAC over the transcript as
well. This is,
I suppose, potentially useful as a defense against some other weakness
(e.g.,
version #), but I don't really see how the current design helps against
attacks on the
MAC.

You might think that there was a MAC which was easier to reverse to find
the original
password, but the defense you have here doesn't help with that because the
on-path attacker can do a bid-down and use the client as a MAC oracle for
any MAC the client supports.

So, I still don't understand what this is supposed to do. Happy to have a
call if you
think that helps

-Ekr




On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo Camarillo <
[e-mail]> wrote:

> Marc, Eric,
>
> what is the status of this discussion?
>
> Thanks,
>
> Gonzalo
>
> On 04/05/2018 2:35 AM, Eric Rescorla wrote:
> >
> >
> > On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On 04/22/2018 05:22 PM, Eric Rescorla wrote:
> >     > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
> [e-mail] <mailto:[e-mail]>>
> >     > wrote:
> >     >
> >     >>
> >     >>>>      For a request or indication message, the agent MUST
> include the
> >     >>>>      USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY
> >     >> attributes
> >     >>>>      in the message unless the agent knows from an external
> indication
> >     >>>>      which message integrity algorithm is supported by both
> agents.  In
> >     >>>>      this case either MESSAGE-INTEGRITY or
> MESSAGE-INTEGRITY-SHA256 MUST
> >     >>>>      be included in addition to USERNAME.  The HMAC for the
> MESSAGE-
> >     >>>
> >     >>> This text appears to conflict with S 7.3 of 5245-bis, which says:
> >     >>
> >     >> [text missing]
> >     >>
> >     >> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure
> for
> >     >> stunbis does not apply.
> >     >>
> >     >
> >     > I hear what you're saying, but publishing two documents at the
> same time
> >     > which
> >     > make contrary recommendations about the same basic protocol is
> un-good.
> >
> >     Sure, but wouldn't it be simpler to have rfc5245bis using stunbis
> >     and have them updating their text, more than adding some tortuous
> >     text in stunbis?
> >
> >     >
> >     >
> >     >>>      The STUN usage must specify which transport protocol is
> used, and
> >     >> how
> >     >>>>      the agent determines the IP address and port of the
> recipient.
> >     >>>>      Section 8 describes a DNS-based method of determining the
> IP
> >     >> address
> >     >>>>      and port of a server that a usage may elect to use.  STUN
> may be
> >     >> used
> >     >>>>      with anycast addresses, but only with UDP and in usages
> where
> >     >>>>      authentication is not used.
> >     >>>
> >     >>> Why this restriction? You should be able to use anycast with
> long-term
> >     >>> AUTH for (say) TURN.
> >     >>
> >     >> https://www.ietf.org/mail-archive/web/behave/current/
> msg03582.html
> >     <https://www.ietf.org/mail-archive/web/behave/current/msg03582.html>
> >     >>
> >     >> I think that the decision of permitting Anycast should be left to
> each
> >     >> STUN Usage.  Basic STUN Usage does not use authentication and use
> only a
> >     >> one round trip for the Binding transaction, so Unicast can be
> used.
> >     >>
> >     >
> >     >> OTOH, TURN and ICE should probably say something about that, so I
> added a
> >     >> new bullet point in Section 13:
> >     >>
> >     >>    o  If Anycast addresses can be used for the server in case TCP
> or
> >     >>       TLS-over-TCP, or authentication are used.
> >     >>
> >     >
> >     > Are you leaving this text in? That seems very confusing.
> >
> >     In isolation yes, but I think it makes sense which the text before
> >     the bullet points:
> >
> >        A STUN usage defines how STUN is actually utilized -- when to send
> >        requests, what to do with the responses, and which optional
> >        procedures defined here (or in an extension to STUN) are to be
> used.
> >        A usage also defines:
> >
> >     [...]
> >
> >        o  If Anycast addresses can be used for the server in case TCP or
> >           TLS-over-TCP, or authentication are used.
> >
> >
> > What is the need for the restriction at all.
> >
> >
> >
> >     >>>>      transaction over UDP or DTLS-over-UDP is also considered
> failed if
> >     >>>>      there has been a hard ICMP error [RFC1122].  For example,
> assuming
> >     >> an
> >     >>>>      RTO of 500ms, requests would be sent at times 0 ms, 500
> ms, 1500
> >     >> ms,
> >     >>>>      3500 ms, 7500 ms, 15500 ms, and 31500 ms.  If the client
> has not
> >     >>>>      received a response after 39500 ms, the client will
> consider the
> >     >>>>      transaction to have timed out.
> >     >>>
> >     >>> I note that these recommendations now seem crazily long. I
> assume the
> >     >>> WG had consensus on this, but I wanted to note it.
> >     >>
> >     >> Not just the WG, also the IESG that approved RFC 5389 too as, but
> for the
> >     >> addition of "or DTLS-over-UDP", this is the same text than in RFC
> 5389.
> >     >>
> >     >
> >     > Yes, I know. My point is that while they might have bee sensible
> when
> >     > 5389 was published they *now* seem crazily long. Did the WG
> explicitly
> >     > decide not to update them?
> >
> >     No, nobody ever suggested that there was an issue there.
> >
> >
> > OK, well, this seems like it should be considered, then, because this
> > doesn't
> > match modern practice.
> >
> >
> >
> >     > This would be good to explain.
> >
> >     New text:
> >
> >        [...]
> >        containing the subjectAltName of that certificate.  The test on
> the
> >        MESSAGE-INTEGRITY-SHA256 attribute indicates that the transaction
> is
> >        authenticated and that the client implements this specification
> and
> >        so can process the ALTERNATE-DOMAIN attribute.
> >
> >
> > All right.
> >
> >
> >     >
> >     >
> >     >>>>      o  What authentication and message-integrity mechanisms
> are used.
> >     >>>>
> >     >>>>      o  The considerations around manual vs. automatic key
> derivation
> >     >> for
> >     >>>>         the integrity mechanism, as discussed in [RFC4107].
> >     >>>>
> >     >>>>      o  What mechanisms are used to distinguish STUN messages
> from other
> >     >>>
> >     >>> Why is this required? It seems like that's a generic STUN
> feature.
> >     >>
> >     >> That text is identical to the text in RFC 5389.  RFC 5764/7983 is
> one such
> >     >> mechanism, but there is nothing that prevent another protocol
> stack to use
> >     >> a different mechanism (inference, shim, etc...)
> >     >>
> >     >
> >     > But ultimately no matter what the other protocol provides for
> demux, STUN
> >     > has its
> >     > own demux.
> >
> >     In fact I think that the reason for that item was because
> >     FINGERPRINT can also be used to demux STUN traffic, but it is
> >     optional.  So an STUN Usage needs to tell if FINGERPRINT is
> >     mandatory (like in ICE).
> >
> >
> > This should be explained.
> >
> >
> >     >>>
> >     >>>>      that is not readily subject to offline dictionary attacks.
> >     >>>>      Protection of the channel itself, using TLS or DTLS,
> mitigates
> >     >> these
> >     >>>>      attacks.
> >     >>>>
> >     >>>>      STUN supports both MESSAGE-INTEGRITY and
> >     MESSAGE-INTEGRITY-SHA256,
> >     >>>>      which is subject to bid down attacks by an on-path
> attacker.
> >     >>>
> >     >>> By an on-path attacker who can forge HMAC-SHA1 in real-time?
> >     That's a
> >     >>> pretty serious adversary, so you should clarify here
> >     >>>
> >     >>
> >     >> New text:
> >     >>
> >     >>    STUN supports both MESSAGE-INTEGRITY and
> MESSAGE-INTEGRITY-SHA256,
> >     >>    which is subject to bid down attacks by an on-path attacker
> that
> >     >>    would strip the MESSAGE-INTEGRITY-SHA256 attribute leaving
> >     only the
> >     >>    MESSAGE-INTEGRITY attribute and exploiting a potential
> >     vulnerability.
> >     >>    Protection of the channel itself, using TLS or DTLS, mitigates
> >     these
> >     >>    attacks.  Timely removal of the support of MESSAGE-INTEGRITY
> in a
> >     >>    future version of STUN is necessary.
> >     >>
> >     >
> >     > I still don't understand the capabilities you seem to believe the
> >     attacker
> >     > has.
> >     > Can you describe the exact attack.
> >     >
> >
> >     1. Vulnerability is found in HMAC-SHA1
> >     2. Client Alice still supports M-I and M-I-256, does not know what
> >     version of STUN server Bob supports and so send both.
> >     3. On-path attacker removes M-I-256.
> >     5. stunbis server Bob thinks that Alice is an RFC 5389 client and
> >     continue with that protocol.
> >
> >
> > This seems like an extremely weak attack. In general, any protocol of
> > this type is as strong
> > as the weakest integrity algorithm it supports, so it's not that the
> > protocol has a downgrade
> > attack, but rather that the minimum algorithm supported is one you don't
> > trust as much
> > as you might like.
> >
> > -Ekr
> >
> >
> >     --
> >     Marc Petit-Huguenin
> >     Email: [e-mail] <mailto:[e-mail]>
> >     Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.
> org>
> >     Profile: https://www.linkedin.com/in/petithug
> >     <https://www.linkedin.com/in/petithug>
> >
> >
>