[saag] FW: Urgent need for a person from the security directorate to review key pionts in I2RS security

"Susan Hares" <shares@ndzh.com> Fri, 14 August 2015 16:47 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32F91A88E4 for <saag@ietfa.amsl.com>; Fri, 14 Aug 2015 09:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.054
X-Spam-Level:
X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, 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 bf40Jp1G93-v for <saag@ietfa.amsl.com>; Fri, 14 Aug 2015 09:47:34 -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 289931A88DE for <saag@ietf.org>; Fri, 14 Aug 2015 09:47:34 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.199.108;
From: Susan Hares <shares@ndzh.com>
To: saag@ietf.org
References:
In-Reply-To:
Date: Fri, 14 Aug 2015 12:47:28 -0400
Message-ID: <010901d0d6b0$e82fcfa0$b88f6ee0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01D0D68F.6121B210"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQMJDnzX0R9xXAXNq+IUI0T2muLIlZubQX4g
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/OkmSaIglz_JOppRpkizUQSdSPqs>
X-Mailman-Approved-At: Mon, 17 Aug 2015 08:18:07 -0700
Cc: 'Jeffrey Haas' <jhaas@pfrc.org>, 'Alia Atlas' <akatlas@gmail.com>
Subject: [saag] FW: Urgent need for a person from the security directorate to review key pionts in I2RS security
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2015 16:47:38 -0000

Security directorate: 

 

I need help rather urgently.  The I2RS and the NETCONF WGs are collaborating
to create the I2RS protocol.  The design team will begin its work next week
(8/17) so I need someone who can help for the next 2 weeks.  We really need
a security person to help us for the next few weeks to determine what are
necessary security requirements for this protocol.   I am willing to provide
tutorial and information for the security person. 

 

NETCONF reviewers have suggested that some of the I2RS security requirements
are unclear or "not security" requirements.  The NETCONF reviewers have also
suggested that the optional insecure transport for non-configuration data)
will not be approved by the security ADs or reviewers.  Rather that both
groups arguing over what they think a security reviewer will say - we'd like
a person from the security directorate to speak for the security area. 

 

The security directorate has really help us in forming our work.  We had a
great security review on the I2RS architecture in December 2014/January 2015
from Tero Kivinen (kivinen@iki.fi) Also our GEN-ART review from Russ Housley
also suggested issues.  After these issues we split our security work into
wire-protocol security and environment security.  We need help to determine
that we have split the work correctly.  We are heading into WG adoption call
on these drafts next week. 

 

The details are in the message below I sent to Kathleen and Stephen.
However, I recalled that last time I also need to send email to saag group
that helped me get a reviewer. 

 

Sue Hares

I2RS co-chair. 

 

From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 14, 2015 11:59 AM
To: 'Kathleen Moriarty'; 'Stephen Farrell'
Cc: 'Alia Atlas'
Subject: Urgent need for a person from the security directorate to review
key pionts in I2RS security 

 

Kathleen and Stephen: 

 

I sent you a request at IETF that we need a security person from the
security directorate to review the following I2RS security drafts. 

 

http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/

http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/

and a revision of 

http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/

 

Perhaps you will recall I mentioned this to you on Friday of IETF.  My need
has turned from urgent (in July) to "very urgent" as we start I2RS-netconf
design team to work on the  I2RS protocol design next week.   Would you
please find some who can advise me from the security directorate?  The
details are below. 

 

Sue Hares 

------------------

 

Document 1)  http://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/

 

We had editorial feedback on requirements 3 and 4 that these requirement
need clarification, and requirement 10 is ambiguous.  We would like feedback
on what the security person on this need for editorial review, and

review of the alternate text. 

 

In this document, we have feedback from Netconf that Requirement 8 and 12
are not security requirements. 

 

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

 

.         SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD
implement
   mechanisms that mitigate DoS attacks

 

Our input from the Ericsson network security is the mitigation of DDos was
important. 

 

Also, the I2RS protocol will have a multiple message sequence in which the
local system can: 

   1.  Perform all or none: All operations succeed or none of them will
       be applied.  This useful when there are mutual dependencies.
 
   2.  Perform until error: Operations are applied in order, and when
       error occurs the processing stops.  This is useful when
       dependencies exist between multiple-message operations, and order
       is important.
 
   3.  Perform all storing errors: Perform all actions storing error
       indications for errors.  This method can be used when there are
       no dependencies between operations, and the client wants to sort
       it out.

 

Is the ability to do impact security?  If so, we need to craft this work. 

If not, we will pull this from the security section. 

 

Lastly, the I2RS group early in its architecture decided that it was
important to provide some information via an insecure connection.
Publishing information via an insecure connection must consider the
information and the context.  This insecure data was going to be used to
provide global information that ISPs would want to publish to public from a
router. 

 

The architecture document: 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

 

I will be calling for the I2RS WG to reconsider the insecure connection, but
I suspect the I2RS WG will want the secure connection.   I need a person
from the security directorate to discuss the issues with during the WG call
regarding the insecure connection.   Unless there is overwhelming agreement
to get rid of the insecure connection, the I2RS chairs and AD are likely to
keep it in. 

 

Document 2)
http://datatracker.ietf.org/doc/draft-mglt-i2rs-security-requirements/

 

This draft considers the security environment that the I2RS operates within.
The security review in December 2014 indicated several comments that led us
to work on a security environment draft.