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

Donald Eastlake <d3e3e3@gmail.com> Mon, 13 June 2016 03:36 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ADF12B03A; Sun, 12 Jun 2016 20:36:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8mXfPjKca9J; Sun, 12 Jun 2016 20:36:47 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5308812B034; Sun, 12 Jun 2016 20:36:47 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id w5so110788820oib.2; Sun, 12 Jun 2016 20:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mvztX6GyjdyJmUvr4crlNm6thofzJoWveiZWF77c8RQ=; b=BLFQzXsTEbeHpjJNlSX7F6C7ne3RHBDcI3TnZ0urvXFzpmSxtM4KJktUT7UBwk/aa8 4RrGf8334ETrUJDReolpjLbJvWPAdEsUOcJZ3Xr21ol2Em02XeFVoyo7YtH3qW+DU4hd hspnFW+u92WaOveDP+fYbsRRduLkcv4O09ildz64f0jm7sMnrvpO0Z5XfxKL4/yC7Kku mO1ZyNQN/3ixLAdl+qo6BmcvCKiqaLYSUQiXWwi3pDponP8cpFMIIiHUjdqtNO2ZQ6BR vNzAbQcgR0U2Yhr3hWPDzRjugoyBYEPwmsxDwyS4ya0woCcMr9XBwNQvEtgcksRAi0fQ 6y1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mvztX6GyjdyJmUvr4crlNm6thofzJoWveiZWF77c8RQ=; b=ei9b4dkZlOSPkx6gNdYsvLt32+se8j6U5edk72USGgOSmbIl6TZONyEE9LKDO72dBu vOaO7Q4gXjgwumfK0ibs6F5tJmJY3nVcVAlBq+qtMFe1G6cpcc9zVdl/Ry7/1bYzZG/6 wl5EhmUHG1RSBCKPKaZfnR9TTRoyNsPlhodFapED7DiS5EYMm3hh1M7EJJxpnTAiNMoJ ADzzyCW2/JyQ1Y/kB0gEF/wwOaATjeR7fPsmRDtFCVQHns+S9GCWVodvFzkQGvCb1pBm oMmvXqpqPJS/42jKeR7FC3qtjG3wUJlPebUxQpqltcRvmY18LABr0OuF3jTEEoPS0HqF 0e4g==
X-Gm-Message-State: ALyK8tJk+GJsnQvC+qdnQKyHL4kvU8s094S/J4NuIowldEBx3OZgEMo+teDt8Dk8bvlyWQXGLHbYjqs8UdFnOA==
X-Received: by 10.202.65.133 with SMTP id o127mr6481651oia.43.1465789006660; Sun, 12 Jun 2016 20:36:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.66 with HTTP; Sun, 12 Jun 2016 20:36:32 -0700 (PDT)
In-Reply-To: <CAF4+nEHmA7m78PU5sQ+D+7agjYK==S6+QSkJaasJhwfpehJK-w@mail.gmail.com>
References: <55E36EFC.6000508@gmail.com> <CAF4+nEEnVWhnmyVrXpFdjKCmrVT+jOLFF519-SBrjq9Do9NjSw@mail.gmail.com> <CAF4+nEHmA7m78PU5sQ+D+7agjYK==S6+QSkJaasJhwfpehJK-w@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 12 Jun 2016 23:36:32 -0400
Message-ID: <CAF4+nEE-cTYv+-a=UhDRVqfEOfmJ_ZzH1uXZgdCf_1UF1v_zrQ@mail.gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a113dc8620ecb8605352099b8
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/SnA-OYR2ifIpLMkcU1bLnhGP3So>
Cc: draft-ietf-trill-channel-tunnel.all@tools.ietf.org, "trill@ietf.org" <trill@ietf.org>, IETF Security Directorate <secdir@ietf.org>
Subject: Re: [secdir] Early SecDir review of draft-ietf-trill-channel-tunnel-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jun 2016 03:36:51 -0000

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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Fri, Apr 22, 2016 at 2:01 PM, Donald Eastlake <d3e3e3@gmail.com>; 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 <yaronf.ietf@gmail.com>;
> 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
>  d3e3e3@gmail.com
>