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:35 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 C6BE312DA05 for <tram@ietfa.amsl.com>; Thu, 3 May 2018 16:35:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Ywr8npiyHg6A for <tram@ietfa.amsl.com>; Thu, 3 May 2018 16:35:42 -0700 (PDT)
Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::232]) (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 7309F12DA43 for <tram@ietf.org>; Thu, 3 May 2018 16:35:42 -0700 (PDT)
Received: by mail-ot0-x232.google.com with SMTP id m11-v6so16443587otf.3 for <tram@ietf.org>; Thu, 03 May 2018 16:35:42 -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=9PqAb68NDHbdHGm3ISwNk6n09yGuIh5ZDpH4Qt9UUCk=; b=UqpCemfeDtefsBjk7hoMmb59jWPT6UwOZw1r76GYuTXI67UAIfNIMXsZQVV15twlAm bK3TuthEEF298gBfcjQWf2UbkJ3L1ZGgZl0eO4lmHKt+GXSvF9JKWqO0elGo1TUo3W6x L3suI7qH5cA9MYbqHBvCT5phfFiutWPF/dUHVdZormr1aSU4Br3tMBVr39ZT75T7SaZT /Ap73NWPT0r8wcBgBw01M4C2oohGPL92g/kWV+G2zAeSVLLwgvbHj6OePU3n8+dtU1ds jmM8hZBLexLVxBoC97KzkSO0xcp2CWnQ9TlrRVkj7XUbQw1u8x2GeA5J6JH6RUX8m8ad uqGA==
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=9PqAb68NDHbdHGm3ISwNk6n09yGuIh5ZDpH4Qt9UUCk=; b=HXtHmfa7y2O4K1fqBOaaByKlY9GxyCFVMeDEGjHGxefh/VZ1c7Q89GadtRU8Iiuv6e 5nXeD/q1AX4rLdNkbACukhxjjEZAUmJTtR+WF7jZ7WJ6miBV076kS0f5FCQ4L+WKpBUx ZzhnL5wxBHDJ/nxZNQ605yj4s4gq/jDRwDsfo8xOkkm9r8cE/pRiDfianqsi6XSkGTJW T/BDtgcQBA5UCzy77IMOrBgQaAbGlmIfphWWRjrRbfiihEu2VzKkgfNQ/0jDQn4ZAr38 qezBVMHUR7Gu4l7vFvwXCMv+24t48SZhZ710diOhm0WdyK057T89U8mDWIcZ4bhwciDC tEAA==
X-Gm-Message-State: ALQs6tDkY2nKvFqTv+lSRaRBlxtKhiT1aoaMqThSaVLHw61RQm8ex9o1 n4vrxHvPqPCHrAZxQgtTW+IKmF1ciLp1zS+owIUh+g==
X-Google-Smtp-Source: AB8JxZqVWE5NKYBcaScrCSZoMYDEKKRUOwrEfAcp9pl00lnAQQVzzz/37Txf8Pg8UMwKTU8sXeXEtVdUBlxymvQXCNA=
X-Received: by 2002:a9d:334f:: with SMTP id u15-v6mr17081667otd.214.1525390541756; Thu, 03 May 2018 16:35:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.118.130 with HTTP; Thu, 3 May 2018 16:35:01 -0700 (PDT)
In-Reply-To: <02569943-db8f-654e-7322-49bc1f1a1163@acm.org>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 3 May 2018 16:35:01 -0700
Message-ID: <CABcZeBN2=a90qbgo8MkihVFpO2bBzi2Ceepj3UpXVxAZJKJrxg@mail.gmail.com>
To: Marc Petit-Huguenin <petithug@acm.org>
Cc: 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
Content-Type: multipart/alternative; boundary="00000000000062b5bb056b55a9ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/2_HYes8Dkl_G3HX8O2gyEwG6-do>
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:35:47 -0000

On Mon, Apr 23, 2018 at 11:16 AM, Marc Petit-Huguenin <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>
> > 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
> >>
> >> 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
>
>