Subject: [NSIS] NATFW NSLP; confidentiality of signaling messages

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

Hi,

the draft is currently contradictory on the requirement of message 
confidentiality.

Section: 5.14.1 says: "optionally confidentiality protection"

While other sections, e.g. Section 5.13, instructs message 
confidentiality as a MUST, especially when authorization tokens are 
transported.

Is there a reason for not providing message confidentiality?! From a 
cryptographic point of view message confidentiality is cheap, since 
security contexts need to be established between neighboring NSIS nodes 
anyway.

Also, it should be clearly stated that NATFW NSLP does not provide 
message confidentiality by itself. Rather it relies on underlying 
protocols, for providing security services such as confidentiality, 
message integrity, data origin authentication, and replay protection. 
(In Section 5.14.1 only authentication is mentioned)

Greetings,
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: Mon, 17 Apr 2006 16:12:45 +0200

Hi Ali,

there is a MUST implement regarding confidentiality protection based on 
GIST. I would not want to indicate a MUST use here since the NATFW NSLP 
usage depends on the environment. The same is true for the QoS NSLP. For 
example, in my home network I use link layer security and I do not see 
why the NATFW NSLP has to use confidentiality protection in such an 
environment.

I will re-read the text to ensure that the language is used 
unambiguously (e.g., with regard to the usage of GIST security).

Ciao
Hannes

---

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

Hi Hannes, all,

as you know, the functionality provided by the NATFW NSLP is pretty 
complex and very security-sensitive.

Therefore, it will not be easy for someone who wants to deploy it to 
decide whether confidentiality in his network makes sense or not. I 
wouldn't leave this decision open because this would just introduce more 
vulnurabilities in the deployment of the NATFW NSLP.

Furthermore, message confidentiality for the NATFW NSLP is required for 
several reasons:

- it protects the SID, which is necessary if SID should be used as a 
proof for session ownership;

- it protect authorization tokens if there will be any. Actually , other 
protocols carrying an authorization tokens for the NATFW NSLP, e.g. 
application layer protocols, must be also confidentility-protected. 
Otherwise, we have a problem and authorization tokens would be useless.

- it protects the policy rules that need to be installed. The draft 
currently  argues that policy rules do not need to be protected from 
eavesdropping, since an attacker could also eavesdrop the traffic and 
find out which policy rules are currently installed. However, I think 
this argument would be just one more argument for not deploying the 
NATFW NSLP due to its insecurity

Also, if TLS or IPSec is used for providing hop-by-hop authentication 
between NSIS node, it does not requires an additional effort to provide 
message confidentiality. And as I mentiond before, from cryptographic 
point of view, confidentiality is cheap and does not add an addional 
delay to the signaling process.

What do you think?

Cheers,
Ali

Hannes Tschofenig wrote:
>> security contexts need to be established between neighboring NSIS 
>> nodes anyway.
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Apr 2006 23:49:20 +0200

Hi Ali,

> complex and very security-sensitive.

Where do you see the complexity in the protocol?

> vulnurabilities in the deployment of the NATFW NSLP.

Mandating a particular deployment model would, in my view, make it even 
harder to get things deployed.

> proof for session ownership;

I need to take a look again at the GIST draft but some time back I got 
the impression that the discovery exchange messages also carry the SID. 
As such, the SID would not be protected. I need to check it again.

> application layer protocols, must be also confidentility-protected. 
Actually they don't.
RSVP carries authorization tokens and RSVP signaling messages are not 
confidentiality protected.

> Otherwise, we have a problem and authorization tokens would be useless.
That's not true. It depends on the deployment environment.

> 
> - it protects the policy rules that need to be installed.
They do not need a protection since the data traffic will reveal these 
rules anyway.

  The draft
> NATFW NSLP due to its insecurity

I am not sure I can follow your line of argument here.

The NATFW NSLP is not IKEv2 and IPsec.

> message confidentiality.
> And as I mentiond before, from cryptographic 

That's true. IF you use hop-by-hop authentication then you might just 
want to enable confidentiality protection.

Still, I do not want to make deployment restrictions: If the 3GPP2 want 
to use the NATFW NSLP based on a specific set of ciphersuites then I am 
fine with it because they have their security folks that know the 
environment better than we do.

Ciao
Hannes

---

From: Ali Fessi <[email-masked]>
Date: Tue, 18 Apr 2006 00:32:03 +0200

Hi Hannes,

> Where do you see the complexity in the protocol?

The NATFW NSLP involves many entities in the signaling process which 
makes a security analysis difficult.

One of the main problems is that due to the NAT handling, message 
integrity can not be provided end-to-end or end-to-middle.

If the protocol would, for example, deal only with firewalls, it would 
be much easier.

>> wouldn't leave this decision open because this would just introduce 
>> more vulnurabilities in the deployment of the NATFW NSLP.
> 
> 
>> Furthermore, message confidentiality for the NATFW NSLP is required 
>> for several reasons:
>>

That would be even one more reason for NOT using the SID for the proof 
of session ownership!

>>
>> - it protect authorization tokens if there will be any. Actually , 
>> other protocols carrying an authorization tokens for the NATFW NSLP, 
>> e.g. application layer protocols, must be also confidentility-protected. 
> 
> Actually they don't.

do you know whether RSVP authorization tokens are used in some 
environments?! If the NATFW NSLP should be used in an Internet 
environment, then authorization tokens must be protected against 
eavesdropping.

> That's not true. It depends on the deployment environment.

agreed.

> The NATFW NSLP is not IKEv2 and IPsec.

I'm not talking about IKEv2 neither about IPSec.
>> between NSIS node, it does not requires an additional effort to 
>> provide message confidentiality.
>> And as I mentiond before, from cryptographic point of view, 
>> confidentiality is cheap and does not add an addional delay to the 
>> signaling process.
> 
> 
> 

Ok, I understand your point. But I think it should be clearly stated in 
the draft, which vulnerabilities do exist if the NATFW NSLP is used 
without message confidentiality and that it is highly recommended to 
provide message confidentiality either by using IPSec/TLS or a link 
layer specific mechanism (I guess the latter case will apply in 3GPP2 
environments).

Is that fine with you?

Cheers,
Ali.

---

From: "Robert Hancock" <[email-masked]>
Date: Tue, 18 Apr 2006 11:20:52 +0100

hi all,

some cents:

*) GIST carries the SID in routing state setup messages 
(including the Query). This is at least partly because
the routing state maintained at the GIST level is SID-
dependent (for security reasons which are discussed in
the spec). It might theoretically be possible to remove
the SID from the initial messages but it would require
quite a bit of careful thought, and would also require
quite a bit of surgery to the message processing rules.
The principle we adopted at an early stage was that 
confidentiality of the SID was not a goal.

*) GIST doesn't say anything about how SIDs should be
allocated. There are asymmetric cryptography techniques
that could use the SID in a particular way which was more
secure. That might be an option for future development of
the NATFW protocol.

*) I think (with Hannes) that it would be a very bad idea
to mandate the use of confidentiality. (Implementation is
already mandated, since it's an mandatory-to-implement
function within GIST.) Mandating the use would have one
of two effects:
- people who took the requirement seriously would quite
possibly decide never to use the protocol at all, even
in environments where it was legitimate, because of the
burden of credential & key management;
- people who did not take the requirement seriously would
simply ignore it. (How many times have you heard from
the v6 marketing community that it has 'security built in'?
and what effect does it have in practice?)

*) I think the right way to address these concerns is to
write a thorough security considerations section which 
explains (in particular) the consequences of not using
GIST-level confidentiality, both for yourself and for
other nodes along the path.

r.

> -----Original Message-----
> From: Ali Fessi [mailto:[email-masked]] 
> Sent: 17 April 2006 23:32
> To: Hannes Tschofenig
> Cc: nsis
> Subject: Re: [NSIS] NATFW NSLP; confidentiality of signaling messages
> 
> 
> Hi Hannes,
> 
> Hannes Tschofenig wrote:
> > Hi Ali,
> > 
> > Ali Fessi wrote:
> > 
> >> Hi Hannes, all,
> >>

---

From: <[email-masked]>
Date: Tue, 18 Apr 2006 14:37:17 +0300

Robert,

>(including the Query). This is at least partly because the 
>routing state maintained at the GIST level is SID- dependent 
>(for security reasons which are discussed in the spec). It 
>might theoretically be possible to remove the SID from the 
>initial messages but it would require quite a bit of careful 
>thought, and would also require quite a bit of surgery to the 
>message processing rules.
>allocated. There are asymmetric cryptography techniques that 
>could use the SID in a particular way which was more secure. 
>That might be an option for future development of the NATFW protocol.
>
>*) I think (with Hannes) that it would be a very bad idea to 
>mandate the use of confidentiality. (Implementation is already 
>mandated, since it's an mandatory-to-implement function within 
>GIST.) Mandating the use would have one of two effects:
>possibly decide never to use the protocol at all, even in 
>environments where it was legitimate, because of the burden of 
>credential & key management;
>simply ignore it. (How many times have you heard from the v6 
>marketing community that it has 'security built in'?
>*) I think the right way to address these concerns is to write 
>a thorough security considerations section which explains (in 
>particular) the consequences of not using GIST-level 
>confidentiality, both for yourself and for other nodes along the path.

Thanks for the summary.  I think that these are reasonable points.
Of course, we also have to remember that NATs themselves are a security
threat, and non-trusted firewalls can also be problematic.

John

---

From: Ali Fessi <[email-masked]>
Date: Tue, 18 Apr 2006 13:39:15 +0200

Hi Robert,

> other nodes along the path.

sounds like a good approach. agreed!

Cheers,
Ali

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Apr 2006 17:47:20 +0200

Hi Ali,

> If the protocol would, for example, deal only with firewalls, it would 

It is true that there are protocols with a simpler security analysis. 
However, I am convinced that the protocol is actually quite simple: 
CREATE message exchange and a REA message exchange.

Since we want to deal with migration scenarios (and we can do that) we 
provide the ability to stop signaling earlier.

The refresh handling is also pretty simple: E2E with the ability to 
allow intermediate nodes to send a NOTIFY message.

>> Mandating a particular deployment model would, in my view, make it 
>> even harder to get things deployed.
>>
>>>
>> the impression that the discovery exchange messages also carry the 
>> SID. As such, the SID would not be protected. I need to check it again.
> 
> 
> 

The session ownership section in the NATFW NSLP draft might be a bit 
misleading since it was written at the time when the session ownership 
was provided using the cryptographically generated identities. It was 
modified later but maybe we need to put additional text in there to 
highlight the provided properties much better.

> environment, then authorization tokens must be protected against 

The 3GPP used the authorization token idea for QoS signaling. However, 
they do not mandate RSVP usage but use GTP tunnels instead although the 
usage of RSVP is described in one of their documents.

Note that this use cases covers QoS signaling and not NATFW signaling.

(I can lookup the detailed references, if you want.)

>> Still, I do not want to make deployment restrictions: If the 3GPP2 
>> want to use the NATFW NSLP based on a specific set of ciphersuites 
>> then I am fine with it because they have their security folks that 
>> know the environment better than we do.
> 
> 

Sounds good to me. I will go through the text to see where additional 
wording would be a reasonable thing todo.

Please let me know if you have some suggestions for specific paragraphs 
as well.

Ciao
Hannes