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

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

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.