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

[Donald Eastlake <[e-mail]>]

Hi Yaron,

draft-ietf-trill-channel-tunnel-09 has been posted. I believe the security
aspects are much improved and would appreciate it if you could take a look.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Fri, Apr 22, 2016 at 2:01 PM, Donald Eastlake <[e-mail]> wrote:

> 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 <[e-mail]>
> 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   [phone] (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [e-mail]
>