Re: [trill] Eric Rescorla's Discuss on draft-ietf-trill-over-ip-15: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Sun, Mar 18, 2018 at 12:21 PM, Donald Eastlake <[e-mail]> wrote:

> Hi Eric,
>
> On Sun, Mar 18, 2018 at 4:56 AM, Eric Rescorla <[e-mail]> 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   [phone] <(508)%20333-2270> (cell)
>  155 Beaver Street, Milford, MA 01757 USA
> <https://maps.google.com/?q=155+Beaver+Street,+Milford,+MA+01757+USA&entry=gmail&source=g>
>  [e-mail]
>
>