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