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

Benjamin Kaduk <kaduk@mit.edu> Tue, 15 May 2018 18:24 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAFE12E04F; Tue, 15 May 2018 11:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sBfKHL11vuN; Tue, 15 May 2018 11:24:50 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 640A11241FC; Tue, 15 May 2018 11:24:49 -0700 (PDT)
X-AuditID: 12074424-707ff70000001acb-c7-5afb25ed9865
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 8A.70.06859.EE52BFA5; Tue, 15 May 2018 14:24:47 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w4FIOfIO031389; Tue, 15 May 2018 14:24:42 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w4FIOZHT030577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 May 2018 14:24:38 -0400
Date: Tue, 15 May 2018 13:24:35 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Marc Petit-Huguenin <petithug@acm.org>
Cc: Eric Rescorla <ekr@rtfm.com>, tram-chairs@ietf.org, tram@ietf.org, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, tasveren@rbbn.com, The IESG <iesg@ietf.org>, draft-ietf-tram-stunbis@ietf.org
Message-ID: <20180515182435.GN2249@kduck.kaduk.org>
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org> <CABcZeBO+2LG4-1-dhzTTSJFH6uhJdSEKLjyVfxO+krzHR8ueQw@mail.gmail.com> <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oLBj+sq0vYjzfsbl"
Content-Disposition: inline
In-Reply-To: <29c18858-3694-c48a-54c3-6dcbfa3b6705@acm.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMKsWRmVeSWpSXmKPExsUixG6nrvte9XeUQf8bNYvOLZfZLFa8Psdu sWn5SiaLGX8mMltcWHOXyWL98m/sFst/rmSz+LD2ApsDh8flK94ev75eZfNYsuQnk8eeOZMY PSY/bmMOYI3isklJzcksSy3St0vgytj0+xZTwW+7irO9k9gbGFcZdTFyckgImEjM77zK3MXI xSEksJhJ4uPTb2wgCSGBjYwSN5d5QiSuMkk83XMGLMEioCpx9PFDJhCbTUBFoqH7MjOILSKg JbF/ynWwScwCtxgl9vT8ZQdJCAukS9x+dZ0VxOYVMJZY1fiGBWLqCiaJW1P/MEMkBCVOznzC AmIzC5RJfD/9ibGLkQPIlpZY/o8DJMwpYC3xbud1sHJRAWWJvX2H2CcwCsxC0j0LSfcshG6I sJbEjX8vmTCEtSWWLXzNDGHbSqxb955lASP7KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1zvdzM Er3UlNJNjOD4clHZwdjd432IUYCDUYmH98LNX1FCrIllxZW5hxglOZiURHmt/wCF+JLyUyoz Eosz4otKc1KLDzGqAO16tGH1BUYplrz8vFQlEd5M3t9RQrwpiZVVqUX5MGXSHCxK4ryCmz9E CQmkJ5akZqemFqQWwWRlODiUJHgvqgA1ChalpqdWpGXmlCCkmTg4DzFKcPAADfdTBRleXJCY W5yZDpE/xagoJc6rBZIQAElklObB9YLSokT2/ppXjOJAbwnz+oOs4AGmVLjuV0CDmYAGF536 DjK4JBEhJdXA6O9y5j3vrwVVjl6tCX4dlsah5jnlulKx24Sd4rMZFLOMXXUPb6ydf/VI8dUJ zg+81G86xLf8WNax46v736bf+4ze+gZ4M/xxn7F+3X4+07suyQ/5l6fuPO/V6nS5SUiqSzr6 TYDbY8U2XvNMHuvZfxsmdfK896macDVwgbj9bOMNwRb1q/KUWIozEg21mIuKEwE0TsDKZgMA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/YnVlZWql9WibUfTEjS7YkYp5Pjo>
Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 18:24:53 -0000

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 <petithug@acm.org>
> > 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: marc@petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>