Subject: [NSIS] GIST authentication

From: "marganne etienne" <[email-masked]>
Date: Tue, 28 Mar 2006 08:35:40 +0200

Hello everybody,

I currently am a student ending my informatic engineer studies and i am studying NSIS and GIST through my end of study project. The topic is the use of NSIS to provide VoIP with a signaling protocol to correctly configure the bindings in NAT's and Firewalls. The question i have is about authentication of GIST adjacent nodes in a NSIS path, i did not see any mechanisms to ensure we do not add unthrustable nodes. I could be wrong and the answer could just be lying aroung. Anyway it think this is a big concern in security to be sure of the list of nodes member of the NSIS data path.

Thank you for reading, i hope to hear from you soon,

Marganne Etienne.

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Mar 2006 01:40:21 -0600

Hi Etienne,

please find my comments inline:

marganne etienne wrote:
> Hello everybody,
>  
> I currently am a student ending my informatic engineer studies and i am 
> studying NSIS and GIST through my end of study project. The topic is the 
> use of NSIS to provide VoIP with a signaling protocol to correctly 
> configure the bindings in NAT's and Firewalls. The question i have is 
> about authentication of GIST adjacent nodes in a NSIS path, i did not 
> see any mechanisms to ensure we do not add unthrustable nodes.

Let me try to phrase what I think you are saying. You are concerned that
- an ordinary router (i.e., non-NSIS node) claims to be an NSIS node
- a NATFW NSLP NSIS node claims to be a QoS NSLP NSIS node (or vice versas)
- a malicious NSIS node redirects signaling messages to an off-path NSIS 
node
- an NSIS node along the path becomes malicious?

Maybe you could elaborate a little bit more about your concern.

> I could 
> be wrong and the answer could just be lying aroung. Anyway it think this 
> is a big concern in security to be sure of the list of nodes member of 
> the NSIS data path.
>  

Ciao
Hannes

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

---

From: "marganne etienne" <[email-masked]>
Date: Tue, 28 Mar 2006 12:11:29 +0200

Hi everybody,

Here is the discussion with Hannes about GIST. Some part of the content were 
already posted by not all, so now it is done.

So as Mr Tschofenig said, there are no need of GIST nodes over the Internet 
to be present to get a NSIS session work properly. I agree with this.The 
problem now is this one :

There is, however, an authorization question. Take a look at the figure
 below:

 +----------------------+              +--------------------------+
 |          Network A   |              |              Network B   |
 |                      |              |                          |
 |            +---------+              +---------+                |
 |      +-///-+ Middle- |              | Middle- +-///-+          |
 |      |     |  box 1  |  No TLS      |  box 2  |     |          |
 |      |     +---------+              +---------+     |          |
 |      |               |              |               |          |
 |      |               |              |               |          |
 |      | TLS           |              |               | TLS      |
 |   +--+---+           |              |            +--+---+      |
 |   | Host |           |              |            | Host |      |
 |   |  A   |           |              |            |  B   |      |
 |   +------+           |              |            +------+      |
 +----------------------+              +--------------------------+

The following question arises: Why should Middlebox 2 authorize the
signaling message to traverse the firewall towards Host B?

To what Mr Tschofenig answered :
We came up with a few solutions (a deployment issue, however):
 - Delayed authorization (described in the main NATFW NSLP draft)
 - Authorization Tokens (described in a separate draft)
 - AAA interaction: Diameter has been used by a few SDOs to authorize the
   firewall request based on previous SIP interaction (in the same
 fashion as proposed for QoS signaling).

Now what i think is : if there is no need of GIST hops between a NSIS 
communication work and transmitting an authorization token could solve the 
authorization question, what could be the role of GIST in such cases ? Also 
this scheme :
- Two end hosts trying to communicate and open bindings in Firewall with the 
help of NSIS but without and GIST hops on the Internet between them.
- The authorization problem solved by an authorization token delivered, 
let's say by SIP.
- The authentication problem solved by TLS or something similar (i.e. adding 
an authentication part to NSIS messages at the beginning of session, to 
authenticate a particular session ID wich is supposed to be unique)

This scheme, then, is a least a bit similar to ICE with the Media Session 
Authorization. There are of course differences, but i think at least it 
looks similar. ICE provides the connectivity and MSA a way to authenticate 
and authorize the session data flow. One of the differences is that ICE do 
not use something similar to GIST, i mean there is only one layer... also i 
could be wrong.

Another little question : is there a way to re-use GIST states built by QOS 
NSLP with NAT/FW NSLP and the opposite ?

Thank you for reading,

Marganne Etienne.

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "marganne etienne" <[email-masked]>
Sent: Tuesday, March 28, 2006 11:37 AM
Subject: Re: [NSIS] GIST authentication

> Hi Etienne,
>
> marganne etienne wrote:
>> Hi Hannes,
>>
>> So since there are TLS and the cookies, the GIST hops can be 
>> authenticate. Now i have another question :
>> Let's say we use NSIS NAT/FW NSLP to open bindings in Firewalls located 
>> at the edges of two subnets. Let's say there are no GIST aware nodes to 
>> create a path between both sides. Somthing like this :
>>
>> NSIS Proxy -- Firewall 1 ---- Internet ---- Firewall 2 --- NSIS Proxy
>>
>> Will it be possible to open the bindings, if both knows their IP adresses 
>> ?  Or is it absolutly necessary to have some GIST nodes on the
>> internet to create a path ?
>
> No, that's not necessary.
>
>
> Btw, in your figure above it would be possible to have something like:
>
> End Host -- Firewall 1 ---- Internet ---- Firewall 2 --- End Host
>
>
>  (there are supposed to have several hops on
>> the Internet between the two sides.) If there is a need for several 
>> GIST/NSIS nodes to be present on the net then there could be some 
>> problems with the installation of NSIS because one could have to install 
>> a lot of those GIST aware hops over the Internet.
> This would indeed be a deployment problem. Hence, it is not necessary.
>
> There is, however, an authorization question. Take a look at the figure 
> below:
>
> +----------------------+              +--------------------------+
> |          Network A   |              |              Network B   |
> |                      |              |                          |
> |            +---------+              +---------+                |
> |      +-///-+ Middle- |              | Middle- +-///-+          |
> |      |     |  box 1  |  No TLS      |  box 2  |     |          |
> |      |     +---------+              +---------+     |          |
> |      |               |              |               |          |
> |      |               |              |               |          |
> |      | TLS           |              |               | TLS      |
> |   +--+---+           |              |            +--+---+      |
> |   | Host |           |              |            | Host |      |
> |   |  A   |           |              |            |  B   |      |
> |   +------+           |              |            +------+      |
> +----------------------+              +--------------------------+
>
> The following question arises: Why should Middlebox 2 authorize the 
> signaling message to traverse the firewall towards Host B?
> We came up with a few solutions (a deployment issue, however):
> - Delayed authorization (described in the main NATFW NSLP draft)
> - Authorization Tokens (described in a separate draft)
> - AAA interaction: Diameter has been used by a few SDOs to authorize the 
> firewall request based on previous SIP interaction (in the same fashion as 
> proposed for QoS signaling).
>
> Ciao
> Hannes
>
>>
>> Thank you,
>>
>> Marganne Etienne.
>>
>> ----- Original Message ----- From: "Hannes Tschofenig" 
>> <[email-masked]>
>> To: "marganne etienne" <[email-masked]>
>> Sent: Tuesday, March 28, 2006 10:29 AM
>> Subject: Re: [NSIS] GIST authentication
>>
>>
>>> Hi Etienne,
>>>
>>> marganne etienne wrote:
>>>
>>>> Hi Hannes,
>>>>
>>>> Well, indeed i was thinking about all cases that could let a GIST/NSIS 
>>>> node being unthrustable.
>>>
>>>
>>> I try to avoid the term "trust" in the meanwhile since it turns out to 
>>> be a placeholder for many other terms.
>>>
>>>
>>>> If such a node gets added to a NSIS path through a GIST exchange (i.e. 
>>>> while the path is being built), it will be hard to dectect it and 
>>>> therefore hard to remove.
>>>
>>>
>>> With the path-coupled MRM a node is only added if
>>> - it supports the signaling application in question
>>> - it sees the signaling messages (discovery messages)
>>>
>>>
>>>> That could happen for example in the cases you talked about :
>>>>
>>>> Is it impossible ? I do not think so, but it is not really important if 
>>>> we can be sure that it will act correctly according to what it claims 
>>>> to be.
>>>
>>>
>>> This is certainly not an impossible scenario but somewhat hard to 
>>> prevent. We have written a paper about this aspect some time ago and we 
>>> were not sure whether this is really something to worry about:
>>>
>>> C. Aoun, et al.: "Securing Middlebox Discovery for Path-Directed 
>>> Signaling in the Internet", in 5th Workshop on Applications and Services 
>>> in Wireless Networks (ASWN), June 29th - July 1st, 2005.
>>>
>>>
>>> There is also a draft that talks about some of the issues listed in the 
>>> paper (e.g., 3GPP GBA).
>>> http://www.tschofenig.priv.at/drafts/draft-tschofenig-nsis-gist-security-00.txt
>>>
>>>
>>>> - a malicious NSIS node redirects signaling messages to an off-path 
>>>> NSIS node
>>>> This is clearly what i was thinking about. Such nodes that redirects 
>>>> messages, in a way that it will break the end-to-end security are 
>>>> dangerous.
>>>
>>>
>>> This threat is actually prevented with the help of cookies if the 
>>> off-path node is not aware of this re-direction attempt.
>>>
>>> Note that the term "end-to-end" security basically means between 
>>> neighboring GIST hops (since this is the end of the communication).
>>>
>>>
>>>> As far as i have seen, there are nothing to authenticate GIST nodes.
>>>
>>>
>>> Actually, Transport Layer Security provides the ability to authenticate 
>>> GIST nodes.
>>>
>>>
>>>> If still there could be authorization tokens at the NSIS level, there 
>>>> is nothing similar for GIST, once again as far as i know.
>>>
>>>
>>> True, there are no authorization tokens at the GIST layer. The 
>>> authorization tokens typically need to have some content to ensure that 
>>> the authorization token are meaningful. This semantic is available at 
>>> the signaling application layer. Hence, we have the tokens there.
>>>
>>>
>>>
>>>
>>>> In some kinds of way this is the same problem. How to be sure that they 
>>>> will act correctly ?
>>>
>>>
>>> Detecting that a node acts malicious is difficult: Try to compile a 
>>> complete list of incorrect behavior for, e.g., a QoS NSLP node.
>>>
>>> Ciao
>>> Hannes
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Marganne Etienne
>>>> ----- Original Message ----- From: "Hannes Tschofenig" 
>>>> <[email-masked]>
>>>> To: "marganne etienne" <[email-masked]>
>>>> Cc: <[email-masked]>
>>>> Sent: Tuesday, March 28, 2006 9:40 AM
>>>> Subject: Re: [NSIS] GIST authentication
>>>>
>>>>
>>>>> Hi Etienne,
>>>>>
>>>>>>  I currently am a student ending my informatic engineer studies and i 
>>>>>> am studying NSIS and GIST through my end of study project. The topic 
>>>>>> is the use of NSIS to provide VoIP with a signaling protocol to 
>>>>>> correctly configure the bindings in NAT's and Firewalls. The question 
>>>>>> i have is about authentication of GIST adjacent nodes in a NSIS path, 
>>>>>> i did not see any mechanisms to ensure we do not add unthrustable 
>>>>>> nodes.
>>>>>
>>>>>
>>>>>
>>>>> - a malicious NSIS node redirects signaling messages to an off-path 
>>>>> NSIS node
>>>>>> I could be wrong and the answer could just be lying aroung. Anyway it 
>>>>>> think this is a big concern in security to be sure of the list of 
>>>>>> nodes member of the NSIS data path.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 28 Mar 2006 06:34:22 -0600

Hi Etienne,

please find a few comments below:

marganne etienne wrote:
> Hi everybody,
> 
> Here is the discussion with Hannes about GIST. Some part of the content 
> were already posted by not all, so now it is done.
> 
> So as Mr Tschofenig said, there are no need of GIST nodes over the 
> Internet to be present to get a NSIS session work properly. I agree with 
> this.The problem now is this one :
> 
> communication work and transmitting an authorization token could solve 
> the authorization question, what could be the role of GIST in such cases 
> ?

 From a GIST point of view Middlebox 2 appears to be the next GIST node 
along the path when Middlebox 1 sends a discovery message.

The authorization token, if you want to use something like this, is 
provided by the QoS and the NATFW NSLP node.

> Also this scheme :
> - Two end hosts trying to communicate and open bindings in Firewall with 
> the help of NSIS but without and GIST hops on the Internet between them.
> - The authentication problem solved by TLS or something similar (i.e. 
> adding an authentication part to NSIS messages at the beginning of 
> session, to authenticate a particular session ID wich is supposed to be 
> unique)
> 
> This scheme, then, is a least a bit similar to ICE with the Media 
> Session Authorization.

Are you referring to draft-wing-session-auth-00?

> There are of course differences, but i think at 
> least it looks similar.

Looks similar? Hmmm.

Ping Pan and Henning Schulzrinne proposed YESSIR many years ago that 
suggested to use a path-coupled signaling protocol (namely RTCP) as a 
QoS and Firewall signaling protocol with the same characteristics. The 
authorization token usage is also known for many-many years.

> ICE provides the connectivity and MSA a way to 
> authenticate and authorize the session data flow.

What is the MSA?

> One of the differences 
> is that ICE do not use something similar to GIST, i mean there is only 
> one layer... also i could be wrong.
It is true that ICE does not use GIST. It does not use a layering 
concept because it was not meant to be used for different usage scenarios.

ICE itself is only an algorithm that uses different protocols. In fact 
it would make sense to use the NAT/FW protocol as one of the protocols 
that ICE could make use for traversing NATs and Firewalls.

> 
> Another little question : is there a way to re-use GIST states built by 
> QOS NSLP with NAT/FW NSLP and the opposite ?

You can reuse state established by GIST for other signaling 
applications. For example, if there is a messaging association between 
two GIST nodes then there is no need to setup a new one if the 
characteristics are the same.

Ciao
Hannes

>>> Let's say we use NSIS NAT/FW NSLP to open bindings in Firewalls 
>>> located at the edges of two subnets. Let's say there are no GIST 
>>> aware nodes to create a path between both sides. Somthing like this :
>>>
>>> Will it be possible to open the bindings, if both knows their IP 
>>> adresses ?  Or is it absolutly necessary to have some GIST nodes on the
>>> problems with the installation of NSIS because one could have to 
>>> install a lot of those GIST aware hops over the Internet.
>>
>> There is, however, an authorization question. Take a look at the 
>> figure below:
>>
>> - AAA interaction: Diameter has been used by a few SDOs to authorize 
>> the firewall request based on previous SIP interaction (in the same 
>>>>> Well, indeed i was thinking about all cases that could let a 
>>>>> GIST/NSIS node being unthrustable.
>>>>
>>>>
>>>>
>>>> I try to avoid the term "trust" in the meanwhile since it turns out 
>>>> to be a placeholder for many other terms.
>>>>
>>>>
>>>>> If such a node gets added to a NSIS path through a GIST exchange 
>>>>> (i.e. while the path is being built), it will be hard to dectect it 
>>>>> and therefore hard to remove.
>>>>
>>>>
>>>>
>>>>> Is it impossible ? I do not think so, but it is not really 
>>>>> important if we can be sure that it will act correctly according to 
>>>>> what it claims to be.
>>>>
>>>>
>>>>
>>>> prevent. We have written a paper about this aspect some time ago and 
>>>> we were not sure whether this is really something to worry about:
>>>>
>>>> Signaling in the Internet", in 5th Workshop on Applications and 
>>>> Services in Wireless Networks (ASWN), June 29th - July 1st, 2005.
>>>>
>>>>
>>>> There is also a draft that talks about some of the issues listed in 
>>>> the paper (e.g., 3GPP GBA).
>>>>> This is clearly what i was thinking about. Such nodes that 
>>>>> redirects messages, in a way that it will break the end-to-end 
>>>>> security are dangerous.
>>>>
>>>>
>>>>
>>>> Actually, Transport Layer Security provides the ability to 
>>>> authenticate GIST nodes.
>>>>
>>>>
>>>>> If still there could be authorization tokens at the NSIS level, 
>>>>> there is nothing similar for GIST, once again as far as i know.
>>>>
>>>>
>>>>
>>>> authorization tokens typically need to have some content to ensure 
>>>> that the authorization token are meaningful. This semantic is 
>>>> available at the signaling application layer. Hence, we have the 
>>>> tokens there.
>>>>
>>>>
>>>>
>>>>
>>>>> In some kinds of way this is the same problem. How to be sure that 
>>>>> they will act correctly ?
>>>>
>>>>
>>>>
>>>>>>>  I currently am a student ending my informatic engineer studies 
>>>>>>> and i am studying NSIS and GIST through my end of study project. 
>>>>>>> The topic is the use of NSIS to provide VoIP with a signaling 
>>>>>>> protocol to correctly configure the bindings in NAT's and 
>>>>>>> Firewalls. The question i have is about authentication of GIST 
>>>>>>> adjacent nodes in a NSIS path, i did not see any mechanisms to 
>>>>>>> ensure we do not add unthrustable nodes.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> - a malicious NSIS node redirects signaling messages to an 
>>>>>> off-path NSIS node
>>>>>>> I could be wrong and the answer could just be lying aroung. 
>>>>>>> Anyway it think this is a big concern in security to be sure of 
>>>>>>> the list of nodes member of the NSIS data path.

---

From: "marganne etienne" <[email-masked]>
Date: Tue, 28 Mar 2006 15:55:44 +0200

Hello,

I was indeed refering to 
http://www.ietf.org/internet-drafts/draft-wing-session-auth-00.txt when 
talking about Media Session Authorization (MSA).

I would like to thank you for your help. You made things clearer.

Marganne Etienne.

----- Original Message ----- 
From: "Hannes Tschofenig" <[email-masked]>
To: "marganne etienne" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 28, 2006 2:34 PM
Subject: Re: [NSIS] GIST authentication

>> Authorization.
>> There are of course differences, but i think at least it looks similar.
>
> Looks similar? Hmmm.
>
> suggested to use a path-coupled signaling protocol (namely RTCP) as a QoS 
> and Firewall signaling protocol with the same characteristics. The 
>> ICE provides the connectivity and MSA a way to authenticate and authorize 
>> the session data flow.
>
> What is the MSA?
>
>> One of the differences is that ICE do not use something similar to GIST, 
>> i mean there is only one layer... also i could be wrong.
> It is true that ICE does not use GIST. It does not use a layering concept 
> because it was not meant to be used for different usage scenarios.
>
> ICE itself is only an algorithm that uses different protocols. In fact it 
> would make sense to use the NAT/FW protocol as one of the protocols that 
> ICE could make use for traversing NATs and Firewalls.
>
>>
> You can reuse state established by GIST for other signaling applications. 
> For example, if there is a messaging association between two GIST nodes 
> then there is no need to setup a new one if the characteristics are the 
> same.
>
>>
>> Thank you for reading,
>>
>
> Ciao
> Hannes
>
>> Marganne Etienne.
>>
>>> firewall request based on previous SIP interaction (in the same fashion 
>>> as proposed for QoS signaling).
>>>
>>> Ciao
>>> Hannes
>>>
>>>>
>>>> Thank you,
>>>>
>>>> Marganne Etienne.
>>>>
>>>>>> Is it impossible ? I do not think so, but it is not really important 
>>>>>> if we can be sure that it will act correctly according to what it 
>>>>>> claims to be.
>>>>>
>>>>>
>>>>>
>>>>>>>>  I currently am a student ending my informatic engineer studies and 
>>>>>>>> i am studying NSIS and GIST through my end of study project. The 
>>>>>>>> topic is the use of NSIS to provide VoIP with a signaling protocol 
>>>>>>>> to correctly configure the bindings in NAT's and Firewalls. The 
>>>>>>>> question i have is about authentication of GIST adjacent nodes in a 
>>>>>>>> NSIS path, i did not see any mechanisms to ensure we do not add 
>>>>>>>> unthrustable nodes.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I could be wrong and the answer could just be lying aroung. Anyway 
>>>>>>>> it think this is a big concern in security to be sure of the list 
>>>>>>>> of nodes member of the NSIS data path.