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

From: Martin Stiemerling <[email-masked]>
Date: Thu, 4 May 2006 16:00:06 +0200

Robert, all,

I cannot say much other than reasonable points and we need
to nail the facts down in the security considerations section.

Just my few cents

   Martin

Am 18.04.2006 um 12:20 schrieb Robert Hancock:

> 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,
>>>>
>>>> as you know, the functionality provided by the NATFW NSLP
>> is pretty
>>>> complex and very security-sensitive.
>>>
>>>
>>> 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.
>>
>>>
>>>>
>>>> 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.
>>>
>>>
>>> Mandating a particular deployment model would, in my view,
>> make it even
>>> harder to get things deployed.
>>>
>>>>
>>>> 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;
>>>
>>>
>>> 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.
>>
>>
>> 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.
>>> RSVP carries authorization tokens and RSVP signaling
>> messages are not
>>> confidentiality protected.
>>
>> 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.
>>
>>>
>>>> Otherwise, we have a problem and authorization tokens
>> would be useless.
>>>
>>> That's not true. It depends on the deployment environment.
>>
>> agreed.
>>
>>>
>>>>
>>>> - 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
>>>
>>>> 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
>>>
>>>
>>> I am not sure I can follow your line of argument here.
>>>
>>> The NATFW NSLP is not IKEv2 and IPsec.
>>
>> I'm not talking about IKEv2 neither about IPSec.
>>>
>>>>
>>>> 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.
>>>
>>>
>>>
>>> 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.
>>
>> 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.
>>
>>>
>>> Ciao
>>> Hannes
>>>
>>>>
>>>> What do you think?
>>>>
>>>> Cheers,
>>>> Ali
>>
>>
>> -- 
>> Ali Fessi
>> University of Tuebingen, Germany
>>
>> _______________________________________________
>> nsis mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/nsis
>>
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

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