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

From: Donald Eastlake <[email-masked]>
Date: Fri, 22 Apr 2016 14:01:40 -0400

Hi Yaron,

As we discussed in Buenos Aires, here is a revised response to your
SECDIR review of draft-ietf-trill-channel-tunnel based on the -08
reversion of that draft. This version of the draft has the group
keying material removed as per
http://www.ietf.org/mail-archive/web/trill/current/msg07215.html

On Sun, Aug 30, 2015 at 5:00 PM, Yaron Sheffer <[email-masked]>
wrote:
>
>...
>
> 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.

See below.

> 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.

Version -08 of the draft has been significant modified as below. I
believe the use of DTLS is better specified and group keying is
no longer in the draft, being deferred to subsequent documents. The
draft specifies the use of serial unicast for multicast / broadcast /
unknown unicast.

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

In this revised draft, although an authentication only option is
provided, which leverages IS-IS key management, when DTLS is used its
key management facilities are available.

> • 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.

At this point, the Channel Tunnel protocol is being used to tunnel
DTLS so I don't think there is that much risk.

> • 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.
> • 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.

These bits have been eliminated.

> • 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?

Figures showing coverage have been added to Section 4.2.

The only time there is an FCS is if the link between two RBridge ports
is Ethernet. If, for example, the link is PPP or pseudowire, there is
no FCS; In particular, the inner Ethernet-like payload of a TRILL Data
packet does not have an FCS. So providing integrity protection of an
FCS does not make sense. An RBridge Channel packet looks like a TRILL
Data packet and can go multiple RBridge hops some of which are
Ethernet and have an FCS and some of which are not Ethernet and do not
have an FCS. Even if all were Ethernet, the FCS can change due to
changes in presences/absence of an outer VLAN tag or other tags or the
like.

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

While this is always done for SType 1, it might or might not be used
for SType 2 or future STypes. (The SType numbering has changed a bit
and there is no STyp3 in the revised draft.)

> • 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.

Version -08 of the draft says, "It is assumed that the IS-IS keying
material is of high quality."

> • 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 now says that when security information is
present it consists of four reserved bits followed by 12 bits of size
information followed by zero to 2**12-1 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?

The current draft provides that if DTLS is in use, then PSK MUST be
supported and certificates MAY be supported. Perhaps that MAY should
be turned back into a SHOULD.

> • 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)?

The draft no longer specifies cipher suites and is intended to just
defer to whatever the DTLS implementation requirements are.

I am not sure how much the following comments apply to the current draft...
> • 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.
DTLS is not used to wrap L2 frames but rather to wrap Channel Tunnel
payloads. The type of the payload is give by the PType. True, there is
a PType that says the payload is an Ethernet frame. Figure 3.4 show
what it would look like without security or with just authentication.
Possibly a figure should be added for the DTLS security case.

> • 4.7: if this mode is assumed for multicast, what is the
> assumed/recommended mode for unicast?
> • 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?

Group security for multi-destination Channel Tunnel messages is being
deferred to another document. The revised draft only covers use of
serial unicast with pairwise security.

> • 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.
> • Actually, I'm not sure where this size is indicated.

Its size would be indicated in the Channel Tunnel Header (which
includes the Security Information field) that is shown as
authenticated in Figure 4.2.

> • 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.
> • Typo: designed -> designated.
> • 5: assuming we will have DTLS handshakes nested within CT, how are
> errors indicated?

If DTLS is not supported at the destination, then you get a Channel
Tunnel (actually RBridge Channel) error saying SType not supported.

If DTLS is supported at the destination, you get a DTLS error Alert
back as a Channel Tunnel message.

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

When DTLS is used, the DTLS replay protection is available. There is
no replay protection if no security is used or if RFC 5310
authentication is used.

> • 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 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 and, as it states in
the draft "only process payload types required and then only with
adequate authentication for the particular circumstances".

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