Subject: [trill] TRILL IPsec encapsulation

From: Yaron Sheffer <[email-masked]>
Date: Wed, 22 Jul 2015 19:48:34 +0200

I have read the TRILL-over-IP draft
(draft-ietf-trill-over-ip-03) as a kind of early SecDir review,
focusing on its use of IPsec. Thanks to Donald Eastlake who
graciously provided me with a crash course on TRILL. He's not
responsible for any stupidity on my part, of course.

So here are some comments:

- The draft currently uses IPsec but not IKE or any kind of
key management. The end result is that data is being encrypted by
very long-lived keys, not enjoying the benefit of forward secrecy
etc. Please use IKEv2 and do NOT use IPsec directly. RFC
4107 explains why.

- There is in fact IPsec-with-multicast, but it's not
widely deployed and is based on the obsolete IKEv1. Instead, I
suggest to use unicast encapsulation with IKEv2. I suppose this
means that you'd want to only encapsulate data but not IS-IS
frames.

- The draft currently derives encryption keys from IS-IS
keys. This is problematic at several levels:

* The IS-IS key is common to a large group of devices
(a.k.a. "a group key") and so is likely to be compromised.

* The key is used directly for encryption, as noted.

* The key is derived using HMAC, which is specified
incorrectly in the draft (one parameter instead of two).

* The derived key is identical for all
routers/links.

- I would suggest to use a derived key for authentication
only, and to derive it differently for each link - although I
realize that this does not raise the security level significantly.
Something like: link-psk = HMAC(IS-IS-key, 6-byte-system-id-1 |
6-byte-system-id-2).

- Note that IKE generates a different encryption key for
each link even if everybody is using the same authentication key
(pre-shared secret). But it's still a bad practice for all
principals to have the same key...

- Longer term it would improve security hugely if each
router had an authenticated identity of its own. In other words,
its own certificate and private key.

- Please don't define your own MTI algorithms. Just use RFC
7321.

Thanks,

Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jul 2015 08:15:12 +0100

Thanks Yaron, that's useful.

S

On 22/07/15 18:48, Yaron Sheffer wrote:
> I have read the TRILL-over-IP draft (draft-ietf-trill-over-ip-03) as a kind of 
> early SecDir review, focusing on its use of IPsec. Thanks to Donald Eastlake who 
> graciously provided me with a crash course on TRILL. He's not responsible for 
> any stupidity on my part, of course.
> 
> - The draft currently uses IPsec but not IKE or any kind of key management. The 
> end result is that data is being encrypted by very long-lived keys, not enjoying 
> the benefit of forward secrecy etc. Please use IKEv2 and do NOT use IPsec 
> directly.RFC 4107 explains why.
> - There is in fact IPsec-with-multicast, but it's not widely deployed and is 
> based on the obsolete IKEv1. Instead, I suggest to use unicast encapsulation 
> with IKEv2. I suppose this means that you'd want to only encapsulate data but 
> not IS-IS frames.
> - The draft currently derives encryption keys from IS-IS keys. This is 
> problematic at several levels:
>    * The IS-IS key is common to a large group of devices (a.k.a. "a group key") 
> and so is likely to be compromised.
>    * The key is derived using HMAC, which is specified incorrectly in the draft 
> (one parameter instead of two).
>    * The derived key is identical for all routers/links.
> - I would suggest to use a derived key for authentication only, and to derive it 
> differently for each link - although I realize that this does not raise the 
> security level significantly. Something like: link-psk = HMAC(IS-IS-key, 
> 6-byte-system-id-1 | 6-byte-system-id-2).
> - Note that IKE generates a different encryption key for each link even if 
> everybody is using the same authentication key (pre-shared secret). But it's 
> still a bad practice for all principals to have the same key...
> - Longer term it would improve security hugely if each router had an 
> authenticated identity of its own. In other words, its own certificate and 
> private key.
> - Please don't define your own MTI algorithms. Just use RFC 7321.
> 
> Thanks,
>      Yaron
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 23 Jul 2015 06:49:20 -0400

Hi Yaron,

Thanks for these comments. Below are a few immediate thoughts of mine.

On Wed, Jul 22, 2015 at 1:48 PM, Yaron Sheffer <[email-masked]> wrote:
> I have read the TRILL-over-IP draft (draft-ietf-trill-over-ip-03) as a kind
> of early SecDir review, focusing on its use of IPsec. Thanks to Donald
> Eastlake who graciously provided me with a crash course on TRILL. He's not

You're welcome. Sorry I was still a bit fuzzy from 12 time zone jet
lag when we got together.

> - The draft currently uses IPsec but not IKE or any kind of key management.
> The end result is that data is being encrypted by very long-lived keys, not
> enjoying the benefit of forward secrecy etc. Please use IKEv2 and do NOT use
> IPsec directly. RFC 4107 explains why.
> with IKEv2. I suppose this means that you'd want to only encapsulate data
> but not IS-IS frames.

I've been thinking about this. TRILL supports broadcast links and
handles multicast data also.

There are several different cases but, on a broadcast
(non-point-to-point) TRILL link, there is an elected designated TRILL
router (called the DRB or Designated RBridge) that, in some sense, is
in charge of the link. Perhaps the DRB could generate a group key and
send it to the other TRILL routers/RBridges on the link using pairwise
security between the DRB and the other RBridges.Of course, if the link
is actually configured as point-to-point, then you know there will
only be two RBridges on it and only need straightforward pairwise
security.

> problematic at several levels:

TRILL tries hard to default to be minimum configuration so it defaults
to bootstrapping from IS-IS keys. This is not meant to prohibit other
techniques if the network manager wants to use them.

>   * The IS-IS key is common to a large group of devices (a.k.a. "a group
> key") and so is likely to be compromised.

IS-IS has both area wide keying, for authentication of link state PDUs
that are flooded area wide, and link scoped keying for link local
IS-IS PDUs such as Hellos. Link scoped IS-IS keying should be what
TRILL bootstraps from by default.

>   * The key is derived using HMAC, which is specified incorrectly in the
> draft (one parameter instead of two).

Sorry, the concatenation sign should have been a comma.

> - I would suggest to use a derived key for authentication only, and to
> derive it differently for each link - although I realize that this does not
> raise the security level significantly. Something like: link-psk =
> HMAC(IS-IS-key, 6-byte-system-id-1 | 6-byte-system-id-2).

Right. Since our discussion, it has occurred to me that that is not
quite adequate because you can have multiple point-to-point links
between the same pair of RBridges for which you would get the same
pair of 6-byte IS-IS System IDs. Actually, pairwise security will be
between two RBridge ports and an RBridge post is uniquely identified
by the System ID of the RBridge and the locally unique Port ID of the
port. So we could go for something like

HMAC ( IS-IS key, System ID1 | Port ID1 | System ID2 | Port ID2 )

(Of course, you also need a rules so both ends get the IDs in the same
order, such as using numeric order treating the System IDs as unsigned
integers.)

> - Please don't define your own MTI algorithms. Just use RFC 7321.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Thanks,
>     Yaron
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 31 Jul 2015 17:49:52 +0300

Hi Donald,

Sorry for the late reply.

Please see some comments/responses below.

Thanks,
	Yaron

> only be two RBridges on it and only need straightforward pairwise

You are proposing to add key management functionality into TRILL, 
specifically for multicast/broadcast cases. It doesn't sound like a good 
idea to me.

If this usage is core to TRILL, you should look at RFC 6407 and the 
other MSEC documents, and bear in mind that they are not widely 
implemented. Otherwise, you're better off sticking to plain IKEv2/IPsec.

> TRILL bootstraps from by default.

Yes, this is a lot better than a global group key.

> order, such as using numeric order treating the System IDs as unsigned

Sounds good.