Re: [secdir] Security directorate

Alia Atlas <akatlas@gmail.com> Tue, 06 January 2015 22:18 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71CED1A8716 for <secdir@ietfa.amsl.com>; Tue, 6 Jan 2015 14:18:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 qo3D0s4CmNyD for <secdir@ietfa.amsl.com>; Tue, 6 Jan 2015 14:18:47 -0800 (PST)
Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA2B1A0103 for <secdir@ietf.org>; Tue, 6 Jan 2015 14:18:47 -0800 (PST)
Received: by mail-yh0-f54.google.com with SMTP id c41so80604yho.27 for <secdir@ietf.org>; Tue, 06 Jan 2015 14:18:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DjAID+/XVg7dZnOA6dfY/pqpiOMrKcXEo/xAiprkFmI=; b=ou+j+gVJ3Ryq2EQmUwlGJWXxSB96FQGYn0x6NF/fetny1oh5vYVEMrZbuSyp43EoGD oCLyqGXmZOS4XwDFWilj+KnsYjAV+UfIMTg71GRd7ijjO6Kcs0dLVAHkx1mnEJ0R9uqG vNqn3B8QbNAuJXUYp8hSJzhJsF/hDEuXRpKBjvd9lcaTyO3mX/DnpfUbj+l/GqOXc7Az jvK6lC20kpVbT/qeImLcj6XIw7xpJ3s/Zkih2kIouM5DgJIUJMFbXOrwx9UnSS/STAO4 yppRpcoOJ7qk2zCWG3WRT6YnXMlZ0wKI0zKz/jr6fykqebo9uEJTWBV9fUU8ZTDyfbuB sjuA==
MIME-Version: 1.0
X-Received: by 10.236.15.103 with SMTP id e67mr31289243yhe.3.1420582726269; Tue, 06 Jan 2015 14:18:46 -0800 (PST)
Received: by 10.170.133.18 with HTTP; Tue, 6 Jan 2015 14:18:46 -0800 (PST)
In-Reply-To: <5492F9F7.1070909@bbn.com>
References: <074b01d00f31$1712da30$45388e90$@ndzh.com> <CAHbuEH7ko_Hz-YHNF=U52a9d8PsX6kYM1udKDK0pWKqhk7VE1Q@mail.gmail.com> <21650.47330.158595.209025@fireball.kivinen.iki.fi> <00e601d01ac4$b5b69b60$2123d220$@ndzh.com> <5492F9F7.1070909@bbn.com>
Date: Tue, 6 Jan 2015 17:18:46 -0500
Message-ID: <CAG4d1rd2b_8cJm-dVd2YrhiShL2FRJgs0edVQe=5V+L0byu9ag@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary=089e0122a476c61e05050c033016
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/2rRHX_UZkF2CsxoyBLnGqR_leG8
X-Mailman-Approved-At: Tue, 06 Jan 2015 14:21:58 -0800
Cc: "Thomas D. Nadeau" <tnadeau@lucidvision.com>, secdir <secdir@ietf.org>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "wardd@cisco.com" <wardd@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>, Adrian Farrel <adrian@olddog.co.uk>, Susan Hares <shares@ndzh.com>
Subject: Re: [secdir] Security directorate
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 06 Jan 2015 22:18:50 -0000

Hi Stephen,

Thanks very much for doing this review.

On Thu, Dec 18, 2014 at 10:59 AM, Stephen Kent <kent@bbn.com> wrote:

>  SECDIR early review of draft-ietf-i2rs-problem-statement-04
>
>
>
>
>
> 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 with the intent of improving security requirements
> and considerations in IETF drafts.  Comments not addressed in last call
> may be included in AD reviews during the IESG review.  Document editors
> and WG chairs should treat these comments just like any other last call
> comments.
>
>
>
> This is a short document describing the problem being addressed by the
> I2RS WG, and establishing some requirements for solutions.
>
>
>
> Section 2 describes the model for I2RS. It calls for using existing
> transport protocols to provide security, a good statement as part of the
> base protocol requirements. Looking at Figure 1, it seems that the only
> paths that are in scope for I2RS are between an I2RS agent and client and
> between clients.
>
> In section 5, authentication, authorization, and integrity are explicitly
> cited as requirements. This is a good statement of requirements. It might
> be nice to state whether confidentiality is also perceived as a
> requirement, or if it explicitly not a requirement.
>

The sad answer is that it depends on what data is being sent.  For
instance, I can see counters or events not requiring confidentiality
(depending) but some things being written or responses might require
confidentiality.
I've added in
" Some communications will also require confidentiality."
at the end of the Secure Control bullet.


 The Security Considerations section is a single paragraph consisting of 2
> sentences. It opens with a nice statement about the importance of security
> in the I2RS context. I think a back pointer to the “secure Control” text
> would be appropriate. The second sentence says that more investigation is
> needed to fully define security requirements such as authorization and
> authentication levels. I don’t know what this last phrase means.
> Authorization (aka access control) isn’t usually described as having levels
> per se. Do you mean granularity of access control, or something else. Also,
> for authentication, there are various mechanisms one can employ, and these
> may be described as offering varying “levels” of security, but that is an
> oversimplification in many cases. A clearer description of what the authors
> are trying to convey here would be good.
>

I've updated the Security Considerations section to:

"Security is a key aspect of any protocol that allows state
      installation and extracting of detailed router state.  The need
      for secure control is mentioned in Section 5.  More architectural
security
      considerations are discussed in <xref
      target="I-D.ietf-i2rs-architecture"/>.  Briefly, the I2RS Agent
      is assumed to have a separate authentication and authorization
      channel by which it can validate both the identity and the
      permissions associated with an I2RS Client.  Mutual
      authentication between the I2RS Agent and I2RS Client is
      required.  Different levels of integrity, confidentiality, and
      replay protection are relevant for different aspects of
      I2RS."


I also looked briefly at draft-hares-i2rs-security-02. That document begins
> with a very good discussion of security terminology based on RFC 4949. It
> also proposes very specific security requirements for communications in the
> I2RS model. That document calls for confidentiality as a requirement, which
> further motivates some mention of this security service in the problem
> statement, even if the statement is equivocal.
>
>
>
>
> Two typos I noted:
>
>
>
> Section 2: measuresments -> measurements
>
>
>
> Section 5:
>
>
>
> Such communications must also have its integrity protected. ->
>
>
>
> Such communications must also be integrity-protected.
>

fixed


Thanks again,
Alia