Re: [secdir] Early SecDir Reviews

Russ Housley <housley@vigilsec.com> Mon, 24 August 2015 19:28 UTC

Return-Path: <housley@vigilsec.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 B36D31A8866; Mon, 24 Aug 2015 12:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 yoUMJgRt0vpy; Mon, 24 Aug 2015 12:28:08 -0700 (PDT)
Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id A4A9B1A8858; Mon, 24 Aug 2015 12:28:08 -0700 (PDT)
Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 308D5F2416D; Mon, 24 Aug 2015 15:27:58 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id b6U7RzeKdB6Z; Mon, 24 Aug 2015 15:26:40 -0400 (EDT)
Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 53770F24166; Mon, 24 Aug 2015 15:27:37 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset="us-ascii"
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <00c201d0de98$25ac79c0$71056d40$@ndzh.com>
Date: Mon, 24 Aug 2015 15:27:26 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FBE7974-F6D5-4A05-A078-E705A61D976B@vigilsec.com>
References: <32779ADA-75D3-4754-AFD2-DFFE7237D939@vigilsec.com> <00c201d0de98$25ac79c0$71056d40$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/OIpIkiJMGvZER6BHJ4Yo5FmV5x4>
Cc: 'IETF SecDir' <secdir@ietf.org>, 'Kathleen Moriarty' <kathleen.moriarty.ietf@gmail.com>, draft-hares-i2rs-auth-trans.all@ietf.org, draft-mglt-i2rs-security-requirements.all@ietf.org
Subject: Re: [secdir] Early SecDir Reviews
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: <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, 24 Aug 2015 19:28:09 -0000

Sue:

> 1) Is REQ-8 a security requirement? 
> 
>   o  SEC-REQ-08: Each Identity is associated with one secondary
>      identity during a particular read/write sequence, but the
>      secondary identity may vary during the time a connection between
>      the I2RS client and I2RS agent is active.  The variance of the
>      secondary identity allows the I2rs client to be associated with
>      multiple applications and pass along an identifier for these
>      applications in the secondary identifier.

Yes, if that identity is going to be used to make the access control decision.

> 2) Is REQ-12 - a security requirement for a protocol?  NETCONF asked this of
> I2RS. 
> 
>   SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement
>   mechanisms that mitigate DoS attacks

Yes.  For example, the IKE cookie mechanism is only there to make it much more expensive the an attacker ti implement DDoS.  They can't fire and forget.  They need to keep state and hang around for at least 1.5 round trips.

> 3) Section 2.4.1 - is a description of the what happens when multiple
> changes occur via multiple messages.  
> 
> My understanding from your question is that the implementation of how an
> I2RS Agent processes the changes (change1, change2, change3) that occur in
> multiple messages is not a security issue, but a implementation issue.  If
> so, Please let me know. 

There might be some protocol issues to assist keep things atomic, but I agree it i not a security issue.

> 4) Are you Ok with REQ-09 specifying a non-secure transport as an option? 

The security considerations need to be clear what the consequences are if this option is selected.

Russ