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

[Brandon Williams <[e-mail]>]

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