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

[Eric Rescorla <[e-mail]>]

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

> 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.
>

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



> 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?
>

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

-Ekr


> --Brandon
>
>
> On 05/15/2018 02:24 PM, Benjamin Kaduk wrote:
>
>> 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
>>
>> On Mon, May 14, 2018 at 01:06:00PM -0700, Marc Petit-Huguenin wrote:
>>
>>> 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.
>>>
>>> On 05/03/2018 04:45 PM, Eric Rescorla wrote:
>>>
>>>> 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 <[e-mail]>
>>>> wrote:
>>>>
>>>> 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.
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Marc Petit-Huguenin
>>> Email: [e-mail]
>>> Blog: https://marc.petit-huguenin.org
>>> Profile: https://www.linkedin.com/in/petithug
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> tram mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
> --
> Brandon Williams; Chief Architect
> Cloud Networking; Akamai Technologies Inc.
>