Return-Path: X-Original-To: trill@ietfa.amsl.com Delivered-To: trill@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9E12D77A for ; Sun, 18 Mar 2018 06:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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] 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 5Xfgbkh-LAWJ for ; Sun, 18 Mar 2018 06:44:06 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 0615012DA15 for ; Sun, 18 Mar 2018 06:44:03 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id w6so2761899qkb.4 for ; Sun, 18 Mar 2018 06:44:02 -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=B1h318d7bCIQ2hEF/Xu6onpEtPoLSIJQM1DV5XAL4No=; b=Chq5JI8/nY6Og/+ZKdrIc+DkQFIijrS3kkVWlEh2kU5pS9/HdptjstH3CaZv++7n72 cfWFqvTxjOUUtFAVcNzTM8ac3rh24I7bohBcM7DPOuimCkFKcL9wjOBMsTHCcrWC9Oh4 7/Mz+ztWzBdD7c+wIsDX6e0Qo/tMciW9aoxu5s/36MLzjt8bNC6pEX05Rvj8HR4GIi// vyOsuQ+OR0QRg+vQ9wYQxU5nKi4CAnZfhnM46BcaQ2HWiMavsCxnMQCxKp1htiFlhAB2 9vYgD0rj3EK+fMg1gWTt3VDZjznB9q5qi03xrO0AIb9nULCdDl4avxvZC415nJQF61+9 ziBg== 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=B1h318d7bCIQ2hEF/Xu6onpEtPoLSIJQM1DV5XAL4No=; b=ZEOYvErr/jFGdYjAToHFxhIzcj7ymsHXYKZDr4ni7gkwpx9FkyRu5VtrIo5eZfdyS7 WzzUROFeq0/J92xxMgTTiQ7HOhREGmAw99HakOD1TIZM8QhKD8IHM/IfXe02QOD6tFlM KAFUFfV0QgeXJ+R0yHt63Fvy21jGfsiGYh9PSrWB5W5phnpqaDrZ+Lw3JcQSxRU2xmlY eklDkj8Gbo8UeFzIC2lGuTx0AeoHxYK+6+KNWtvFzPg3oED5Gc44J6KvxHotsP5FTYju 47Mgp6wdIE0+YNZIKFRcVtcs9Keg0IR2WEF0EOhjStzEMgjlQnBSYDxEB7WwqWxy+Q2v K4nQ== X-Gm-Message-State: AElRT7GQosukT28zFIVElh7a9bgKAfbYWZMzFm9JMMNGmwhL7TYlkg6n tfV9Tc28WGY+/EbGo1GOU4fcv/o5Kjcok5wLZtlZ0Q== X-Google-Smtp-Source: AG47ELtszMOnxp27dRaaO8HDEUrBQrdY7PnZlOg/fohJCEkwqcm1ZazFCXAWILw3bU9SBBTLeY0yo40EqPBVo/6wKP0= X-Received: by 10.55.192.151 with SMTP id v23mr12843068qkv.83.1521380642028; Sun, 18 Mar 2018 06:44:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.37.234 with HTTP; Sun, 18 Mar 2018 06:43:21 -0700 (PDT) In-Reply-To: References: <152136336568.18246.2247428495885349462.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Sun, 18 Mar 2018 13:43:21 +0000 Message-ID: To: Donald Eastlake Cc: The IESG , draft-ietf-trill-over-ip@ietf.org, trill-chairs@ietf.org, Susan Hares , trill IETF mailing list Content-Type: multipart/alternative; boundary="001a114797c6bc9e060567b00888" Archived-At: Subject: Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT) X-BeenThere: trill@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Developing a hybrid router/bridge." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 13:44:08 -0000 --001a114797c6bc9e060567b00888 Content-Type: text/plain; charset="UTF-8" On Sun, Mar 18, 2018 at 12:21 PM, Donald Eastlake wrote: > Hi Eric, > > On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla wrote: > > Eric Rescorla has entered the following ballot position for > > draft-ietf-trill-over-ip-15: Discuss > > > > ... > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Hopefully this is easy to resolve. In the best case, you will be > > able to demonstrate that this is not a problem in practice and > > document that. If not, the actual fix is straightforward, though > > incompatible. > > > > S 7.1.1. > > I am concerned about the use of the IS-IS key in this way. First, on > > general principles, you should not use a single key both as input to a > > KDF and directly as a working key. Specifically, however, RFC 5310 > > defines the use of HMAC authentication with IS-IS-key as the HMAC > > key, and HKDF-Expand is really just SHA-256. Thus, if an attacker > > was able to observe (or cause to be created) an IS-IS packet that > > happened to have the same contents as the HKDF Info value you > > provide would then know the IKE PSK. > > > > The correct practice here is to separately expand both the IS-IS > > key *and* the IKE PSK from the same original value. If you cannot > > do that, you should at least generate an Info value which is > > guaranteed to not be the input to any RFC 5310 MAC. > > The source may not be easily accessible. > > The first byte of the data to which the RFC 5310 MAC is applied is always > 0x83, the Interdomain Routeing Discriminator. The first byte of the data > below is 0x54 ('T') so they cannot be the same. > > HKDF-Expand-SHA256 ( IS-IS-key, > "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-Port ) > > > Could also add some text such as "Note that the value to which the HKDF > function is applied starts with 0x54 ('T') while the data to which RFC 5310 > authentication is applied (an IS-IS PDU) starts with 0x83, the Interdomain > Routeing Discriminator, thus, although they are both SHA256 based, they are > never applied to the same value." > OK. This is not cryptographically ideal (you really should be deriving two separate keys from HKDF) but given this I am not aware of any weakness. We could presumably consult with someone like Karthik Bhargavan or Hugo Krawczyk, but I imagine you'd just get "we don't know of any problems", but it's not great, which is more or less my position. Based on this, I will withdraw my DISCUSS and assume that Alia can shepherd these changes. > When IS-IS security is in use, IKEv2 SHOULD use a pre-shared key that > > incorporates the IS-IS shared key in order to bind the TRILL data > > session to the IS-IS session. The pre-shared key that will be used > > > > The technique you provide does not guarantee a binding between the > > sessions. It merely ensures (modulo the caveat above) that both sides > > know the IS-IS Key. It's easy to see this by noting that you could > > move IS-IS traffic from one IPsec association to another. If you > > actually want to bind these sessions, you must do something different. > > I think the idea was just that, in conjunction with the text later in this > section, the IPsec key wouldn't be used for longer than the IS-IS key. > > How about just deleting the words "in order to bind the TRILL data session > to the IS-IS session."? > That seems fine to me. > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I see that native encapsulation is incompatible with NATs (S 8). > > That's probably worth stating upfront to minimize confusion. > > > > S 5.4.2. > > > > f. No middleboxes are allowed in the TRILL over IP transport link > > because middlebox support is beyond the scope of this document. > > > > How would you know if no middleboxes were in the link? > > Well, if they map IP addresses, the "neighbor" values inside the Hellos > will not get mapped, will not match, and thus you will be unable to > establish adjacency and nothing will flow over the link except Hellos (no > data, LSPs, etc.). You need an application specific gateway for TRILL to > operate through a NAT. On the other hand, a sufficiently benign middlebox > (if there are such things) which, for example, only had a black list of > some IP protocols / ports / addresses, that had no effect on the TRILL data > or control traffic would be pretty invisible and TRILL should work fine > through it. > > How about the following replacement text: > > f. This document assumes there are no middleboxes in the path and thus > does not cover restrictions on such middleboxes. Middlebox support is > beyond the scope of this document. > > SGTM. > S 5.5. > > Can you use VXLAN with IPsec? > > "VXLAN" is really Ethernet over VXLAN over UDP. I don't see a problem with > doing Ethernet over VXLAN over UDP over IPsec. > Perhaps worth mentioning. > S 5.6. > > What security mechanism do you expect to use for TCP? IPsec again? > > Yes. > Also perhaps worth mentioning. > > the timing and implementation details may be such that P! and P2 each > > > > Nit: P1, right? > > Yes, sorry about that pesky shift key... > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 <(508)%20333-2270> (cell) > 155 Beaver Street, Milford, MA 01757 USA > > d3e3e3@gmail.com > > --001a114797c6bc9e060567b00888 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Mar 18, 2018 at 12:21 PM, Donald Eastlake <= ;d3e3e3@gmail.com= > wrote:
Hi Er= ic,

On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla = <ekr@rtfm.com> = wrote:
> Eric Rescorla has entered the following ballot position for<= br>> draft-ietf-trill-over-ip-15: Discuss
>
> ...
>
> ----------------------------------------= ------------------------------
> DISCUSS:
> --------------= --------------------------------------------------------
><= br>> Hopefully this is easy to resolve. In the best case, you will be> able to demonstrate that this is not a problem in practice and
>= ; document that. If not, the actual fix is straightforward, though
> = incompatible.
>
> S 7.1.1.
> I am concerned about the use= of the IS-IS key in this way. First, on
> general principles, you sh= ould not use a single key both as input to a
> KDF and directly as a = working key. Specifically, however, RFC 5310
> defines the use of HMA= C authentication with IS-IS-key as the HMAC
> key, and HKDF-Expand is= really just SHA-256. Thus, if an attacker
> was able to observe (or = cause to be created) an IS-IS packet that
> happened to have the same= contents as the HKDF Info value you
> provide would then know the IK= E PSK.
>
> The correct practice here is to separately expand bo= th the IS-IS
> key *and* the IKE PSK from the same original value. If= you cannot
> do that, you should at least generate an Info value whi= ch is
> guaranteed to not be the input to any RFC 5310 MAC.

The source may not be easily accessible.

The first byte of the data to which the RFC 5310 MAC is applied is always = 0x83, the Interdomain Routeing Discriminator. The first byte of the data be= low is 0x54 ('T') so they cannot be the same.

<= div>
=
     HKDF-Expand-SHA256 ( IS-IS-key,
         "TRILL IP" | P1-System-ID | P1-Port | P2-System-ID | P2-=
Port )

Could also add some text such as "Note that the v= alue to which the HKDF function is applied starts with 0x54 ('T') w= hile the data to which RFC 5310 authentication is applied (an IS-IS PDU) st= arts with 0x83, the Interdomain Routeing Discriminator, thus, although they= are both SHA256 based, they are never applied to the same value."

OK. This is not cryptographically = ideal (you really should be deriving two separate keys from HKDF) but given= this I am not aware of any weakness. We could presumably consult with some= one like Karthik Bhargavan or Hugo Krawczyk, but I imagine you'd just g= et "we don't know of any problems", but it's not great, w= hich is more or less my position.

Based on this, I= will withdraw my DISCUSS and assume that Alia can shepherd these changes.<= /div>


> =C2=A0 =C2=A0When IS-IS security is in = use, IKEv2 SHOULD use a pre-shared key that
> =C2=A0 =C2=A0incorporat= es the IS-IS shared key in order to bind the TRILL data
> =C2=A0 =C2= =A0session to the IS-IS session.=C2=A0 The pre-shared key that will be used=
>
> The technique you provide does not guarantee a binding bet= ween the
> sessions. It merely ensures (modulo the caveat above) that= both sides
> know the IS-IS Key. It's easy to see this by noting= that you could
> move IS-IS traffic from one IPsec association to an= other. If you
> actually want to bind these sessions, you must do som= ething different.

I think the idea was just that, in conjunct= ion with the text later in this section, the IPsec key wouldn't be used= for longer than the IS-IS key.

How about just deleting the w= ords "in order to bind the TRILL data session to the IS-IS session.&qu= ot;?

That seems fine to me.
=C2=A0

> -------------------------------= ---------------------------------------
> COMMENT:
> -----= -----------------------------------------------------------------=
>
> I see that native encapsulation is incompatible with NATs = (S 8).
> That's probably worth stating upfront to minimize confus= ion.
>
> S 5.4.2.
>
> =C2=A0 =C2=A0 =C2=A0 f. No mi= ddleboxes are allowed in the TRILL over IP transport link
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0because middlebox support is beyond the scope of= this document.
>
> How would you know if no middleboxes were i= n the link?

Well, if they map IP addresses, the "neighbo= r" values inside the Hellos will not get mapped, will not match, and t= hus you will be unable to establish adjacency and nothing will flow over th= e link except Hellos (no data, LSPs, etc.). You need an application specifi= c gateway for TRILL to operate through a NAT. On the other hand, a sufficie= ntly benign middlebox (if there are such things) which, for example, only h= ad a black list of some IP protocols / ports / addresses, that had no effec= t on the TRILL data or control traffic would be pretty invisible and TRILL = should work fine through it.

How about the followi= ng replacement text:
f. This document assumes there are no middle= boxes in the path and thus does not cover restrictions on such middleboxes.= Middlebox support is beyond the scope of this document.

SGTM.


<= span class=3D"">> S 5.5.
> Can you use VXLAN with IPsec?

"VXLAN" is really Ethernet over VXLAN over UDP. I don't = see a problem with doing Ethernet over VXLAN over UDP over IPsec.

Perhaps worth mentioning.


> S 5.6.
> What securit= y mechanism do you expect to use for TCP? IPsec again?

Yes.

Also perhaps w= orth mentioning.
=C2=A0
> =C2=A0 =C2=A0the timi= ng and implementation details may be such that P! and P2 each
>
&g= t; Nit: P1, right?

Yes, sorry about that pesky sh= ift key...

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= =C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street, Milford, MA 01757 U= SA
=C2=A0d3e3e= 3@gmail.com


--001a114797c6bc9e060567b00888--