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

[Benjamin Kaduk <[e-mail]>]

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
>