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

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 3 May 2018 16:34:47 -0700

On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote:
> Hi Eric,
> 
> Thanks for the review, please see my responses inline.
> 
> On 04/16/2018 12:57 PM, Eric Rescorla wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tram-stunbis-16: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Rich version of this review at:
>> https://mozphab-ietf.devsvcdev.mozaws.net/D5132
>>
>>
>> Can you please indicate how you addressed the points Matt Miller
>> raised in his secdir review about the use of MD5.
> 
> From my response on 2018-03-11:
> 
>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but the
>> hash length of MD5 is 16 bytes (128 bits).  I think this is merely a typo,
>> since the purpose appears to be for backwards compatibility with existing
>> systems.
> 
> Fixed.
> 
>>
>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential)
>> and Section appear to define the same functional algorithm, but with subtle
>> syntax differences.  As far as I can tell, they are actually the same
>> algorithm; would it not be acceptable to have Section 9.2.2 point to
>> Section 17.5.1.1 for the algorithm description?
>>
>>
> 
> This is going into the IANA registry so I left things there.  I fixed the discrepancy with section 9.2.2.
> 
> I also fixed the definition of the key for SHA-256, which must use OpaqueString for the realm.
> 
>>
>>
>>
>> DETAIL
>>>      by the agent sending the indication.  It primarily serves to
>>>      correlate requests with responses, though it also plays a small role
>>>      in helping to prevent certain types of attacks.  The server also uses
>>>      the transaction ID as a key to identify each transaction uniquely
>>>      across all clients.  As such, the transaction ID MUST be uniformly
>>>      and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
>>
>> I didn't realize this was a SHOULD. ICE depends on it as a security
>> condition, so it probably needs to be a MUST.
> 
> Done.
> 
>>
>>
>>>      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.
> 
>>
>>
>>>      STUN Security Feature it is understood that the corresponding STUN
>>>      Security Feature bit in the "nonce cookie" is set to 1.
>>>
>>>      For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
>>>      security feature, it is implied that the "Password algorithms" bit,
>>>      as defined in Section 17.1, is set to 1 in the "nonce cookie".
>>
>> I'm not sure I understand the bid down attack here or the proposed
>> defense.  Can you please walk through what the assumed attacker
>> capabilities are, what the client and server capabilities are, how the
>> bid down attack works, and how this protects against it?
> 
> The plan is to add an annex to the document explaining that.  I'll finish to process the other reviews from the IESG and then come back to that.
> 

Instead of an annex, we added a new section in the Security Considerations.  Please have a look at -17 and let us know if that explanation is good enough.

Thanks.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2018 16:35:01 -0700

On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin <[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]>
> > wrote:
> >
> >>
> > 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
> >>
> >> 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]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 3 May 2018 16:45:08 -0700

No, I don't understand this at all. This section talks about a bid-down on
the PASSWORD-ALGORITHM, but I don't see how a weakness in MD5 is relevant
here.

Assuming I understand correctly, the structure of the protocol is that
given a password, you do:

   key = Password-Algorithm(username, realm, password)

And then use key with HMAC for an integrity check, where HMAC is SHA-1
(with MESSAGE-INTEGRITY) or SHA-256 (with MESSAGE-INTEGRITY-SHA256).
However, in this case the MD5 isn't a security critical component at the
protocol layer [0], because it's just is just to act as a transformation of
the password into a fixed-length string for use as a key, so this doesn't
require collision resistance or pseudorandomness. I could be wrong here,
but if so, please describe a potential weakness in MD5 which could lead to
compromise of this protocol

-Ekr

[0] It might be an issue if someone were to recover the hashed password.

On Thu, May 3, 2018 at 4:34 PM, Marc Petit-Huguenin <[email-masked]>
wrote:

> > The plan is to add an annex to the document explaining that.  I'll
> finish to process the other reviews from the IESG and then come back to
> that.
> >
>
> Instead of an annex, we added a new section in the Security
> Considerations.  Please have a look at -17 and let us know if that
> explanation is good enough.
>
> Thanks.
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 14 May 2018 13:06:00 -0700

During the discussion about choosing password algorithms, someone came to the microphone (AFAIR) and said that it was subject to bid-down attack.  We then design a solution to prevent that and that's what, after more discussions, we put in the draft.  So I welcome any comment on the strength or weakness of the protection offered by the scheme we put in place and any suggestion to make it better, but as for the reasons it is there you will have to talk to the Working Group.

Thanks.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 15 May 2018 13:24:35 -0500

I think I have the same understanding as Ekr, in which case the
bid-down concerns apply only to message integrity and not to
password-algorithm.

So it would be good to hear from the WG on this issue.

-Benjamin

---

From: Brandon Williams <[email-masked]>
Date: Thu, 17 May 2018 16:04:42 -0400

I'll take a stab at describing the working group discussion, but please 
keep in mind that my recollection of this is faint ... it was a few 
years ago at this point.

The working group started with a fundamental assumption that we should 
be moving away from MD5 for the purpose of key generation. I don't 
recall the WG having any detailed discussion of whether using MD5 here 
is a real security weakness in the protocol; had Ekr suggested at the 
mic that MD5 weakness might not actually be a problem we quite possibly 
would have chosen not to make any change to key derivation at all.

So, working from the basic assumption that we should be moving away from 
MD5 for key derivation, it seemed only natural that we should be 
attempting to prevent an adversary from forcing downgrade back to MD5 
via a bid-down attack as a way to weaken key derivation. After all, if 
preventing bid-down is not important then the same logic seems to 
suggest that moving away from MD5 at all is not important.

I know that's not a very satisfying answer to the question of how we got 
here, but it represents my best recollection nonetheless.

That having been said, I'm having trouble reconciling Ekr's "I don't see 
how a weakness in MD5 is relevant here" with Matt Miller's earlier 
comment "I am wondering why a more robust password algorithm (key 
derivation function) was not defined (e.g., HKDF-SHA-256)". Matt appears 
to suggest that we should go farther than we have while Ekr appears to 
suggest that we might not need to have gone even that far.

Any suggestions about path to resolution on this? Am I just completely 
misinterpreting the comments we've received so far?

--Brandon

On 05/15/2018 02:24 PM, Benjamin Kaduk wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
> 

-- 
Brandon Williams; Chief Architect
Cloud Networking; Akamai Technologies Inc.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 May 2018 13:22:04 -0700

On Thu, May 17, 2018 at 1:04 PM, Brandon Williams <
[email-masked]> wrote:

> keep in mind that my recollection of this is faint ... it was a few years
> ago at this point.
>
> The working group started with a fundamental assumption that we should be
> moving away from MD5 for the purpose of key generation. I don't recall the
> WG having any detailed discussion of whether using MD5 here is a real
> security weakness in the protocol; had Ekr suggested at the mic that MD5
> weakness might not actually be a problem we quite possibly would have
> chosen not to make any change to key derivation at all.
>

Sure. I don't remember being in the room for this.

> MD5 for key derivation, it seemed only natural that we should be attempting
> to prevent an adversary from forcing downgrade back to MD5 via a bid-down
> attack as a way to weaken key derivation. After all, if preventing bid-down
> is not important then the same logic seems to suggest that moving away from
> MD5 at all is not important.
>
> how a weakness in MD5 is relevant here" with Matt Miller's earlier comment
> "I am wondering why a more robust password algorithm (key derivation
> function) was not defined (e.g., HKDF-SHA-256)". Matt appears to suggest
> that we should go farther than we have while Ekr appears to suggest that we
> might not need to have gone even that far.
>

Well, I don't know what Matt is thinking. Perhaps he would like to weigh in?

-Ekr

>>> During the discussion about choosing password algorithms, someone came
>>> to the microphone (AFAIR) and said that it was subject to bid-down attack.
>>> We then design a solution to prevent that and that's what, after more
>>> discussions, we put in the draft.  So I welcome any comment on the strength
>>> or weakness of the protection offered by the scheme we put in place and any
>>> suggestion to make it better, but as for the reasons it is there you will
>>> have to talk to the Working Group.
>>>
>>> Thanks.
>>>
>>>>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria
>>>>>>> .
>>>>>>>
>>>>>> html
>>>>>
>>>>>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but
>>>>>>>
>>>>>> the
>>>>>
>>>>>> hash length of MD5 is 16 bytes (128 bits).  I think this is merely a
>>>>>>>
>>>>>> typo,
>>>>>
>>>>>> since the purpose appears to be for backwards compatibility with
>>>>>>>
>>>>>> existing
>>>>>
>>>>>> systems.
>>>>>>>
>>>>>>
>>>>>> Fixed.
>>>>>>
>>>>>>
>>>>>>> and Section appear to define the same functional algorithm, but with
>>>>>>>
>>>>>> subtle
>>>>>
>>>>>> This is going into the IANA registry so I left things there.  I fixed
>>>>>>
>>>>> the discrepancy with section 9.2.2.
>>>>>
>>>>>>
>>>>>> I also fixed the definition of the key for SHA-256, which must use
>>>>>>
>>>>> OpaqueString for the realm.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> DETAIL
>>>>>>>
>>>>>>>>       correlate requests with responses, though it also plays a
>>>>>>>> small
>>>>>>>>
>>>>>>> role
>>>>>
>>>>>>       in helping to prevent certain types of attacks.  The server also
>>>>>>>>
>>>>>>> uses
>>>>>
>>>>>>>>       USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY
>>>>>>>>
>>>>>>> attributes
>>>>>
>>>>>>>>       this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256
>>>>>>>>
>>>>>>> MUST
>>>>>
>>>>>> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for
>>>>>>
>>>>> stunbis does not apply.
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>>       security feature, it is implied that the "Password algorithms"
>>>>>>>>
>>>>>>> bit,
>>>>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 May 2018 15:33:37 -0500

> Well, I don't know what Matt is thinking. Perhaps he would like to weigh in?

I think this is a question of "attack over the network" vs.
"compromised password database".  You want HKDF-SHA-256 or Argon2 or
something like that because it makes it harder for an attacker to
brute-force a compromised database of hashed passwords, which is
something of a different concern than turning a string into a crypto
key and worrying about an attacker in the network that only observes
the ciphertext.  That is, the problem of brute-forcing the secret material
given the network ciphertext is different from attacking the
(hashed) password database directly.

So it seems possible that both points are relevant, just protecting
against different things.

-Benjamin

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 May 2018 13:50:31 -0700

On Thu, May 17, 2018 at 1:33 PM, Benjamin Kaduk <[email-masked]> wrote:

> comment

Right. But the weak password hashing function is a problem if you have
the data on disk, whether you negotiate it or not, so biddown protection
doesn't help.

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 May 2018 15:55:16 -0500

> the data on disk, whether you negotiate it or not, so biddown protection

Right.  So maybe we need a way to signal that the MD5-hashed thing
can be removed from the on-disk database.  (Well, "need".)  The
first occurrence of non-md5 might not be enough, though...

-Benjamin

---

From: "Matthew A. Miller" <[email-masked]>
Date: Thu, 17 May 2018 16:17:44 -0600

> against different things.

My initial thoughts were along the lines of "compromised database",
which admittedly data-at-rest is at the top of my mind most of the time.
 The key derivations in this document are ok for how they are used.

I thought I'd backed away from that robustness point in the email
discussion that ensued from the review, as it sounded like a concern
that was out of scope for this work.  If offline attacks are in-scope
then something that makes brute force take some real work (at _a
minimum_ PBKDF2 with 10k+ iterations, or better yet use scrypt or
argon2).  If it's out-of-scope, then this needs to be called out in the
security considerations.

Otherwise, I think a valid concern to implementers is that MD5 is
getting removed from or turned-off in various base libraries and module.
 Moving away from it helps implementations avoid having to rely on older
(and potentially vulnerable/exploitable) base libraries just to keep an
algorithm around seems very worthwhile.

- m&m

Matthew A. Miller

---

From: Brandon Williams <[email-masked]>
Date: Fri, 18 May 2018 09:43:44 -0400

OK, so based on this, it seems that the WG was right about the desire to 
move away from MD5 but unclear about the reason. If the goal is to 
mitigate against keeping weak hashes in a local database on the server, 
the doc should be clear that this is risk and explain how bid-down helps 
achieve the goal.

Depending upon the internal implementation on the server, bid-down 
protection could be important as part of a model to help the server 
avoid caching weak precomputed password hashes to insecure local storage 
I suppose. For example, if the server computes the hash using the 
negotiated algorithm and then writes the hash to a local cache to avoid 
having to calculate it again, it would be good to avoid generating weak 
hashes that could be leaked from a compromised server. Of course, this 
is only really meaningful if the server has strong protections around 
the the username/password database that's required to generate the hash 
values in the first place.

Does this seem like it would be going in the right direction?

--Brandon

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 18 May 2018 17:11:19 -0500

> Does this seem like it would be going in the right direction?

I think so.

-Benjamin