Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Fri, 21 February 2020 14:53 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D0C120898 for <hipsec@ietfa.amsl.com>; Fri, 21 Feb 2020 06:53:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 eIfvJT9PlRyt for <hipsec@ietfa.amsl.com>; Fri, 21 Feb 2020 06:53:49 -0800 (PST)
Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 EC967120880 for <hipsec@ietf.org>; Fri, 21 Feb 2020 06:53:48 -0800 (PST)
Received: by mail-lf1-x129.google.com with SMTP id 83so1684050lfh.9 for <hipsec@ietf.org>; Fri, 21 Feb 2020 06:53:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TUT5x4l0n7yijh1yU+VFJscCtxilGv5RJgTyMdzzdQk=; b=UqzjBE34xemnoueFyoWctTNkTtcFjYcilWQPA7laQZ5FjFCz/Lna1fu0u2/pmMFtmk u81qCMA1PkjPa+adud+fyzjC2uxRVaky5GGV56p50FxecVkbZ7MdIXOrOJjM5H2MKj+R mRvL50oS9AU05zGteZNLIRoHN1QEvt1h9pdOGlvRxW28CfquDKq8bQEJvRIfVj/ZHS4M l4TGDTErpScYijJuyNiIATzRL/R09+JAmubFCC+RR3mFeur6/sbZ2ji25T+ut+lsKQ15 nZ27gRo6DqNbFD5KmGXjcts/b8WeUwq7DPY2ePS5PsXf/NgJuPqAwVKy4pgXwru1CkD+ Cd2w==
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=TUT5x4l0n7yijh1yU+VFJscCtxilGv5RJgTyMdzzdQk=; b=AY1BEXLjcDFiHajMeMOtWA72/VP6AzZBVYwwzgmsprgB4gW/rDN2wdCVLQkWtvAedp b/+44JhN8pam6WxL4/A0xd8phh7BV9CIzNvo5ln+TvdnQBD8fzlUnYLCowNdkeE3+ttn FLKu12hEaWaxYmCmuCErlXuESEd5iPietvbP1jZgWz+ABkBQdIs4YBrhAJ6+J1ZyOuaY kfJyaYmt40WCCr07uGmYnvucRqyeTUMzWw4hkLz2llKeHBSUYwNoeIF5A6z5cW5lwx6J Ql2DU+G2sVpYg5z1UrfLYy7DzWAqeAvDhj1kDaYj2wi3cMpUoh41qeEEe2xy+2B24xwh MzEg==
X-Gm-Message-State: APjAAAXb5eCY/tpI6Gsjo8QObQUYqF/irK097Qrpu4djKrq47IDdYEWW OOK8dsOoHcNF3IjigsjZhlTxYxKUv11k8Mlyj5ZqRw==
X-Google-Smtp-Source: APXvYqxyWrxmO5PTDFf8j87Iy4KDZuAkU7Ys7QHAF01Y+KuSh+nXCctz/mtWM6+vwb0/R17u36niWPDqs4CJVY7bceU=
X-Received: by 2002:ac2:53b9:: with SMTP id j25mr19669197lfh.140.1582296827119; Fri, 21 Feb 2020 06:53:47 -0800 (PST)
MIME-Version: 1.0
References: <152546246777.11589.13288594519409569524.idtracker@ietfa.amsl.com> <a657ffe0-3574-850e-3b8d-9b21f6f8825b@ericsson.com> <CABcZeBO3gLUZevW0zTN6RHiuYBY+7d-4DefSNBA3FzhXFWfGQw@mail.gmail.com> <47c0cdb7980fa6b9d85d71de926d24ea50a90930.camel@ericsson.com> <CABcZeBOVzKyd1Q6uYi66AFEazhW5OSOwYMBnUqGvjHRk4+0DtA@mail.gmail.com> <20b7460348acc2f3d958ab8ed66a70b49448289a.camel@ericsson.com> <CABcZeBNVBEATYW6-OKK8C0dJ=NzvhRp2N2xmStgNWqTYqQ7-xQ@mail.gmail.com> <82ded3745fe403d24c3866845f5f202f182f9d1e.camel@ericsson.com> <CABcZeBM2Tm5EuF=htBBD0qyYpKarvvgE_LbTKU8n9oBQVPZdsA@mail.gmail.com> <5df6df66bf1d1fdd28d94dfdbf85b17e0f9f4cb2.camel@ericsson.com> <CABcZeBO2LDoB39-7EZo9kk-RGL96Bi4gJ1nwpXxGxwFEsyeuKQ@mail.gmail.com> <163d9a999e5eac1130377dd104f602cfea789506.camel@ericsson.com>
In-Reply-To: <163d9a999e5eac1130377dd104f602cfea789506.camel@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 21 Feb 2020 06:53:10 -0800
Message-ID: <CABcZeBOgVOkoCN95ccXCbUuDkFoxDZOWURu+-VYuxSKsX3t0cg@mail.gmail.com>
To: Miika Komu <miika.komu@ericsson.com>
Cc: "draft-ietf-hip-native-nat-traversal@ietf.org" <draft-ietf-hip-native-nat-traversal@ietf.org>, "hip-chairs@ietf.org" <hip-chairs@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "hipsec@ietf.org" <hipsec@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004f60c4059f1730e6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/3DF_40hbqGON2kxWtDEVQetED1I>
Subject: Re: [Hipsec] Eric Rescorla's Discuss on draft-ietf-hip-native-nat-traversal-28: (with DISCUSS and COMMENT)
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 14:54:02 -0000

I do not have time to assess this claim. I would encourage the security ADs
to do so.

On Fri, Feb 21, 2020 at 6:36 AM Miika Komu <miika.komu@ericsson.com> wrote:

> Hi Eric,
>
> so your original question was:
>
> "The concern is what's known as a "cross-protocol" attack. Is there
> any situation in which there might be ambiguity about two message
> types that are protected with the same key?"
>
> No ambiguity about the message types, because the messages between
> relay client and relay server carry always either a RELAY_FROM or
> RELAY_TO parameter (depending on direction) and this is covered by the
> HMAC.
>
> In the rendezvous case, you have different FROM and VIA_RVS parameters,
> also covered by HMACs.
>
> pe, 2020-02-21 kello 05:34 -0800, Eric Rescorla kirjoitti:
> > Typically in security protocols we look for demonstrations of this.
> > What is your argument for why it cannot?
> >
> > -Ekr
> >
> >
> > On Fri, Feb 21, 2020 at 4:25 AM Miika Komu <miika.komu@ericsson.com>
> > wrote:
> > > Hi,
> > >
> > > to, 2020-02-20 kello 08:58 -0800, Eric Rescorla kirjoitti:
> > > >
> > > >
> > > > On Thu, Feb 20, 2020 at 7:38 AM Miika Komu <
> > > miika.komu@ericsson.com>
> > > > wrote:
> > > > > Hi Eric,
> > > > >
> > > > > to, 2020-02-20 kello 06:04 -0800, Eric Rescorla kirjoitti:
> > > > > >
> > > > > >
> > > > > > On Wed, Feb 19, 2020 at 10:50 PM Miika Komu <
> > > > > miika.komu@ericsson.com>
> > > > > > wrote:
> > > > > > > Hi Eric,
> > > > > > >
> > > > > > > ke, 2020-02-19 kello 13:20 -0800, Eric Rescorla kirjoitti:
> > > > > > > > > > > > S 5.8.
> > > > > > > > > > > >>
> > > > > > > > > > > >>    5.8.  RELAY_HMAC Parameter
> > > > > > > > > > > >>
> > > > > > > > > > > >>       As specified in Legacy ICE-HIP [RFC5770],
> > > the
> > > > > > > > > RELAY_HMAC
> > > > > > > > > > > parameter
> > > > > > > > > > > >>       value has the TLV type 65520.  It has the
> > > same
> > > > > > > > > semantics
> > > > > > > > > > > as RVS_HMAC
> > > > > > > > > > > >>       [RFC8004].
> > > > > > > > > > > >
> > > > > > > > > > > > What key is used for the HMAC?
> > > > > > > > > > >
> > > > > > > > > > > clarified this as follows:
> > > > > > > > > > >
> > > > > > > > > > > [..] It has the same semantics as RVS_HMAC as
> > > specified
> > > > > in
> > > > > > > > > section
> > > > > > > > > > > 4.2.1
> > > > > > > > > > > in [RFC8004].  Similarly as with RVS_HMAC, also
> > > > > RELAY_HMAC
> > > > > > > is
> > > > > > > > > is
> > > > > > > > > > > keyed
> > > > > > > > > > > with the HIP integrity key (HIP-lg or HIP-gl as
> > > > > specified
> > > > > > > in
> > > > > > > > > > > section 6.5
> > > > > > > > > > > in [RFC7401]), established during the relay
> > > > > registration
> > > > > > > > > procedure
> > > > > > > > > > > as
> > > > > > > > > > > described in Section 4.1.
> > > > > > > > > >
> > > > > > > > > > This seems like it might have potential for cross-
> > > > > protocol
> > > > > > > > > attacks on
> > > > > > > > > > the key. Why
> > > > > > > > > > is this OK>
> > > > > > > > >
> > > > > > > > > this is standard way of deriving keys in HIP. The
> > > keying
> > > > > > > procedure
> > > > > > > > > is
> > > > > > > > > the same as with specified in RFC8004. If there is some
> > > > > attack
> > > > > > > > > scenario, please describe it in detail?
> > > > > > > > > Or is there some editorial issue here?
> > > > > > > >
> > > > > > > > I'm not sure. When I read this text it appears to say
> > > that
> > > > > you
> > > > > > > should
> > > > > > > > be using the same key for two kinds of messages. Is that
> > > > > correct?
> > > > > > >
> > > > > > > the key is always specific to a Host Association, i.e.,
> > > unique
> > > > > > > between
> > > > > > > a Relay Client and a Relay Server. So if there is a
> > > Rendezvous
> > > > > > > server
> > > > > > > (used with RVS_HMAC), this would be a different host and
> > > > > different
> > > > > > > Host
> > > > > > > Association. If the same host provides both rendezvous and
> > > > > relay
> > > > > > > service, it should be fine to reuse the same key.
> > > > > >
> > > > > > Why is that OK? Generally we try not to do this. Do you have
> > > a
> > > > > proof
> > > > > > that it is not possible to have one message mistaken for
> > > another?
> > > > >
> > > > > so I assume we are talking about the (artificial) case where a
> > > > > single
> > > > > host provides both Relay and Rendezvous service, and is
> > > > > communicating
> > > > > with a single registered Client? It's the same control channel,
> > > so
> > > > > I
> > > > > don't see any need to have different HMAC keys for different
> > > > > messages
> > > > > since it's still the same two hosts. Or maybe I misunderstood
> > > your
> > > > > scenario, so please elaborate?
> > > >
> > > > The concern is what's known as a "cross-protocol" attack. Is
> > > there
> > > > any situation in which there might be ambiguity about two message
> > > > types that are protected with the same key?
> > >
> > > I don't see any case where this could occur.
>