Subject: [NSIS] WGLC on " NAT/Firewall NSIS Signaling Layer Protocol (NSLP)" to start next week

From: <[email-masked]>
Date: Thu, 13 Apr 2006 15:35:22 +0300

Hi all,

The authors have indicated that they think that the draft is ready for
WGLC.
As long as the WG agrees, I'd like to start a WGLC on Monday April 17th,
until May 1st.

Feel free to send comments beforehand, however.

http://www.ietf.org/internet-drafts/draft-ietf-nsis-nslp-natfw-11.txt

thanks,
John

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

---

From: Ali Fessi <[email-masked]>
Date: Mon, 17 Apr 2006 14:58:18 +0200

Hi all,

a proof of session ownership is the NATFW NSLP is supposed to be
provided by the session ID. (Section 3.6)

However, SID can not provide any garantee that a request is
originating from the initial NI; even if it is randomly generated.

SID can be eavesdropped and can be miused for replay attacks and 
cut-and-paste attacks with modified policy rules.

Those attacks are already described, e.g. in Section 5.5 and 5.10; but 
no solution has been provided.

The problem with SID is that it is not cryptographically protected. 
Using it for proof of session ownership would be a mistake in the design 
of the NATFW NSLP similar to the mistake of using CRC for message 
integrity for WEP.

greeting,
Ali
-- 
Ali Fessi
University of Tuebingen, Germany

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Apr 2006 15:21:47 +0200

Hi Ali,

thanks for revisiting this discussion. In previous draft versions we 
described a solution based on a cryptographically generated Session 
Identifier (i.e., using the hash of a public key). Another document also 
elaborated on the usage of a hash based identifier.

We discussed the idea of a crypgraphically generated SIDs in the past 
but there was never huge excitement about it. Altought the usage of a 
crypgraphic identifier addresses certain attacks it also comes at a 
cost. The additional complexity was not seen as a good justification to 
introduce the cryptgraphic SID to address relatively minor attacks.

A randomly generated SID already prevents attacks by off-path 
adversaries. Adversaries along the path are problematic for various 
reasons (e.g., injection of data traffic).

Ciao
Hannes

---

From: Ali Fessi <[email-masked]>
Date: Mon, 17 Apr 2006 15:59:44 +0200

Hi Hannes,

Hannes Tschofenig wrote:
> adversaries.

this is not true if attackers can eavesdrop the SID and re-initiate 
signaling with it (this would be very easy, e.g. in a wireless 
environment).

The fact that NSIS nodes need to establish a security context with their 
NSIS peer-nodes to secure the signaling, reduces the severity of the 
problem. But attackers can also be legitimate neighboring hosts.

Such as an attack is already described in Section 5.10.1 (Miuse of 
mobility in NAT handling; BTW: this attacks is actually not specific to 
NATs; firewalls need also to update their policy rules for mobility support)

Protecting the signaling by providing message confidentiality could help 
to solve the problem. Is this correct?

> Adversaries along the path are problematic for various 

I actually don't see a severe problem with nodes along the path, since 
they will be of a nature of routers and not end hosts.

Ali
>> Using it for proof of session ownership would be a mistake in the 
>> design of the NATFW NSLP similar to the mistake of using CRC for 
>> message integrity for WEP.
>>
>> greeting,
>> Ali

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Apr 2006 16:21:31 +0200

Hi Ali,

> signaling with it (this would be very easy, e.g. in a wireless 

I guess you refer to off-path adversaries on the same shared medium. Right?

> NATs; firewalls need also to update their policy rules for mobility 
The attack in Section 5.10.1 can be prevented with ordinary TLS 
protection between neighboring nodes.

> to solve the problem. Is this correct?
Yes.

The only attack that cannot be addressed here is the following: The 
adversary sends a signaling message to a firewall that is not the next 
one along the path. Section 4.10 of RFC 4081 describes it.

> 
>> Adversaries along the path are problematic for various reasons (e.g., 
>> injection of data traffic).
> 
> 
True.

Ciao
Hannes

>>> Those attacks are already described, e.g. in Section 5.5 and 5.10; 
>>> but no solution has been provided.
>>>