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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 24 October 2018 13:41 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 2A059128CF3; Wed, 24 Oct 2018 06:41:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Bws2RiV8IAnb; Wed, 24 Oct 2018 06:41:11 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 E6B91127332; Wed, 24 Oct 2018 06:41:08 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id v6-v6so4798975ljc.11; Wed, 24 Oct 2018 06:41:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MPPftkVINzNSnketAlIoNOXC/cFHRSbcnpafYD0DLGg=; b=e62LZ9vypy1AgqyAcckGn+ui0vlue8m7sDqE2nHebux/qTLx+9IVlxyuYHdyyqymRR JYhAJeankgGUYvIfAo4rH8Stee6aMeyy7xKhFgESr/THTC6jHtv/byfIE3UCXug3gUIJ 9k0QzxjibhXYxhGnO6ufS6bQVhhLsRqkqDy0/Wi6XdJQR//FHg4tzZ2DWFsetUUywXU6 I85/wG9ZCd7C5Kyly2TAK4vvD9x2xkdfMC1cJkrI/D4CJH5sZRZXss4sSk3xbab/T3wA JuJT67KKGhkNpz3VDh+BoxEP3aSAlzdQyM+EG1ehgoAh/h9D+g0XKlR4qWfbvzX/lDjT 3J3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MPPftkVINzNSnketAlIoNOXC/cFHRSbcnpafYD0DLGg=; b=ihaNUg08Ic/QoUlsZ67MZtNmt3CFiHOTOOOzSVy6wFCPewP3C0TwW7G3JayLteLomy AXJd8Rx2aexjo2lJ/JlF6BgFydfL/gnc7qq7kqKg7WPtXV0XClQxDWYC02QsUk+IWcXK AZKmT6CzPgB9B4dJdP+QknX8cw6tXB78n+10A78MNGFFgpK629uiEoQDL9BLhqWkhcA8 mmN4hz58AryQFfsXcqI2QkhquOXjO2u++q6fopBH+fcQeURbw5jlR5n4wcPYL0j8Ipzv GZEGCxNThw8K53tid6vyqedNimgVEkg1Wfv/kwLQGm+19q/J+lq+bnCtFfR1duPl95YQ fqDQ==
X-Gm-Message-State: AGRZ1gJxNhM7yfNmkvZEhY0eOgCdVACSpp+7oFv8Jepk3721P3qj2/l7 p6Z4fIxt/tEpXPrvYawyQ0TfFtFGMm2KDddrueALtQ==
X-Google-Smtp-Source: AJdET5e75+2dgU53jbC2IeOqpc3vnjaW30gTI7vlPIIUNK/QQ56MfewdgYNQUWPNZXcruJb+Mx4Qtk8eNIFAcg5DRs8=
X-Received: by 2002:a2e:921a:: with SMTP id k26-v6mr1814117ljg.163.1540388466893; Wed, 24 Oct 2018 06:41:06 -0700 (PDT)
MIME-Version: 1.0
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org> <CABcZeBNk4KWA1Bzw7=i=Siie_6Vf7v-v2cfDyA4WvSAE2D9hrA@mail.gmail.com> <02569943-db8f-654e-7322-49bc1f1a1163@acm.org> <CABcZeBN2=a90qbgo8MkihVFpO2bBzi2Ceepj3UpXVxAZJKJrxg@mail.gmail.com> <235b838f-2800-2cd0-8b01-947e70837619@ericsson.com> <CABcZeBMn1G8BT13bx3JTs04zwQk8K72+btj=xwC662F5AcANXg@mail.gmail.com> <cbb48225-5089-9275-787c-38fa4504a6a4@acm.org> <CABcZeBPNwu-tr8Tf_DiW2iOVy2NDEJoLwAR-6=EWHZak2gVMYg@mail.gmail.com> <c135ad63-bb18-a5f2-4aa2-e2a3268ac26f@acm.org> <CAKKJt-e1XFJNrx-LKmpZFDy6ZuaXt5+Lp+Uw90-Bu-M22PMt3Q@mail.gmail.com> <472563ee-5fc3-655d-8e31-138cc774e608@acm.org>
In-Reply-To: <472563ee-5fc3-655d-8e31-138cc774e608@acm.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 24 Oct 2018 08:40:55 -0500
Message-ID: <CAKKJt-dXijVNnAtYojq9x=9_m0pwAM8XTNP8wUEMvAa+m9UXUA@mail.gmail.com>
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>, "Asveren, Tolga" <tasveren@rbbn.com>, IESG <iesg@ietf.org>, draft-ietf-tram-stunbis@ietf.org
Content-Type: multipart/alternative; boundary="00000000000062ab300578f9a348"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/UbOopRO8aJLkDKS3d_-VXsAgBsc>
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.29
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: Wed, 24 Oct 2018 13:41:17 -0000

Hi, Marc,

On Wed, Oct 24, 2018 at 3:44 AM Marc Petit-Huguenin <petithug@acm.org>
wrote:

> Hi Spencer,
>
> I sent my answers to Eric Rescorla questions on 2018-10-07 following an
> in-person meeting with my co-author, but never got a response back.
> Because there was no change proposed by Eric I went ahead and published -19
> a couple of weeks after that, with the text agreed in response to Adam's
> and Benjamin's comments.
>
> https://www.ietf.org/mail-archive/web/tram/current/msg02635.html


Ah - I wonder if that was what had happened.

It sounds like you did the right thing, and that Eric has now responded,
which is also the right thing to do.

Thanks for helping me understand.

Spencer


> On 10/23/18 7:28 PM, Spencer Dawkins at IETF wrote:
> > Hi, Marc,
> >
> > I see that a -19 has been submitted, but didn't see a reply from Eric in
> > this thread. Do you think that you've converged?
> >
> > (I saw an offer of a conference call, so thought an out-of-band
> > conversation might have happened)
> >
> > Thanks,
> >
> > Spencer
> >
> > On Sun, Oct 7, 2018 at 9:35 AM Marc Petit-Huguenin <petithug@acm.org>
> wrote:
> >
> >> Hi Eric,
> >>
> >> Please see inline.
> >>
> >> On 09/10/2018 03:25 AM, Eric Rescorla wrote:
> >>> On Sat, Sep 8, 2018 at 2:31 PM, Marc Petit-Huguenin <petithug@acm.org>
> >>> wrote:
> >>>
> >>>> Hi Eric,
> >>>>
> >>>> Apologies for the delay in getting back to that.
> >>>>
> >>>> I think that there is some misunderstanding in what STUNbis is trying
> to
> >>>> do, so please see my comments inline.
> >>>>
> >>>> On 06/18/2018 10:43 AM, Eric Rescorla wrote:
> >>>>> Hi folks,
> >>>>>
> >>>>> I've reviewed the new version, but I don't think that the biddown
> >>>>> discussion makes much sense.
> >>>>>
> >>>>> To recap, there are two hashes here:
> >>>>>
> >>>>> - The hash which you use to store the password with (currently mostly
> >>>> MD5)
> >>>>> - The hash you use to compute the MAC (currently SHA-1).
> >>>>>
> >>>>> First, let's stipulate that MD5 isn't a great choice here, though
> SHA-1
> >>>>> isn't a great choice
> >>>>> either for pwd hashing You want Argon or the like. With that said,
> >>>> there's
> >>>>> no sensible
> >>>>> biddown attack on that hash because it's a per-server feature, not a
> >>>>> per-transaction
> >>>>> feature. So, as long as the server has MD5-hashed passwords, the
> >>>> situation
> >>>>> is bad.
> >>>>
> >>>> In no place in STUNbis we are proposing to use SHA-1 for password
> >>>> encryption, so I am not sure where that come from.  What we propose
> is:
> >>>>
> >>>
> >>> You're right, it's SHA-256, but my criticisms apply equally there.
> >>
> >> SHA-256 was what the WG adopted.  Our attempts to add other passwords
> >> encryption mechanisms were denied.  It is true that Argon2 was not in
> that
> >> list (in our defense Argon2 was not known before July 2015), but I do
> not
> >> see why the WG would have accepted that one over the others.  Anyway it
> is
> >> too late to fix this, as it is my understanding that the WG does not
> have
> >> enough energy to reach consensus on a new password algorithm.  Someone
> can
> >> just write a draft adding Argon2 as password encryption, as we will
> have a
> >> IANA registry for that.
> >>
> >>>
> >>>
> >>>> - Establish a registry for new password algorithms (section 18.5), so
> >>>> algorithms like Argon2 could be added later (but note that our own
> >>>> proposals to add more password algorithms were rejected by the working
> >>>> group).
> >>>> - Add a new password algorithm to that registry, namely SHA-256.
> >>>> - Register MD5 as an initial password algorithm for backward
> >> compatibility
> >>>> purpose.
> >>>>
> >>>> As for the biddown protection itself, it is my recollection that it
> >>>> happened more or less like that:
> >>>>
> >>>>
> >>>> INT. MEETING ROOM - DAY
> >>>>
> >>>> One of the co-editors of STUNBis stands at the microphone:
> >>>>
> >>>>                            CO-EDITOR
> >>>>                  We added SHA-256 protection for passwords
> >>>>                  in STUNBis.
> >>>>
> >>>>                            SOMEONE (V.O.)
> >>>>                  As MD5 still need to be supported, you need to add
> >>>>                  protection for bid-down attacks.
> >>>>
> >>>> CLOSE-UP on CO-EDITOR ROLLING HIS EYES
> >>>>
> >>>>                            CO-EDITOR
> >>>>                  OK, I'll work on that.
> >>>>
> >>>> Four to eight months has passed.
> >>>>
> >>>> INT. ANOTHER MEETING ROOM - DAY
> >>>>
> >>>> The same co-editor of STUNBis stands at the microphone:
> >>>>
> >>>>                            CO-EDITOR
> >>>>                  We added a nice mechanism to prevent bid-down
> >>>>                  attacks on passwords.  Any comments?
> >>>>
> >>>>                            THE ROOM
> >>>>                  (silence)
> >>>>
> >>>>                            CO-EDITOR
> >>>>                  Moving on...
> >>>>
> >>>
> >>> I don't see how any of this is relevant to my technical points above.
> >>
> >> My point was that we, the co-editors, did not decide on adding bid-down
> >> protection, someone asked us to do so and no-one in the WG saw any
> problem
> >> with that.  The reasons that person wanted that are not known to us
> but, as
> >> you insist, here's one reason I can think of:
> >>
> >> It is a fact that, for operational reasons, a password database cannot
> be
> >> re-encrypted at once.  Also for operational reasons, the MD5 password
> >> cannot be immediately removed from the database as soon the user
> submitted
> >> a new one.  In fact, and for quite some time, both encrypted variants of
> >> the same password may have to be kept in that database, because a single
> >> user may use a mix of devices, some of them that use an RFC 5389 client,
> >> some that use a STUNbis client.  It is up to the STUN server owner to
> >> decide how long the migration to STUNbis will take and when it will be
> >> acceptable to reject all RFC 5389 (i.e. MD5) clients (that migration
> time
> >> can be purposely reduced to 0 seconds but that's the choice and
> >> responsibility of the owner of the server).
> >>
> >> Meanwhile we still need to be sure that if the STUN client is
> implementing
> >> STUNbis it unconditionally gets the additional protection of the new
> >> password encryption algorithm.  That's where the biddown protection
> kicks
> >> in, by preventing an online attacker to have the server misidentifying a
> >> STUNbis client as an RFC 5389 client, by preventing an online attacker
> to
> >> have the client misidentifying a STUNbis server as a RFC 5389 server,
> and
> >> having both them use the MD5 encrypted password instead of the SHA-256
> >> encrypted password, all of that easily done by stripping the unprotected
> >> 401 response of the new STUNbis PASSWORD-ALGORITHMS attribute.
> >>
> >>>
> >>>
> >>>
> >>>>> The second topic is the hash used to compute the MAC. However, I
> don't
> >>>> see
> >>>>> how
> >>>>> this gives you sensible biddown protection because that hash is also
> >> used
> >>>>> to compute
> >>>>> MAC over the negotiation: an attacker who has compromised a MAC which
> >> the
> >>>>> server
> >>>>> supports will quite likely be able to forge a MAC over the transcript
> >> as
> >>>>> well. This is,
> >>>>> I suppose, potentially useful as a defense against some other
> weakness
> >>>>> (e.g.,
> >>>>> version #), but I don't really see how the current design helps
> against
> >>>>> attacks on the
> >>>>> MAC.
> >>>>
> >>>> There is no biddown attack protection for the MAC, as stated in
> Section
> >>>> 16.3:
> >>>>
> >>>> "The bid-down protection mechanism described in this document is new,
> >>>>  and thus cannot currently protect against a bid-down attack that
> >>>>  lowers the strength of the hash algorithm to HMAC-SHA1."
> >>>>
> >>>> What we put in place is a plan for *future* versions of STUN to get
> >>>> biddown protection for the MAC.  That's it, no more, no less.
> >>>>
> >>>
> >>> Yes, but I don't believe that this will provide bid-down protection for
> >> the
> >>> MAC in the future for the reasons I indicate above.
> >>>
> >>> If you think this does something useful, please show me an example
> attack
> >>> and how this fixes it. Note that it's not generally useful to just bid
> >> down
> >>> the MAC itself unless the MAC you bid down to is weak enough to exploit
> >> in
> >>> some other way.
> >>
> >> I do not know what weaknesses will be discovered in the future.  I am
> also
> >> pretty sure that the cost of not using that mechanism is very close to
> 0.
> >> What I am sure of is that the cost of reengineering a new biddown
> >> protection mechanism if we ever need it will be high.  We already went
> >> through the pains of designing one for the password algorithm, so why
> not
> >> extend it so it can be used in the aftermath of the next Snowden
> facepalm
> >> moment?
> >>
> >>> Again, happy to have a call to walk though this if that
> >>> helps.
> >>>
> >>> -Ekr
> >>>
> >>>
> >>>
> >>>
> >>>>>
> >>>>> You might think that there was a MAC which was easier to reverse to
> >> find
> >>>>> the original
> >>>>> password, but the defense you have here doesn't help with that
> because
> >>>> the
> >>>>> on-path attacker can do a bid-down and use the client as a MAC oracle
> >> for
> >>>>> any MAC the client supports.
> >>>>>
> >>>>> So, I still don't understand what this is supposed to do. Happy to
> >> have a
> >>>>> call if you
> >>>>> think that helps
> >>>>>
> >>>>> -Ekr
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Mon, Jun 18, 2018 at 3:40 AM, Gonzalo Camarillo <
> >>>>> Gonzalo.Camarillo@ericsson.com> wrote:
> >>>>>
> >>>>>> Marc, Eric,
> >>>>>>
> >>>>>> what is the status of this discussion?
> >>>>>>
> >>>>>> Thanks,
> >>>>>>
> >>>>>> Gonzalo
> >>>>>>
> >>>>>> On 04/05/2018 2:35 AM, Eric Rescorla wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin <
> >>>> petithug@acm.org
> >>>>>>> <mailto:petithug@acm.org>> wrote:
> >>>>>>>
> >>>>>>>     On 04/22/2018 05:22 PM, Eric Rescorla wrote:
> >>>>>>>     > On Sun, Apr 22, 2018 at 2:02 PM, Marc Petit-Huguenin <
> >>>>>> petithug@acm.org <mailto:petithug@acm.org>>
> >>>>>>>     > wrote:
> >>>>>>>     >
> >>>>>>>     >>
> >>>>>>>     >>>>      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.
> >>>>>>>     >>
> >>>>>>>     >
> >>>>>>>     > I hear what you're saying, but publishing two documents at
> the
> >>>>>> same time
> >>>>>>>     > which
> >>>>>>>     > make contrary recommendations about the same basic protocol
> is
> >>>>>> un-good.
> >>>>>>>
> >>>>>>>     Sure, but wouldn't it be simpler to have rfc5245bis using
> stunbis
> >>>>>>>     and have them updating their text, more than adding some
> tortuous
> >>>>>>>     text in stunbis?
> >>>>>>>
> >>>>>>>     >
> >>>>>>>     >
> >>>>>>>     >>>      The STUN usage must specify which transport protocol
> is
> >>>>>> used, and
> >>>>>>>     >> how
> >>>>>>>     >>>>      the agent determines the IP address and port of the
> >>>>>> recipient.
> >>>>>>>     >>>>      Section 8 describes a DNS-based method of determining
> >> the
> >>>>>> IP
> >>>>>>>     >> address
> >>>>>>>     >>>>      and port of a server that a usage may elect to use.
> >> STUN
> >>>>>> may be
> >>>>>>>     >> used
> >>>>>>>     >>>>      with anycast addresses, but only with UDP and in
> usages
> >>>>>> where
> >>>>>>>     >>>>      authentication is not used.
> >>>>>>>     >>>
> >>>>>>>     >>> Why this restriction? You should be able to use anycast
> with
> >>>>>> long-term
> >>>>>>>     >>> AUTH for (say) TURN.
> >>>>>>>     >>
> >>>>>>>     >> https://www.ietf.org/mail-archive/web/behave/current/
> >>>>>> msg03582.html
> >>>>>>>     <https://www.ietf.org/mail-archive/web/behave/current/
> >>>> msg03582.html>
> >>>>>>>     >>
> >>>>>>>     >> I think that the decision of permitting Anycast should be
> left
> >>>> to
> >>>>>> each
> >>>>>>>     >> STUN Usage.  Basic STUN Usage does not use authentication
> and
> >>>> use
> >>>>>> only a
> >>>>>>>     >> one round trip for the Binding transaction, so Unicast can
> be
> >>>>>> used.
> >>>>>>>     >>
> >>>>>>>     >
> >>>>>>>     >> OTOH, TURN and ICE should probably say something about that,
> >> so
> >>>> I
> >>>>>> added a
> >>>>>>>     >> new bullet point in Section 13:
> >>>>>>>     >>
> >>>>>>>     >>    o  If Anycast addresses can be used for the server in
> case
> >>>> TCP
> >>>>>> or
> >>>>>>>     >>       TLS-over-TCP, or authentication are used.
> >>>>>>>     >>
> >>>>>>>     >
> >>>>>>>     > Are you leaving this text in? That seems very confusing.
> >>>>>>>
> >>>>>>>     In isolation yes, but I think it makes sense which the text
> >> before
> >>>>>>>     the bullet points:
> >>>>>>>
> >>>>>>>        A STUN usage defines how STUN is actually utilized -- when
> to
> >>>> send
> >>>>>>>        requests, what to do with the responses, and which optional
> >>>>>>>        procedures defined here (or in an extension to STUN) are to
> be
> >>>>>> used.
> >>>>>>>        A usage also defines:
> >>>>>>>
> >>>>>>>     [...]
> >>>>>>>
> >>>>>>>        o  If Anycast addresses can be used for the server in case
> TCP
> >>>> or
> >>>>>>>           TLS-over-TCP, or authentication are used.
> >>>>>>>
> >>>>>>>
> >>>>>>> What is the need for the restriction at all.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>     >>>>      transaction over UDP or DTLS-over-UDP is also
> >> considered
> >>>>>> failed if
> >>>>>>>     >>>>      there has been a hard ICMP error [RFC1122].  For
> >> example,
> >>>>>> assuming
> >>>>>>>     >> an
> >>>>>>>     >>>>      RTO of 500ms, requests would be sent at times 0 ms,
> 500
> >>>>>> ms, 1500
> >>>>>>>     >> ms,
> >>>>>>>     >>>>      3500 ms, 7500 ms, 15500 ms, and 31500 ms.  If the
> >> client
> >>>>>> has not
> >>>>>>>     >>>>      received a response after 39500 ms, the client will
> >>>>>> consider the
> >>>>>>>     >>>>      transaction to have timed out.
> >>>>>>>     >>>
> >>>>>>>     >>> I note that these recommendations now seem crazily long. I
> >>>>>> assume the
> >>>>>>>     >>> WG had consensus on this, but I wanted to note it.
> >>>>>>>     >>
> >>>>>>>     >> Not just the WG, also the IESG that approved RFC 5389 too
> as,
> >>>> but
> >>>>>> for the
> >>>>>>>     >> addition of "or DTLS-over-UDP", this is the same text than
> in
> >>>> RFC
> >>>>>> 5389.
> >>>>>>>     >>
> >>>>>>>     >
> >>>>>>>     > Yes, I know. My point is that while they might have bee
> >> sensible
> >>>>>> when
> >>>>>>>     > 5389 was published they *now* seem crazily long. Did the WG
> >>>>>> explicitly
> >>>>>>>     > decide not to update them?
> >>>>>>>
> >>>>>>>     No, nobody ever suggested that there was an issue there.
> >>>>>>>
> >>>>>>>
> >>>>>>> OK, well, this seems like it should be considered, then, because
> this
> >>>>>>> doesn't
> >>>>>>> match modern practice.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>     > This would be good to explain.
> >>>>>>>
> >>>>>>>     New text:
> >>>>>>>
> >>>>>>>        [...]
> >>>>>>>        containing the subjectAltName of that certificate.  The test
> >> on
> >>>>>> the
> >>>>>>>        MESSAGE-INTEGRITY-SHA256 attribute indicates that the
> >>>> transaction
> >>>>>> is
> >>>>>>>        authenticated and that the client implements this
> >> specification
> >>>>>> and
> >>>>>>>        so can process the ALTERNATE-DOMAIN attribute.
> >>>>>>>
> >>>>>>>
> >>>>>>> All right.
> >>>>>>>
> >>>>>>>
> >>>>>>>     >
> >>>>>>>     >
> >>>>>>>     >>>>      o  What authentication and message-integrity
> mechanisms
> >>>>>> are used.
> >>>>>>>     >>>>
> >>>>>>>     >>>>      o  The considerations around manual vs. automatic key
> >>>>>> derivation
> >>>>>>>     >> for
> >>>>>>>     >>>>         the integrity mechanism, as discussed in
> [RFC4107].
> >>>>>>>     >>>>
> >>>>>>>     >>>>      o  What mechanisms are used to distinguish STUN
> >> messages
> >>>>>> from other
> >>>>>>>     >>>
> >>>>>>>     >>> Why is this required? It seems like that's a generic STUN
> >>>>>> feature.
> >>>>>>>     >>
> >>>>>>>     >> That text is identical to the text in RFC 5389.  RFC
> 5764/7983
> >>>> is
> >>>>>> one such
> >>>>>>>     >> mechanism, but there is nothing that prevent another
> protocol
> >>>>>> stack to use
> >>>>>>>     >> a different mechanism (inference, shim, etc...)
> >>>>>>>     >>
> >>>>>>>     >
> >>>>>>>     > But ultimately no matter what the other protocol provides for
> >>>>>> demux, STUN
> >>>>>>>     > has its
> >>>>>>>     > own demux.
> >>>>>>>
> >>>>>>>     In fact I think that the reason for that item was because
> >>>>>>>     FINGERPRINT can also be used to demux STUN traffic, but it is
> >>>>>>>     optional.  So an STUN Usage needs to tell if FINGERPRINT is
> >>>>>>>     mandatory (like in ICE).
> >>>>>>>
> >>>>>>>
> >>>>>>> This should be explained.
> >>>>>>>
> >>>>>>>
> >>>>>>>     >>>
> >>>>>>>     >>>>      that is not readily subject to offline dictionary
> >>>> attacks.
> >>>>>>>     >>>>      Protection of the channel itself, using TLS or DTLS,
> >>>>>> mitigates
> >>>>>>>     >> these
> >>>>>>>     >>>>      attacks.
> >>>>>>>     >>>>
> >>>>>>>     >>>>      STUN supports both MESSAGE-INTEGRITY and
> >>>>>>>     MESSAGE-INTEGRITY-SHA256,
> >>>>>>>     >>>>      which is subject to bid down attacks by an on-path
> >>>>>> attacker.
> >>>>>>>     >>>
> >>>>>>>     >>> By an on-path attacker who can forge HMAC-SHA1 in
> real-time?
> >>>>>>>     That's a
> >>>>>>>     >>> pretty serious adversary, so you should clarify here
> >>>>>>>     >>>
> >>>>>>>     >>
> >>>>>>>     >> New text:
> >>>>>>>     >>
> >>>>>>>     >>    STUN supports both MESSAGE-INTEGRITY and
> >>>>>> MESSAGE-INTEGRITY-SHA256,
> >>>>>>>     >>    which is subject to bid down attacks by an on-path
> attacker
> >>>>>> that
> >>>>>>>     >>    would strip the MESSAGE-INTEGRITY-SHA256 attribute
> leaving
> >>>>>>>     only the
> >>>>>>>     >>    MESSAGE-INTEGRITY attribute and exploiting a potential
> >>>>>>>     vulnerability.
> >>>>>>>     >>    Protection of the channel itself, using TLS or DTLS,
> >>>> mitigates
> >>>>>>>     these
> >>>>>>>     >>    attacks.  Timely removal of the support of
> >> MESSAGE-INTEGRITY
> >>>>>> in a
> >>>>>>>     >>    future version of STUN is necessary.
> >>>>>>>     >>
> >>>>>>>     >
> >>>>>>>     > I still don't understand the capabilities you seem to believe
> >> the
> >>>>>>>     attacker
> >>>>>>>     > has.
> >>>>>>>     > Can you describe the exact attack.
> >>>>>>>     >
> >>>>>>>
> >>>>>>>     1. Vulnerability is found in HMAC-SHA1
> >>>>>>>     2. Client Alice still supports M-I and M-I-256, does not know
> >> what
> >>>>>>>     version of STUN server Bob supports and so send both.
> >>>>>>>     3. On-path attacker removes M-I-256.
> >>>>>>>     5. stunbis server Bob thinks that Alice is an RFC 5389 client
> and
> >>>>>>>     continue with that protocol.
> >>>>>>>
> >>>>>>>
> >>>>>>> This seems like an extremely weak attack. In general, any protocol
> of
> >>>>>>> this type is as strong
> >>>>>>> as the weakest integrity algorithm it supports, so it's not that
> the
> >>>>>>> protocol has a downgrade
> >>>>>>> attack, but rather that the minimum algorithm supported is one you
> >>>> don't
> >>>>>>> trust as much
> >>>>>>> as you might like.
> >>>>>>>
> >>>>>>> -Ekr
> >>>>>>>
> >>>>>>>
> >>>>>>>     --
> >>
>
>
>
> --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>