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

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Mar 2017 17:48:53 -0500

Hi Daniel,

Thanks for your comments. See below.

On Tue, Jan 17, 2017 at 12:52 PM, Daniel Franke <[email-masked]> wrote:
> 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.

OK.

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

Well, actually access to directory server messages.

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

OK.

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

OK.

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

The -12 version just posted is intended to resolve these comments.

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 2 Mar 2017 17:57:01 -0500

Resending with [email-masked]
replaced with [email-masked].