RE: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt
<john.loughney@nokia.com> Mon, 18 June 2007 15:20 UTC
Return-path: <nsis-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J25-0001qJ-8p; Mon, 18 Jun 2007 11:20:45 -0400
Received: from nsis by megatron.ietf.org with local (Exim 4.43) id 1I0J23-0001kS-O9 for nsis-confirm+ok@megatron.ietf.org; Mon, 18 Jun 2007 11:20:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0J23-0001kH-E3 for nsis@ietf.org; Mon, 18 Jun 2007 11:20:43 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0J22-0003SM-31 for nsis@ietf.org; Mon, 18 Jun 2007 11:20:43 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l5IFKZ5g023848; Mon, 18 Jun 2007 18:20:40 +0300
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 18:20:26 +0300
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jun 2007 10:19:54 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt
Date: Mon, 18 Jun 2007 10:19:09 -0500
Message-ID: <071568CA7B789D4AA170CEF8C9613B4FB639D8@daebe103.NOE.Nokia.com>
In-Reply-To: <FBFB963C-00EF-422D-B689-E3E0B1D3FFA0@netlab.nec.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt
Thread-Index: AcexjDE/XHJSOpDWRc6h1TWIBuEzSwAL8HUw
References: <457D2357.3060503@ericsson.com> <FBFB963C-00EF-422D-B689-E3E0B1D3FFA0@netlab.nec.de>
From: john.loughney@nokia.com
To: stiemerling@netlab.nec.de, nsis@ietf.org
X-OriginalArrivalTime: 18 Jun 2007 15:19:54.0774 (UTC) FILETIME=[1FBC2360:01C7B1BC]
X-Nokia-AV: Clean
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 87e958510a39f65fbeb5ae8b5e360e3b
Cc:
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0594207052=="
Errors-To: nsis-bounces@ietf.org
Martin, When do you think you will be able to do this? I agree that this is the right thing to do. John ________________________________ From: ext Martin Stiemerling [mailto:stiemerling@netlab.nec.de] Sent: 18 June, 2007 02:37 To: nsis Subject: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt Hi all, We still have the pending issue of handling the sec dir review of the NATFW NSLP form last December. My current intention is too follow the guidance and to rework the whole security section to get it shorten and focussed on the real challenges of the NATFW NSLP. Any further thoughts or objections? Thanks, Martin (for all NATFW NSLP authors) Anfang der weitergeleiteten E-Mail: Von: Magnus Westerlund <magnus.westerlund@ericsson.com> Datum: 11. Dezember 2006 10:22:31 MEZ An: NSIS <nsis@ietf.org> Kopie: meadows@itd.nrl.navy.mil Betreff: [NSIS] [Fwd: secdir review of draft-ietf-nsis-nslp-natfw-13.txt] Hi NSIS Many thanks to Catherine Meadows (CC) who has done the Security Directorate review attached. It was done on my and the WG chairs request through the security ADs to help check the security details of the document. It contains the normal boilerplate for document that are in IESG review, but as you know this document isn't in that step yet. I hope this can help improve the document. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- Von: Catherine Meadows <meadows@itd.nrl.navy.mil> Datum: 10. Dezember 2006 15:32:45 MEZ An: iesg@ietf.org, secdir@mit.edu, nsis-chairs@tools.ietf.org, stiemerling@netlab.nec.de, hannes.tschofenig@siemens.com, elwynd@dial.pipex.com Kopie: Catherine Meadows <meadows@itd.nrl.navy.mil> Betreff: secdir review of draft-ietf-nsis-nslp-natfw-13.txt 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 primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This ID describes a protocol by which hosts may signal along the path used for transport of data packets the information necessary to configure NATs and firewalls according to the needs of the application data flows. Not surprisingly, the use of this protocol by unauthorized hosts could cause major security problems. The security considerations considerations section of this document describes the problems in detail, and outlines recommendations for solutions. These are to have security mechanisms providing data origin authentication, replay protection, integrity protection, and optional confidentiality protection. According to this document, uch security mechanisms can be provided for neighboring nodes by using a mutually authenticated transport layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities, as well as randomly generated (that is, unpredictable) session IDs. For non-neighboring nodes (presumably, this means nodes that do not share a security association) some sort of authorization is still necessary. The document discusses the possibility of using authorization tokens for this, and also provides some recommendations for protecting them (e.g. protection against tampering and confidentiality to protect against replay). The document does not go into detail about this, apparently because the usage of authorization tokens in NPLS is covered in another document (referenced in this ID). This security strategy looks plausible, but I found the justification for it very hard to follow. It starts with a number of possible attacks that an unauthorized host could perform using NSLP. Almost all of these attacks can be prevented by providing authorization (the exceptions are one or two denial of service attacks), and recommendations for authorizations are accordingly provided. However, there are two cases in which such recommendations are lacking. In one of these (5.2.3, data sender behind a firewall), no reason is given for the lack of a recommendation. In the other (5.8, misuse of unreleased sessions), it is claimed that this will be addressed by the NATFW NSLP. This last confused me; isn't that the protocol that this document describes? The list of attacks appears to have grown up over a period of time as the document went through its various iterations. In its current form, the list is not very helpful, especially as the end of the security considerations section, in which the actual recommendations are made do not reference them explicitly. Instead, there are somewhat vague comments such as Almost all security threats at the NATFW NSLP layer can be prevented by using a mutually authenticated Transport Layer secured connection and by relying on authorization by the neighboring NATFW NSLP entities. It would have been helpful for the reader to know what is meant by "almost all" without having to go back through the entire list of attacks. I would suggest that the authors provide a tightened up, condensed account of the security threats against NSLP. There is no need to try to have an exhaustive list of attacks; indeed such a list will be of limited use since one can never be certain that all the possibilities can be exhaustive. Instead, it would be more helpful to described classes of threats, with some illustrative examples. In the final section, where the recommendations for security mechanisms are made, you need to be explicit about the types of threats that are addressed. In particular, some characterization of the types of threats that are and are not addressed by authentication and authorization of neighboring nodes needs to be provided, I am wondering if it would not be a good idea to have a separate ID describing the security mechanisms that need to be used by this protocol. The WG already seems to be halfway there, since they are already working on an ID for authentication tokens. Catherine Meadows Head, Formal Methods Section Center for High Assurance Computer Systems Code 5540 Naval Research Laboratory Washington, DC 20375 phone: +1-202-767-3490 fax: +1-202-404-7942 _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis stiemerling@netlab.nec.de NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
_______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] [Fwd: secdir review of draft-ietf-nsis-nsl… Magnus Westerlund
- [NSIS] Pending issue secdir review of draft-ietf-… Martin Stiemerling
- RE: [NSIS] Pending issue secdir review ofdraft-ie… john.loughney
- Re: [NSIS] Pending issue secdir review ofdraft-ie… Martin Stiemerling
- Re: [NSIS] Pending issue secdir review ofdraft-ie… Ali Fessi