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, 03 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. >
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- [tram] Eric Rescorla's Discuss on draft-ietf-tram… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Brandon Williams
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Matthew A. Miller
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Brandon Williams
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Marc Petit-Huguenin
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Camarillo
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Spencer Dawkins at IETF
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- [tram] Blackout posting of draft-ietf-tram-stunbi… Spencer Dawkins at IETF
- Re: [tram] Blackout posting of draft-ietf-tram-st… Gonzalo Salgueiro (gsalguei)