Subject: Re: [secdir] Early SecDir review of draft-ietf-trill-channel-tunnel-07

From: Donald Eastlake <[email-masked]>
Date: Tue, 8 Sep 2015 14:57:14 -0400

Hi Yaron,

Thanks for the review.

On Sun, Aug 30, 2015 at 5:00 PM, Yaron Sheffer <[email-masked]>
wrote:
> This is an early security review, written at the request of the
> TRILL WG.
>
> The document defines a way to tunnel arbitrary frames of related
> control protocols within the TRILL "channel". Most of the document
> (and the focus of this review) is about security this tunnel.

Perhaps a bit of history would be useful:

TRILL primarily uses IS-IS for its control plane and, of course,
whatever native link-technology specific control features are
available internal to a link between TRILL switch (RBridge) ports can
be used locally, but these have some limitations. So the "RBridge
Channel" facility was specified in RFC 7178 to support the extensible
specification of unicast or multicast, single or multi-hop typed
control messages between TRILL switches and between a TRILL-aware end
station and the TRILL switch to which it is attached. (One would
expect most end stations to not be TRILL-aware.) The first use of the
RBridge Channel facility was to support BFD over TRILL, as specified
in RFC 7175.

There are three things that might seem like useful additions to the
RFC 7178 RBridge Channel facility:
(1) Although RFC 7178 handles control messages between TRILL switches or
between a TRILL-aware end station and an adjacent TRILL switch, you
also might want such messages between a TRILL-aware end station
and a non-adjacent TRILL switch or between two TRILL-aware end
stations not on the same link.
(2) Although RFC 7178 provides for an extensible type for control
messages, there may be cases where there is already an Ethertype
defined so it would be convenient to have an RBridge Channel message
type that says that its payload starts with an Ethertype or, in some
cases, a destination MAC address, a source MAC address, and an
Ethertype, where that Ethertype tells you what the further payload is.
(3) RFC 7178 does not provide for security, something that was noted
by the Security Area at the time it went through the IESG but was not
considered blocking, perhaps partly because the first application for
RBridge Channel was for to carry BFD that has its own security.

Early versions of this draft covered all three of these points and had
a bunch of somewhat complex material addressing point 1 and less
material than the current version addressing point 3. However, there
did not seem to be an immediate requirement to address point 1 so, to
slim down the draft, that was removed while the amount of material
addressing point 3 has grown.

> Summary
>
> I believe the draft is not ready for IETF LC in its current form. I
> assume the original intention was to use DTLS, but the use of DTLS
> is not well specified and the alternative that's proposed for
> multicast comes with inferior security.

After studying your review and thinking about it, I agree that the
draft is not ready.

DTLS is actually a very recent addition to the draft.

In early versions, the security provided in the Channel Tunnel draft
was very much like IS-IS authentication. The option of using DTLS was
added quite recently to provide an option with better key negotiation
/ management.  Although I'm not sure, in this context where the TRILL
switches are pretty much trusted entities, that this is much needed.

If, for example, a link between TRILL switch ports traverses an
insecure environment, then it seems to me that the best answer is link
encryption based on the link technology (which is what the TRILL over
IP draft is intended to specify for IP links and what the
draft-eastlake-trill-link-security early partial draft is intended to
specify for other link technologies used between TRILL switch ports).
Link security would protect both the TRILL IS-IS control traffic as
well as TRILL Data packets (which includes RBridge Channel packets
since they are encoded as if they were TRILL Data packets) and
sometimes also protects some link-local link technology specific
control packets. Channel Tunnel security protects only Channel Tunnel
messages although, if they are multi-hop, it can protect them to some
extent against intervening TRILL switches.

> Details
>
> • In general, I don't understand why it makes sense to define a whole new
> security protocol, just for control-plane traffic of one specific protocol,
> important as it may be. At the very least I would expect an analysis of
> potential alternatives (IPsec? MACsec?) and why they do not fit this use
> case.

It seems important to at least be able to provide the same level of
authentication as the primary IS-IS control plane. And IPsec, DTLS,
and MACsec seems like the big three bell and whistle equipped datagram
security schemes, one of which should be optionally available. There
is a significant gap between these two levels of security.

See the end of this response for my further thoughts on this high
level question...

(Note that currently the TRILL protocol does not require a TRILL switch
to have an IP address or a MAC address associated with it although
there would be various ways to overcome this if desired.)

> • As a result of the home-brew transport protocol, we also don't get
> a standard key management protocol.

I'm not completely sure what you are referring to but the "home-brew
transport protocol" of RBridge Channel [RFC 7178] is currently
implemented and deployed and in use for BFD and, I believe, further
control plane messages that have not yet been standardized.

> • And from a process POV, the TRILL WG may not be the best place, as
> far as participants' expertise, to develop a security protocol. An
> early SecDir review certainly helps, but I'm not sure the current
> reviewer is capable of detecting every last issue that might be
> lurking in the protocol.

Well, there are things for which I would say TRILL WG is clearly
inappropriate, like designing cryptographic primitives, and things
where I think the TRILL WG is appropriate, such as determining, when
security is provided, what parts of an RBridge Channel packet of other
TRILL PDU should be authenticated and/or encrypted and what parts
need to be unauthentication or in plain text because they are mutable
or needed by transit devices.

> • 4.1: the A and E bits are not guaranteed to be correct? Then why
> are they here? They describe critical security properties, and
> therefore someone is bound to use them to make critical policy
> decisions. If the bits' semantics are not guaranteed, we'd better
> drop them.

The E bit was intended to be useful as a hint to diagnostics/debugging
software that a payload is encrypted so trying to parse it without
keys is not going to get you very far. But I think the bits could be
removed.

> • A bit: I think we are confusing authentication with integrity
> protection.  With opportunistic security, you usually don't have
> authentication, but integrity protection is still worthwhile.

Although opportunistic security is mentioned I don't think there is
any specification of how to do it in this draft. Do you believe that
the Authentication TLV in IS-IS should be renamed the Integrity TLV?

> • 4.2: Coverage - it would be nice if Fig. 2.1 showed the coverage
> of authentication (integrity protection!) and encryption. Why is an
> Ethernet frame's FCS not covered by integrity protection? Is there
> any non-malicious reason someone would want to modify the FCS in
> transit?

Some graphic representation of the coverages, rather than just text,
seems like a good idea. I'm not completely certain that Figure 2.1 is
the best place -- perhaps there should be a new figure.

On coverage of Ethernet FCS: the only case where you can be sure there
is an invariant Ethernet FCS between TRILL switch ports would be a
single hop RBridge Channel message over Ethernet (TRILL over Ethernet
is specified in RFC 6325) between adjacent TRILL switch ports where
there are no intervening bridges.  Bridged LANs are pretty much
transparent to TRILL and, if there are any intervening bridges between
TRILL switch ports, those bridges can change the FCS due to
inserting/removing various tags etc.

RBridge Channel messages can be multihop (multiple TRILL hops) and
even if all the hops were point-to-point Ethernet, the Ethernet FCS
could change at every TRILL switch along the path due to the
presence/absence of tags. The optional outer VLAN tag in TRILL over
Ethernet has no relationship to the actual Data Label of the payload
but just gives some VLAN ID that is convenient to use to get the TRILL
data packet from one TRILL switch to the next TRILL switch in the
path.

> • 4.3: "in some cases" - why not simply say, "When SType is 1 or 3"?

Because there might be additional STypes specified that can also use
this. But I guess it doesn't matter much since such specification
could amend the provisions here.

> • 4.3: why deconstruct HKDF and use HKDF-Expand instead of simply
> using the whole thing, including HKDF-Extract?

Because the draft follows the advice in RFC 5869 that specifies HKDF:

                   In some applications, the input may already be a
   good pseudorandom key; in these cases, the "extract" stage is not
   necessary, and the "expand" part can be used alone.

The Channel Tunnel draft assumes that an IS-IS key will be a good key.
Explicitly noting that assumption would be a good idea.

> • I am confused about 4.1 vs. 4.5, and specifically, what does the
> Size byte cover. I think this is incorrect in 4.5.

Maybe I am missing something but they look compatible with me. Section
4.1 is more general, and says that when security information is
present it consists of a byte of flags followed by a byte of size
information followed by zero to 255 bytes of "More Info". Section 4.5
is more specific and says that for a particular SType, this "More
Info" consists of the two byte RFC 5310 Key ID followed by a variable
amount of "Authentication Data".

> • 4.6: this section starts with certificates (presumably, both
> client and server should authenticate with a cert) and then moves on
> to PSK. Are both allowed?

If DTLS is supported, then
  PSK MUST be supported and certificates SHOULD be supported.

The wording could be improved to make this clearer if this sort of
material stays in this draft.

> • 4.6: TLS is rapidly moving toward perfect-forward secrecy. Why
> require a cipher suite that's being deprecated across all of
> industry (TLS_RSA_WITH_AES_128_CBC_SHA256)?

A mandatory to implement algorithm seemed useful for interoperability
if this sort of material remains in this draft but it could be
indirectly specified by a reference to another document.

> • 4.6.: I am still unclear on how CT keys are derived from DTLS.
> • 4.6: Why have a TRILL-level key ID with DTLS-PSK has the notion of
> key ID?
> • 4.6: with certificates the frames may be very large. Does the protocol
> support such sizes?
> • 4.6: there should be a lot more text about how DTLS is used to wrap L2
> frames.

I tend to agree that there are problems here. Rather than responding
on each point above see the end of this note where I propose removing
the DTLS material entirely.

> • 4.7: if this mode is assumed for multicast, what is the
> assumed/recommended mode for unicast?

It depends on what services you want.

> • Obviously integrity protection where the MAC key is shared with all peers
> is very weak. There are various ways to deal with that, starting with RSA
> signatures but including more efficient methods (TESLA comes to mind). Have
> you considered any of them?
> • 4.7.1: if the authentication data is variable length, you must ensure that
> the field that indicates its size is integrity-protected as well.

OK.

> • Actually, I'm not sure where this size is indicated.
> • It seems to me that a fully random 128-bit nonce would be both
> simpler to implement and more secure than the scheme proposed here.

Possibly but the generation of good random number can also be
considered a burden.

> • Typo: designed -> designated.

Thanks.

> • 5: assuming we will have DTLS handshakes nested within CT, how are
> errors indicated?

See note at end of this message.

> • General: is there any facility for replay protection? If no, why
> not?

Not in general. There should be.

> • 7: The more normative parts of the Security Considerations would
> probably fit nicely into a separate Applicability section.

> • 7: I think the document should be much more clear (normative)
> about what message types are allowed within the tunnel, or not. And
> possibly about required filtering by address.

I disagree. The whole idea is to be a general, extensible messaging
facility.  I don't think it is possible to anticipate in advance what
people might want to use it for and the precise tests they should
make. I'm not sure how much more can generally and validly be said
other than to be conservative in what you accept.

Overall Note
------------

Based on this review and further consideration, I think the attempt in
this draft to convolve DTLS with the Channel Tunnel feature, while not
inherently impossible, is pretty much a failure and not the best
approach.

When stronger security, encryption, key negotiation, and the like are
desired, a general payload-independent feature running between
RBridges that envelopes TRILL Data packets should be used.  This could
be used to protect RBridge Channel messages since they are encoded a
TRILL Data packets and could be specified in a separate document to
which this draft could refer.

The security in this draft should be simplified to providing
authentication and replay protection.

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