Subject: RE: [Sipping] :draft-jain-sipping-srtp-00.txt

From: Ranjit Avasarala <[email-masked]>
Date: Thu, 11 Sep 2003 15:42:31 +0530

Hi 
    I have a doubt on use of srtp with sip.

  Actually if we use TLS i.e sips url instead of sip url. Then do we
also need to use srtp instead of rtp?

Ranjit

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Sep 2003 13:39:44 +0300

> also need to use srtp instead of rtp?

Sips and TLS protect only the signaling part of the communications.
Even if you use them, your media streams will be in cleartext.
If you are worried about the content of your calls leaking out,
signaling security does not help you.

SRTP on the other protects media streams. But it does not help
protecting SIP signaling. If you are worried about e.g.
authorization of subscribers in a commercial setup, or
about leaking private information about the kind of calls
you are making, you need some signaling security.

In conclusion, you need either sips/TLS, SRTP, or both
depending on your security needs.

(It might be nice if there was a new URL scheme which
shows that the media streams too have to be protected.
Sipss, anyone?)

--Jari

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 11 Sep 2003 08:48:37 -0400

--On Thursday, September 11, 2003 1:39 PM +0300 Jari Arkko 
<[email-masked]> wrote:
[snip]
> shows that the media streams too have to be protected.
The reason the security properties have to be indicated by a url scheme for 
sip is because the signaling is multi-hop. Since the media is end to end 
the policy can be indicated end-to-end as well.

At one point we had security pre-conditions in SDP offer/answer as well as 
QoS preconditions to address just this issue. If I recall the discussions 
correctly, we removed them because we were convinced that you could express 
the policy through the presence/absence of a key-exchange protocol embedded 
either in SDP or in a separate SIP body, and the parameters of that key 
exchange protocol. Is there some policy for media security which is not 
expressable through SDP offer/answer with embedded security parameters such 
as in draft-baugher-mmusic-sdpmediasec ?

If so, we ought to discuss and see what could be added or changed.

Dave.

> --Jari

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Thu, 11 Sep 2003 16:07:41 +0300

David R. Oran wrote:
> The reason the security properties have to be indicated by a url scheme 
> for sip is because the signaling is multi-hop. Since the media is end to 
> end the policy can be indicated end-to-end as well.

Yes, this is indeed possible. The multi-hop difference is
significant, thank you for reminding me about that...

(OTOH, I don't know if folks are using sips: also as some sort of
user-visible indication of security being present and used, since
the behaviour is mandated in RFCs. So it has another role besides
being used to carry the information through intermediate nodes.
Anyway, I don't know if adding new URL schemes is a good idea.
Certainly, if taken to its extreme, we can't be adding new URL
schemes for all kinds of parameter and policy decisions. That's
why we have SDP and other carried signaling information.)

--Jari

---

From: Ranjit Avasarala <[email-masked]>
Date: Fri, 12 Sep 2003 15:48:04 +0530

Hi
    Further to your suggestion, there should be a field in the SIP
signalling or SDP body which indicates whether media is to be secured or
not i.e RTP is to be used or SRTP is to be used. . But currently I don't
see any field in either SIP or SDP which could convey this info. So
either a new sip header or MIME type should be added which will indicate
the same.

Ranjit

-----Original Message-----
From: David R. Oran [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 6:19 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; Mats Näslund; Fredrik Lindholm
Subject: Re: [Sipping] :draft-jain-sipping-srtp-00.txt

for 

At one point we had security pre-conditions in SDP offer/answer as well
as 
QoS preconditions to address just this issue. If I recall the
discussions 
correctly, we removed them because we were convinced that you could
express 
the policy through the presence/absence of a key-exchange protocol
embedded 
either in SDP or in a separate SIP body, and the parameters of that key 
exchange protocol. Is there some policy for media security which is not 
expressable through SDP offer/answer with embedded security parameters
such 
as in draft-baugher-mmusic-sdpmediasec ?

Dave.

> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments of core SIP

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: Mats Näslund <[email-masked]>
Date: Fri, 12 Sep 2003 12:30:06 +0200

This is signalled by the use of AVP or SAVP profile, respectively.

/mats

---

From: Kavita Jain <[email-masked]>
Date: Wed, 10 Sep 2003 11:18:11 -0400

Dear Mr. Arrko, Mr. Naslund, and Mr. Lindholm,

I yet have to read the draft-ietf-msec-mikey-07.txt very carefully. However,
I would like to make the following general points regarding the proposed
scheme:

1) Not sure what does the "static DH key" mean in your email. The DH key
will be generated every time it is needed. 

2) The proposed scheme is a simple scheme that would work reasonably well
with the existing headers. The scheme is open for defining all the headers
that would be needed to negotiate other paramaters which are being
considered default right now. For example, bit length of the DH key and type
of the key which is DH.

3) The proposed scheme talks only about a way to exchange the key to encrypt
the media packets because of the following two reasons:
	a) Currently SIP does not have this capability. 
	b) SRTP does not talk about this issue either. 

4) Again, the bit length for the key is a default value. It can be of any
length once we define a header for it.

5) We are planning to run DES in Hardware. Not sure if this is what you
meant to ask.

Thanks

kavita

---

From: Mats Näslund <[email-masked]>
Date: Wed, 10 Sep 2003 21:17:40 +0200

Dear colleague(s),

Thanks for your reply. Some comments inline.

 > will be generated every time it is needed.

Then the whole schems breaks down. Unless at least one of the public
DH values are static (and certified by a certificate) you MUST use
authenticaion of the DH value, otherwise all security against MITM is 
lost. (See the RFC by Eric R you refered to.)

 > considered default right now. For example, bit length of the DH key 
and type

Unless you provide sufficient security (see above) I'm afraid
it doesn't matter so much what headers and parameters you can support
since you cannot trust them to be authentic.

 > 	b) SRTP does not talk about this issue either.

This is not correct. SRTP provides both integrity
and confidentiality (as well as a number of other config options).

 > length once we define a header for it.

I sincerely hope so, but at any rate your default (64) is *WAY*
too small.

 > 5) We are planning to run DES in Hardware. Not sure if this is what you

No, we wanted to ask which mode of encryption: ECB, CBC, OFB,.... etc
you propose to use, as it's not possible to fully see what security
properties you get otherwise (and even worse, without this defined
it will not be possible to interoperate).

In summary, I see serious issues with your proposal:

- neither key exchange, nor other parameters, are authenticated
- having DH as only method is very heavy on "thin" clients
- there is no option for integrity protection of the media
- as a consequence, there is no replay protection
- DES is no longer considered "secure enough", in particular no
   algorithm with 64 bit keys is
- ...

I think that in order to address all these issues, we will arrive at
something quite similar to MIKEY.

Kind regards,

/Mats

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 22 Sep 2003 18:03:01 -0700

> see any field in either SIP or SDP which could convey this info.

The <transport> field does this.  See section 12 of
draft-ietf-avt-srtp-09.txt.  It would look like this in SDP:

  m=audio 49170 RTP/SAVP 0

-d

> So either a new sip header or MIME type should be added which
> will indicate the same.
>
> Ranjit
>