Subject: [NSIS] NATFW NSLP; No solution provided for attack described in section 5.5.3

From: Ali Fessi <[email-masked]>
Date: Fri, 21 Apr 2006 00:11:32 +0200

Dear NATFW NSLP authors,

there is currently no security requirement derived from the threat 
described in Section 5.5.3 (Data Receiver (DR) behind a firewall);

although it is a very realistic attack!

However, looking at the whole document, a solution for resolving this 
attack can be actually provided:

- either by relying on an authorization framework (authorization tokens, 
SAML, etc.)

- or by relying upon GIST or underlying protocols, for providing 
hop-by-hop authentication;

So the derived security requirements could be updated accordingly (i 
could provide a suggestions for some text, if you want)

Also: the attack described in section 5.5.4 is actually the same except 
the middlebox function is a NAT instead of firewall; but this doesn't 
make a difference.

Regards,
Ali
-- 
Ali Fessi
University of Tuebingen, Germany
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Apr 2006 13:19:45 +0200

Hi Ali,

thanks for looking at these issues.

> although it is a very realistic attack!

I think some additional text is needed to indicate that this type of 
attack can be addressed in the following case:
* The DR might want to place restrictions on the data senders it wants 
to talk. This is possible with the DTINFO object. If he knows that he is 
going to talk to someone but does not know to whom then this is 
obviously a little bit difficult.
* The authorization policy solutions (done in the context of SIP), for 
example, could certainly help to prevent an adversary from learning the 
contact address of the data receiver.

I think we should add this text to the section instead of saying that 
there is no requirement raised. Since the authorization tokens are not 
dealt with in this document there is actually no requirement raised here.

> hop-by-hop authentication;

I agree that these mechanisms could prevent an "attack".
However, the current text already indicates that the middlebox could 
authorize the end host. As such, I think it is already addressed. Since 
this is the threat/scenario section I guess we don't need to describe 
possible solutions.

> the middlebox function is a NAT instead of firewall; but this doesn't 

With a DR behind a NAT the DS will send the NSIS signaling message (and 
the data traffic through the NAT) while this is not necessarily true for 
the Firewall case.

Still, I agree that both sections should be merged due to heir similiarity.

> Ali

Ciao
Hannes

> ------------------------------------------------------------------------
>

---

From: Ali Fessi <[email-masked]>
Date: Fri, 21 Apr 2006 13:53:07 +0200

Hi Hannes,

> dealt with in this document there is actually no requirement raised here.

sounds good.

>> - either by relying on an authorization framework (authorization 
>> tokens, SAML, etc.)
>>
>> Also: the attack described in section 5.5.4 is actually the same 
>> except the middlebox function is a NAT instead of firewall; but this 
>> doesn't make a difference.
> 
> 

sounds also good.

Thanks,
Ali