Subject: [Sip] SIP message integrity

From: "Steffen Fries" <[email-masked]>
Date: Wed, 24 Apr 2002 13:51:05 +0200

Hi,

I've got a question to the provision of message integrity, 
which might be scenario specific.

SIP itself does not provide message integrity by itself. 
Instead message body integrity may be achieved by using HTTP 
Digest Authentication. This is not sufficient for many 
scenarios. Especially the security for the last hop should have 
an integrity protection that covers the complete message.

For the 3GPP networks there was a decision to have integrity 
for the last hop by using IPSec in favour of the SIP Digest 
Authentication. But for wireline networks the usage of an 
additional security protocol might not always be the best 
choice.

During IETF53 I've got the impression that people rather tend 
to go with TLS to achieve message integrity than using an 
extension to SIP. A possible extension to be used would be the 
SIP Digest Authentication (draft-undery-sip-auth-00.txt), which 
was also discussed elaborately during the last meeting. 

Did I get a wrong impression or is the TLS way really 
sufficient for most of the cases? 

Regards
	Steffen

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Apr 2002 05:10:06 -0700 (PDT)

> sufficient for most of the cases? 

   If you run SIP over UDP, TLS is useless and IPsec
   is a better choice. Also: the digest schemes don't
   address confidentiality.

	Mike

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 24 Apr 2002 14:24:13 +0200

>    is a better choice. Also: the digest schemes don't
That is true, but is confidentiallity especially for the first 
hop necessary? Imagine a scenario, where you have a SIP 
telephony service provider and a small size company uses this 
service. The company will probably have a firewall deployed. If 
you use IPSec or TLS to protect the link between the user in 
the company and the telephony service provider, the user will 
not be able to make a phone call, since the port information of 
the RTP communication is encrypted and the firewall does not 
possess the appropriate key.

Steffen
___________________________________________________________
Steffen Fries,     Siemens AG, CT IC 3	
Otto-Hahn-Ring 6,  D-81730 Munich, Germany 
Phone:  (+49) 89 / 636-53403, Fax  :  (+49) 89 / 636-48000
Email:  [email-masked]
___________________________________________________________
    This email was written on 100% recycled bytes!

---

From: Michael Thomas <[email-masked]>
Date: Wed, 24 Apr 2002 06:03:48 -0700 (PDT)

Steffen Fries writes:
 > hop necessary? Imagine a scenario [...]

   It's equally easy for me to imagine scenarios like
   cable MSO's not turing on DOCSIS BPI (which I've heard
   is quite common), wireless AP's with braindead
   L2 encryption, and DSL providers not doing
   anything at all. When you need it, you need it.

   As for the middle boxen you posit, this is the
   price of non-transparency. Your middle box will 
   have an equal amount of trouble adultering a
   message covered by a keyed hash if it doesn't
   posess a key. Some of us think this is a feature.

		   Mike

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 24 Apr 2002 16:36:32 +0200

>    posess a key. Some of us think this is a feature.

You are certainly right, but when no NAT/PAT is involved there 
is no need from the middle-box to alter the message. It would 
just need to trace the messages to open/close the appropriate 
ports on the firewall.

Anyway, I was interested if there are more scenarios evident 
were security in terms of message integrity protection is 
necessary and additional security protocols are not favoured to 
provide this service.

Steffen________________________________________________________
___

---

From: Chris Martin <[email-masked]>
Date: Thu, 25 Apr 2002 00:27:57 -0500

>    anything at all. When you need it, you need it.

These are merely examples of poor practices in the wild. Once a few well
placed lawsuits are lodged I bet this practices ceases.

---

From: Chris Martin <[email-masked]>
Date: Thu, 25 Apr 2002 00:38:09 -0500

> necessary and additional security protocols are not favoured to

How about internal office communications, once deemed secure, to a
certain extent with the exception of a few PBX admins, which can now be
eavesdropped on by anyone with a LAN connection a sniffer, and assuming
enough knowledge to be dangerous in a switched environment, that can
capture and replay media of a confidential nature such as high level
conferencing.....

This scenario actually fits the need for additional security
protocols...but thats because I am concerned along those same lines.

Along the lines of not wanting additional security protocols...besides
issues related to dynamic pinholing, signaling modification for
NAT/NAPT, bypassing intrusion detection systems is another area of
concern. If certain signaling fields are encrypted unauthorized access
can be masked. I think that encryption of the media stream and signaling
authentication makes more sense.

---

From: Chris Martin <[email-masked]>
Date: Thu, 25 Apr 2002 00:25:54 -0500

> possess the appropriate key.

I would recomend that the firewall not be the endpoint for encryption,
or if it is then it will have the pre-share key.

%--%      +---------+        /-----\    /-------\    +----------+
 /\-------| firewall|--------| VPN |----|SP VPN |----| SP Proxy |
====      +---------+        \-----/    \-------/    +----------+
                                \___IPSec___/ 
                            or       
                     \__________IPSec____/

In the above scenario either way, the signaling must be taken care of
prior to encapsulation/decapsulation.

I agree with you, otherwise, the firewall cannot act on SIP signaling.

This only provides confidentiality between the customer Edge and the SP
edge. Internally on the customer network data is still "in the clear"

Chris

---

From: "Steffen Fries" <[email-masked]>
Date: Thu, 25 Apr 2002 10:27:05 +0200

> protocols...but thats because I am concerned along those same lines.
Encryption of the media stream in corporate environments is 
certainly an important requirement. It may also be interesting 
for carrier grade solutions.

> issues related to dynamic pinholing, signaling modification for NAT/NAPT,
> bypassing intrusion detection systems is another area of concern. If
> certain signaling fields are encrypted unauthorized access can be masked.
> I think that encryption of the media stream and signaling authentication
> makes more sense.

Does this mean you would favour signaling authentication rather 
than signaling integrity? Is the reason for this the support of 
NAT/NAPT?

Steffen

---

From: Chris Martin <[email-masked]>
Date: Thu, 25 Apr 2002 19:36:20 -0500

> than signaling integrity? Is the reason for this the support of

No I would prefer both actually, but I am inclined to be one of the more
paranoid.  :^)

But yes the reasoning for my comment is due to the fact that to permit
signaling through sip enabled nat/napt, at a minimum the SDP must not be
encrypted. That is not to say that I dont want full encryption....I do,
but thats another discussion and a different topic.

---

From: Chris Martin <[email-masked]>
Date: Fri, 26 Apr 2002 07:42:22 -0500

> but thats another discussion and a different topic.

I should clarify this further by stating that I would like to see full
encryption of signaling and media, but I dont want to hamper the efforts
of firewall vendors in their effort to facilitate SIP, which most have
done or are in process of doing. There are now at least 5 B2BUA style
firewall products and 3 application layer gateway style firewall vendors
with firewall solutions available or about to be available. There are
also about 5 other vendors providing other alternatives to firewalls to
address private address space and/or dynamic pinhole capability for SIP.
Many of these are well known vendors. 

Also many clients offer NAT features that would be useless with this
level of encryption initially.

It almost appears that to provide the level of integrity and
confidentiality that may be required in the future, the requirement
would be to provide a VPN capability in the client for media and
signaling and to proxy all such traffic to a carrier based VPN gateway
for decapsulation/encapsulation or between endpoints for the same
action. But then you get to the private address issues again and
circumvention of security policy (IDS cant detect unauthorized
communcations, firewalls cant enforce security policy via filters,
etc...).