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

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 18 Jun 2018 13:40:53 +0300

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On 04/22/2018 05:22 PM, Eric Rescorla wrote:
>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <[email-masked] <mailto:[email-masked]>>
>     > 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: [email-masked] <mailto:[email-masked]>
>     Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.org>
>     Profile: https://www.linkedin.com/in/petithug
>     <https://www.linkedin.com/in/petithug>
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jun 2018 10:43:24 -0700

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 <
[email-masked]> wrote:

> >     > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
> [email-masked] <mailto:[email-masked]>>
> >     > wrote:
> >     >
> >     >>