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

[Marc Petit-Huguenin <[e-mail]>]

Hi Spencer,

I sent my answers to Eric Rescorla questions on 2018-10-07 following an in-person meeting with my co-author, but never got a response back.  Because there was no change proposed by Eric I went ahead and published -19 a couple of weeks after that, with the text agreed in response to Adam's and Benjamin's comments.

https://www.ietf.org/mail-archive/web/tram/current/msg02635.html

On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote:
> Hi, Marc,
> 
> I see that a -19 has been submitted, but didn't see a reply from Eric in
> this thread. Do you think that you've converged?
> 
> (I saw an offer of a conference call, so thought an out-of-band
> conversation might have happened)
> 
> Thanks,
> 
> Spencer
> 
> On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin <[e-mail]> wrote:
> 
>> Hi Eric,
>>
>> Please see inline.
>>
>> On 09/10/2018 03:25 AM, Eric Rescorla wrote:
>>> On Sat, Sep 8, 2018 at 2:31 PM, Marc Petit-Huguenin <[e-mail]>
>>> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> Apologies for the delay in getting back to that.
>>>>
>>>> I think that there is some misunderstanding in what STUNbis is trying to
>>>> do, so please see my comments inline.
>>>>
>>>> On 06/18/2018 10:43 AM, Eric Rescorla wrote:
>>>>> 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.
>>>>
>>>> In no place in STUNbis we are proposing to use SHA-1 for password
>>>> encryption, so I am not sure where that come from.  What we propose is:
>>>>
>>>
>>> You're right, it's SHA-256, but my criticisms apply equally there.
>>
>> SHA-256 was what the WG adopted.  Our attempts to add other passwords
>> encryption mechanisms were denied.  It is true that Argon2 was not in that
>> list (in our defense Argon2 was not known before July 2015), but I do not
>> see why the WG would have accepted that one over the others.  Anyway it is
>> too late to fix this, as it is my understanding that the WG does not have
>> enough energy to reach consensus on a new password algorithm.  Someone can
>> just write a draft adding Argon2 as password encryption, as we will have a
>> IANA registry for that.
>>
>>>
>>>
>>>> - Establish a registry for new password algorithms (section 18.5), so
>>>> algorithms like Argon2 could be added later (but note that our own
>>>> proposals to add more password algorithms were rejected by the working
>>>> group).
>>>> - Add a new password algorithm to that registry, namely SHA-256.
>>>> - Register MD5 as an initial password algorithm for backward
>> compatibility
>>>> purpose.
>>>>
>>>> As for the biddown protection itself, it is my recollection that it
>>>> happened more or less like that:
>>>>
>>>>
>>>> INT. MEETING ROOM - DAY
>>>>
>>>> One of the co-editors of STUNBis stands at the microphone:
>>>>
>>>>                            CO-EDITOR
>>>>                  We added SHA-256 protection for passwords
>>>>                  in STUNBis.
>>>>
>>>>                            SOMEONE (V.O.)
>>>>                  As MD5 still need to be supported, you need to add
>>>>                  protection for bid-down attacks.
>>>>
>>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES
>>>>
>>>>                            CO-EDITOR
>>>>                  OK, I'll work on that.
>>>>
>>>> Four to eight months has passed.
>>>>
>>>> INT. ANOTHER MEETING ROOM - DAY
>>>>
>>>> The same co-editor of STUNBis stands at the microphone:
>>>>
>>>>                            CO-EDITOR
>>>>                  We added a nice mechanism to prevent bid-down
>>>>                  attacks on passwords.  Any comments?
>>>>
>>>>                            THE ROOM
>>>>                  (silence)
>>>>
>>>>                            CO-EDITOR
>>>>                  Moving on...
>>>>
>>>
>>> I don't see how any of this is relevant to my technical points above.
>>
>> My point was that we, the co-editors, did not decide on adding bid-down
>> protection, someone asked us to do so and no-one in the WG saw any problem
>> with that.  The reasons that person wanted that are not known to us but, as
>> you insist, here's one reason I can think of:
>>
>> It is a fact that, for operational reasons, a password database cannot be
>> re-encrypted at once.  Also for operational reasons, the MD5 password
>> cannot be immediately removed from the database as soon the user submitted
>> a new one.  In fact, and for quite some time, both encrypted variants of
>> the same password may have to be kept in that database, because a single
>> user may use a mix of devices, some of them that use an RFC 5389 client,
>> some that use a STUNbis client.  It is up to the STUN server owner to
>> decide how long the migration to STUNbis will take and when it will be
>> acceptable to reject all RFC 5389 (i.e. MD5) clients (that migration time
>> can be purposely reduced to 0 seconds but that's the choice and
>> responsibility of the owner of the server).
>>
>> Meanwhile we still need to be sure that if the STUN client is implementing
>> STUNbis it unconditionally gets the additional protection of the new
>> password encryption algorithm.  That's where the biddown protection kicks
>> in, by preventing an online attacker to have the server misidentifying a
>> STUNbis client as an RFC 5389 client, by preventing an online attacker to
>> have the client misidentifying a STUNbis server as a RFC 5389 server, and
>> having both them use the MD5 encrypted password instead of the SHA-256
>> encrypted password, all of that easily done by stripping the unprotected
>> 401 response of the new STUNbis PASSWORD-ALGORITHMS attribute.
>>
>>>
>>>
>>>
>>>>> 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.
>>>>
>>>> There is no biddown attack protection for the MAC, as stated in Section
>>>> 16.3:
>>>>
>>>> "The bid-down protection mechanism described in this document is new,
>>>>  and thus cannot currently protect against a bid-down attack that
>>>>  lowers the strength of the hash algorithm to HMAC-SHA1."
>>>>
>>>> What we put in place is a plan for *future* versions of STUN to get
>>>> biddown protection for the MAC.  That's it, no more, no less.
>>>>
>>>
>>> Yes, but I don't believe that this will provide bid-down protection for
>> the
>>> MAC in the future for the reasons I indicate above.
>>>
>>> If you think this does something useful, please show me an example attack
>>> and how this fixes it. Note that it's not generally useful to just bid
>> down
>>> the MAC itself unless the MAC you bid down to is weak enough to exploit
>> in
>>> some other way.
>>
>> I do not know what weaknesses will be discovered in the future.  I am also
>> pretty sure that the cost of not using that mechanism is very close to 0.
>> What I am sure of is that the cost of reengineering a new biddown
>> protection mechanism if we ever need it will be high.  We already went
>> through the pains of designing one for the password algorithm, so why not
>> extend it so it can be used in the aftermath of the next Snowden facepalm
>> moment?
>>
>>> Again, happy to have a call to walk though this if that
>>> helps.
>>>
>>> -Ekr
>>>
>>>
>>>
>>>
>>>>>
>>>>> 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]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug