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

Eric Rescorla <ekr@rtfm.com> Thu, 03 May 2018 23:45 UTC

Return-Path: <ekr@rtfm.com>
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 1ADFE12E884 for <tram@ietfa.amsl.com>; Thu, 3 May 2018 16:45:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.608
X-Spam-Level:
X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 ac_BYaO-27l8 for <tram@ietfa.amsl.com>; Thu, 3 May 2018 16:45:50 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C2112E034 for <tram@ietf.org>; Thu, 3 May 2018 16:45:50 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id k5-v6so10863754oiw.0 for <tram@ietf.org>; Thu, 03 May 2018 16:45:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZErh6SYyqcHOKTQtgJUo2EAFeU1w0RAc5pJKVSjDGpM=; b=z+SotQcijEtbIQGFpPsyXrRp582s+4NfkqFNJ/htp+VnF5G+aFikEiFsvPvgzb6HZV VK507ZjvD2cYMuBUMZroRpWupgpPZml/+Rb1E4ZGVKD3bFsmZun9cFMnlzmTMU8SAgfx 4pFiJCMoBpf2dW4XSqQ39SVU0BegMFIz+yI2mLUvi8a1UCUsnjEkQxVPpC6iv8TZLea7 my+/XWZzWwB8Gn+Dx5UPPygppxaPoAaDwsBJ2uaXGWsNxGadUrD4MjVqA25oblvaK0Vu jKrkWBNonq0GqBHr2xY8pmtclzGDMF0d94kUticpTb5AxjDOqf+UtLN4WmCG2Ra70JGz B55Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZErh6SYyqcHOKTQtgJUo2EAFeU1w0RAc5pJKVSjDGpM=; b=DjiKsSZCidSMezUS1tV3PgU4yC7Vwtl7ckKilqjJ5JhkduJz48jSbJxM2vNE+SmsFz Kn/AJjsX5aTlO2nee+KrYv84NYnujKHkiuWX5K3PnHplNC+SOJSbmYKXpewGTqCwIhzU 9Op8aZgwbX5EV0kMFlmEmRFR6Rj3DeDq7mMOkGsqTnc0pcXYbnKq4uh6jJeJlquMxXkq 4r3FfT69piNh85BVXjWLfwnPmfznpmBE9UkRZZn6wZflk/a4TPJ6m2apDSBzwL46uhxd UM7+BYBd+9wtgtwanOGbrHpZRxKGf33Z6uJI1B4e0uT+NyWkiVUVdBB4WVrkvJ5v0t6x ypcw==
X-Gm-Message-State: ALQs6tB9zJn7z9axiP2kTlruMeuHSBoPry4kqM01SdGPl+olrE5pja/3 P0PsV2YFZ/a2OmAiipCZfyC3WAX9BG/RgKTL6z8SiA==
X-Google-Smtp-Source: AB8JxZpTODeTtoX/+2A25cQZHQM6Ic4XyJ06+2FqGeMO4kiDSi2/CFS7Y9toaUG3tBN6bXkkOXMuqaToxhn2ZY/tvnw=
X-Received: by 2002:aca:ea46:: with SMTP id i67-v6mr16261782oih.174.1525391149337; Thu, 03 May 2018 16:45:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 16:45:08 -0700 (PDT)
In-Reply-To: <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org>
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org> <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 3 May 2018 16:45:08 -0700
Message-ID: <CABcZeBO+2LG4-1-dhzTTSJFH6uhJdSEKLjyVfxO+krzHR8ueQw@mail.gmail.com>
To: Marc Petit-Huguenin <petithug@acm.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-tram-stunbis@ietf.org, tram-chairs@ietf.org, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, tasveren@rbbn.com, tram@ietf.org
Content-Type: multipart/alternative; boundary="00000000000099aba2056b55cd85"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/jD1tVIqJGDZz0yGbOELxkcXbFQg>
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: Thu, 03 May 2018 23:45:53 -0000

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