Re: [secdir] Early SecDir Reviews

"Susan Hares" <shares@ndzh.com> Mon, 24 August 2015 20:45 UTC

Return-Path: <shares@ndzh.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 B7C8B1B2B12; Mon, 24 Aug 2015 13:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.055
X-Spam-Level:
X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no
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 bSiBNIiz9VXC; Mon, 24 Aug 2015 13:45:49 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9864C1B2B10; Mon, 24 Aug 2015 13:45:49 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.218.207;
From: "Susan Hares" <shares@ndzh.com>
To: "'Joel Halpern'" <joel.halpern@ericsson.com>, "'Russ Housley'" <housley@vigilsec.com>
References: <32779ADA-75D3-4754-AFD2-DFFE7237D939@vigilsec.com> <00c201d0de98$25ac79c0$71056d40$@ndzh.com> <8FBE7974-F6D5-4A05-A078-E705A61D976B@vigilsec.com> <6BCE198E4EAEFC4CAB45D75826EFB07614F4FD89@eusaamb101.ericsson.se>
In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB07614F4FD89@eusaamb101.ericsson.se>
Date: Mon, 24 Aug 2015 16:45:45 -0400
Message-ID: <010201d0dead$da590540$8f0b0fc0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHjR5i/kudQwZm7gHsLIiXDOIy/DAKmR64YAY+Z2NEB9W2z4Z3FcXhQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/BcEvWhlGfq4gJIEHYqNyE8tQSNY>
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 20:45:50 -0000

Russ: 
 
Do think that identifier is a better use like Joel suggested? 

Sue 

-----Original Message-----
From: Joel Halpern [mailto:joel.halpern@ericsson.com] 
Sent: Monday, August 24, 2015 4:05 PM
To: Russ Housley; Susan Hares
Cc: draft-mglt-i2rs-security-requirements.all@ietf.org;
draft-hares-i2rs-auth-trans.all@ietf.org; 'Stephen Farrell'; 'Kathleen
Moriarty'; 'IETF SecDir'
Subject: RE: Early SecDir Reviews

Hannes is probably correct that we mean identifier, not identity, in almost
all cases in the document.

In particular, regarding primary and secondry identifier, the secondary
identifier is NOT used for any security decisions.  Access control is based
only on the primary identifier.

Yours,
Joel

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Monday, August 24, 2015 3:27 PM
To: Susan Hares
Cc: draft-mglt-i2rs-security-requirements.all@ietf.org;
draft-hares-i2rs-auth-trans.all@ietf.org; 'Stephen Farrell'; 'Kathleen
Moriarty'; 'IETF SecDir'
Subject: Re: Early SecDir Reviews

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