[secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms

Daniel Franke <dfoxfranke@gmail.com> Tue, 17 January 2017 17:52 UTC

Return-Path: <dfoxfranke@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6B5591293D8; Tue, 17 Jan 2017 09:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UzjQaMMgQavH; Tue, 17 Jan 2017 09:52:26 -0800 (PST)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 F256A127077; Tue, 17 Jan 2017 09:52:25 -0800 (PST)
Received: by mail-qt0-x229.google.com with SMTP id v23so169970053qtb.0; Tue, 17 Jan 2017 09:52:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aOiNmPXYBV49qD0p79dlOTzyLlsUYDk2xUxrbNGc5WE=; b=W1SeOfit1tXWHTzZh4H1LJ+qo2exRb4tbuBC/+AbXwaFQonJkcIJfys5AAQ2qHnvNA w2FHIiJMrDFBx3du5J0SyMA0SxC4or5FD7SlQF7AOB/sDalyrEqX74NWyJ+NUXd8dd7k jmeClNarzc0tuG1EFHDGGjOpPnrnEbhOeu3qvVwawKgmtC1YW9jflEiMcSOpv+ypLD+T xJ3Z8tfqQqSpw5ReW5Rqs1l35JQw5b55hiTRbq5jLbKmt9G/p1+1zJQD5NVvrvuF8FE1 DBL4qLyh6mup3BFlDAoKQxMrD4knelMhuttPIEVLsfA8oyGC09ffH4S0qlpY+H4F9/dl 51SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aOiNmPXYBV49qD0p79dlOTzyLlsUYDk2xUxrbNGc5WE=; b=GwIp+hWtzBWEzON9Ly3eQ1rK4pFLoiDvG131KiHm7nxJL6iluWIEk8+jmBg7osJAXM ws2wQ4e02A+nvRVxOvMKGqSkZXB41JiNAlqKf695WhLDLDrao0csWoIp2Avp0Pr/mTqs 22uhKdelFxBjxXXectIqA8w8lmfWKmO4DxJ6Piz5DCySkCEDe6ngkntZ3iViixgu5hvP 7ABiZCcAUyMEOmD/+v04XNbiZqMRzR6nwUHJaE4yTPgBFVP8hqmLNGJALJt0risNy9/v CX3L5MeC3aA0fnMJ9arpot0rUAyozGIzhQpiR1qP9I27t+aHMxaXgrzYqHMT0FjX2O5Z DeIw==
X-Gm-Message-State: AIkVDXK1foh3nkbb91qZBVCmBajDk+BLzBaoOOaewvjQOD30i71BRRGXX7Nza5vJjPkMDlqY6umyVEj1pvgmgA==
X-Received: by with SMTP id c31mr37548355qte.55.1484675545096; Tue, 17 Jan 2017 09:52:25 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 17 Jan 2017 09:52:24 -0800 (PST)
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Tue, 17 Jan 2017 12:52:24 -0500
Message-ID: <CAJm83bCdcDHomk3EJKEnbmdW6U22GGN5cyHPrdJC1H967v5OGw@mail.gmail.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-trill-directory-assist-mechanisms-all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jY9zGWR-wHMetdUjQkwR5bYapgw>
Subject: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms
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: Tue, 17 Jan 2017 17:52:27 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I believe this document is READY WITH NITS. I'm satisfied with its
normative content but the Security Considerations section could use
a bit of elaboration.

I had never heard of TRILL prior to being assigned this review and
the tree of normative references is a bit daunting, so these comments
will necessarily be based only on an extremely high-level view of
the system.

draft-ietf-trill-directory-assist-mechanisms proposes to augment
TRILL by adding directory servers which cache information about network
topology, allowing RBridges to sometimes shortcut the usual learning
algorithm that they would use to discover this information.

Here are the fundamental points which the Security Considerations
section either addresses or ought to address:

1. There are three relevant security goals:

   a. Availability: packets should reach their intended destination

   b. Confidentiality: packets should not reach unintended destinations

   c. Privacy: metadata concerning network presence should not be
      shared more widely than necessary

2. Access control to directory servers can be enforced using
   pre-existing cryptographic mechanisms specified in RFCs 5304, 5310,
   and 7978.

3. Principals authorized (duly or otherwise) to read directory data
   can violate privacy.

4. Principals authorized to modify directory data can violate
   availability and confidentiality.

5. Directory servers must therefore take care to implement and enforce
   access control policies which are not overly permissive.

The current text of the Security Considerations section directly
addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of
the draft obliquely implies points 1c and 3 but I wish they'd be
stated more explicitly. But the major omission is point 5: what does
a correct authorization predicate look like? What sort of access must
necessarily be authorized in order for protocol execution to succeed?
What sort of access generally ought *not* be authorized?