Subject: [NSIS] Pending issue secdir review of draft-ietf-nsis-nslp-natfw-13.txt

From: Martin Stiemerling <[email-masked]>
Date: Mon, 18 Jun 2007 11:36:32 +0200

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 <[email-masked]>
> Datum: 11. Dezember 2006 10:22:31 MEZ
> An: NSIS <[email-masked]>
> Kopie: [email-masked]
> 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: [email-masked]
> ----------------------------------------------------------------------
>
> Von: Catherine Meadows <[email-masked]>
> Datum: 10. Dezember 2006 15:32:45 MEZ
> An: [email-masked], [email-masked], [email-masked],  
> [email-masked], [email-masked],  
> [email-masked]
> Kopie: Catherine Meadows <[email-masked]>
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

[email-masked]
NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
London W3 6BL | Registered in England 2832014

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

---

From: <[email-masked]>
Date: Mon, 18 Jun 2007 10:19:09 -0500

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:[email-masked]] 
	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. 

	Thanks,

		Von: Magnus Westerlund <[email-masked]>
		Datum: 11. Dezember 2006 10:22:31 MEZ
		An: NSIS <[email-masked]>
		Kopie: [email-masked]
		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

	
----------------------------------------------------------------------
		Ericsson AB                | Phone +46 8 4048287
		Torshamsgatan 23           | Fax   +46 8 7575550
		S-164 80 Stockholm, Sweden | mailto:
[email-masked]

		Von: Catherine Meadows <[email-masked]>
		Datum: 10. Dezember 2006 15:32:45 MEZ
		An: [email-masked], [email-masked],
[email-masked], [email-masked],
[email-masked], [email-masked]
		Kopie: Catherine Meadows <[email-masked]>
		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

	
	[email-masked]
	NEC Europe Limited | Registered Office: NEC House, 1 Victoria
Road, London W3 6BL | Registered in England 2832014

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 19 Jun 2007 09:24:36 +0200

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

---

From: Ali Fessi <[email-masked]>
Date: Tue, 19 Jun 2007 14:40:32 +0200

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:
> 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 <[email-masked] 
> <mailto:[email-masked]>> <[email-masked] 
> <mailto:[email-masked]>>:
> 
>> Martin,
>>
>> Von: Magnus Westerlund <[email-masked] 
>> <mailto:[email-masked]>>
>> An: NSIS <[email-masked] <mailto:[email-masked]>>
>> Kopie: [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>>
>>
>> Von: Catherine Meadows <[email-masked] 
>> <mailto:[email-masked]>>
>> An: [email-masked] <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>,
>> [email-masked] <mailto:[email-masked]>, 
>> [email-masked] <mailto:[email-masked]>,
>> [email-masked] <mailto:[email-masked]>, 
>> [email-masked] <mailto:[email-masked]>
>> Kopie: Catherine Meadows <[email-masked] 
>> <mailto:[email-masked]>>
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
> 

-- 
Ali Fessi
Computer Networks and Internet
University of Tuebingen, Germany
Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/