Re: [NSIS] Pending issue secdir review ofdraft-ietf-nsis-nslp-natfw-13.txt

[Ali Fessi <[e-mail]>]

Hi Martin,

yes, I agree. The security section contains some text about security 
threats that is about 3 years old. It is necessary to update it.

I can go through this section again when you are done with re-writing it.

Cheers,
  Ali




Martin Stiemerling wrote:
> Hi John,
> 
> Yes I will be able to do this, I just want some feedback if the WG is 
> fine with it. 
> 
> I also see this as the right approach, i.e., narrowing the security 
> section down to the real issues that are still valid. Some of the issues 
> are more less GIST issues which have been described in GIST itself.
> 
> The current security section has grown over time, which is quite common 
> for older drafts.
> 
> Thanks,
> 
>   Martin
> 
> Am 18.06.2007 um 17:19 schrieb <[e-mail] 
> <mailto:[e-mail]>> <[e-mail] 
> <mailto:[e-mail]>>:
> 
>> 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:[e-mail]] 
>> 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 <[e-mail] 
>> <mailto:[e-mail]>>
>> Datum: 11. Dezember 2006 10:22:31 MEZ
>> An: NSIS <[e-mail] <mailto:[e-mail]>>
>> Kopie: [e-mail] <mailto:[e-mail]>
>> 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 [phone]
>> Torshamsgatan 23           | Fax   [phone]
>> S-164 80 Stockholm, Sweden | mailto:
>> [e-mail] <mailto:[e-mail]>
>>
>>
>> ----------------------------------------------------------------------
>>
>>
>>
>> Von: Catherine Meadows <[e-mail] 
>> <mailto:[e-mail]>>
>> Datum: 10. Dezember 2006 15:32:45 MEZ
>> An: [e-mail] <mailto:[e-mail]>, [e-mail] 
>> <mailto:[e-mail]>,
>> [e-mail] <mailto:[e-mail]>, 
>> [e-mail] <mailto:[e-mail]>,
>> [e-mail] <mailto:[e-mail]>, 
>> [e-mail] <mailto:[e-mail]>
>> Kopie: Catherine Meadows <[e-mail] 
>> <mailto:[e-mail]>>
>> 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: [phone]
>> fax: [phone]
>>
>> _______________________________________________
>> nsis mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>>
>>
>> [e-mail] <mailto:[e-mail]>
>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria
>> Road, London W3 6BL | Registered in England 2832014
>>
>>
>>
> 
> [e-mail] <mailto:[e-mail]>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL | Registered in England 2832014
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis


-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: [phone] / Fax: [phone]
EMail: [e-mail]
Web: http://net.informatik.uni-tuebingen.de/~fessi/


_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis