Subject: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01

From: "Dawes, Peter, VF-Group" <[email-masked]>
Date: Wed, 28 Apr 2010 10:15:25 +0200

Hello All,
An updated draft is available on the topic of providing security for the
media plane between a SIP client and its first-hop proxy
(http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-01.txt).
This draft defines a "mediasec" header field parameter and a "mediasec"
option tag to extend RFC 3329 "Security Mechanism Agreement for the
Session Initiation Protocol (SIP)" to apply to the media plane. 
 
This draft results from 3GPP requirements to secure the media plane
controlled by SIP. The DTLS-SRTP work being done in IETF could not be
used because security setup is done within the media plane, and the
media plane might not be available at session setup. Also, DTLS-SRTP
does not meet the requirement for lawful interception to be
undetectable. 3GPP media plane security is described in
http://ftp.3gpp.org/ftp/Specs/2010-03/Rel-9/33_series/33328-910.zip.

A new version of I-D, draft-dawes-dispatch-mediasec-parameter-01.txt has
been successfully submitted by Peter Dawes and posted to the IETF
repository.

Filename:	 draft-dawes-dispatch-mediasec-parameter
Revision:	 01
Title:		 Capability Exchange for Media Plane Security
Creation_date:	 2010-04-19
WG ID:		 Independent Submission
Number_of_pages: 21

Abstract:
Negotiating the security mechanisms used between a Session Initiation
Protocol (SIP) user agent and its next-hop SIP entity is already
described in an RFC.  This document extends negotiation of a security
mechanism to the media plane by defining a new Session Initiation
Protocol (SIP) header field parameter to label security mechanisms that
apply to the media plane. 
 
Best regards,
Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 28 Apr 2010 08:20:41 -0500

On 4/28/10 03:15, Apr 28, Dawes, Peter, VF-Group wrote:
> Also, DTLS-SRTP does not meet the requirement for lawful interception to be undetectable.
>    

I'm afraid that requirement is out of scope for work undertaken in the 
IETF. The official, published, IETF-wide policy on lawful intercept is 
summarized as: "The IETF has decided not to consider requirements for 
wiretapping as part of the process for creating and maintaining IETF 
standards."

Please see RFC 2804 for further details.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Apr 2010 09:30:19 -0400

Peter - a question:

> Session Initiation Protocol (SIP)" to apply to the media plane. 

I am confused about the concept of "security for the media plane between 
a SIP client and its first-hop proxy".

A proxy has no involvement with media. I read through the draft to 
understand better, but didn't gain enlightenment there. In fact I found 
no mention of proxies at all. However I did find that the mechanism only 
applies in cases where there is a single Via header, which means the 
server must be one hop removed from the client.

So I haven't been able to discern if this is just a matter of the first 
hop from the client enforcing a requirement that media security be used 
between the UAC and UAS, or if there is some expectation that the proxy 
will in fact control the receipt and encryption/decryption of the media.

That might have been clearer if the examples showed the SDP.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 28 Apr 2010 19:12:03 +0200

The underlying way this works is described in:

http://www.3gpp.org/ftp/Specs/html-info/33328.htm

Search for "a2ae" for the relevant bits of text.

The first hop device is in fact a B2BUA with media, where it needs to implement these procedures. 

The general use case for these procedures would seem to be where you have an access technology that is not secure in itself, but needs some level of security therefore provided. So WLAN uses accessing 3G would use it, but 3G users would not, because the underlying bearers are already security protected to an extent.

I'll leave Peter to discuss how much more introductory material should be in the document, but this at least will hopefully help you understand what is happening.

regards

Keith 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, April 28, 2010 2:30 PM
> To: Dawes, Peter, VF-Group
> Cc: [email-masked]
> Subject: Re: [dispatch] New I-D: 
> draft-dawes-dispatch-mediasec-parameter-01
> 
> Peter - a question:
> 
> > An updated draft is available on the topic of providing 
> security for 
> > the media plane between a SIP client and its first-hop proxy 
> > 
> I am confused about the concept of "security for the media 
> plane between a SIP client and its first-hop proxy".
> 
> A proxy has no involvement with media. I read through the 
> draft to understand better, but didn't gain enlightenment 
> there. In fact I found no mention of proxies at all. However 
> I did find that the mechanism only applies in cases where 
> there is a single Via header, which means the server must be 
> one hop removed from the client.
> 
> So I haven't been able to discern if this is just a matter of 
> the first hop from the client enforcing a requirement that 
> media security be used between the UAC and UAS, or if there 
> is some expectation that the proxy will in fact control the 
> receipt and encryption/decryption of the media.
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Apr 2010 13:26:19 -0400

> The first hop device is in fact a B2BUA with media, where it needs to implement these procedures. 

This is the key thing I was suspecting.
If it needs to be a B2BUA for this to work, then talking about it as a 
proxy is inappropriate.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 28 Apr 2010 16:24:55 -0500

At 12:26 PM 4/28/2010, Paul Kyzivat wrote:

>If it needs to be a B2BUA for this to work, then talking about it as 
>a proxy is inappropriate.
>
>         Thanks,
>         Paul
>
>>The general use case for these procedures would seem to be where 
>>you have an access technology that is not secure in itself, but 
>>needs some level of security therefore provided. So WLAN uses 
>>accessing 3G would use it, but 3G users would not,

this makes it appear in an SBC role (which does always receive the 
media) more than a B2BUA role (which doesn't always (i.e., perhaps 
rarely) receive the media).

If this is agreed to, then this can be more of an e2e scenario in 
which DTLS-SRTP can be used, in which the P-CSCF has the decryption 
keys for the media - thus able to meet the requirements for LI that 
the IETF cannot address, per RFC 2804, as Adam stated already.

I'm also not completely clear now SRTP can be used at all in this 
scenario, given the scenario assumes that SRTP breaks the 
requirements for LI capture. Thus, isn't this doc advocating a 
mandate that (effectively) "there shall be no SRTP between the UE and 
the first hop proxy (that really isn't a proxy) because it breaks the 
LI requirements that 3GPP wants to address (that the IETF can't)"....

this appears curious at best

James

>>because the underlying bearers are already security protected to an extent.
>>I'll leave Peter to discuss how much more introductory material 
>>should be in the document, but this at least will hopefully help 
>>you understand what is happening.
>>regards
>>Keith
>>>From: [email-masked] [mailto:[email-masked]] 
>>>On Behalf Of Paul Kyzivat
>>>Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01
>>>
>>>Peter - a question:
>>>
>>>>option tag to extend RFC 3329 "Security Mechanism Agreement for 
>>>>the Session Initiation Protocol (SIP)" to apply to the media plane.
>>>I am confused about the concept of "security for the media plane 
>>>between a SIP client and its first-hop proxy".
>>>
>>>understand better, but didn't gain enlightenment there. In fact I 
>>>found no mention of proxies at all. However I did find that the 
>>>mechanism only applies in cases where there is a single Via 
>>>header, which means the server must be one hop removed from the client.
>>>
>>>So I haven't been able to discern if this is just a matter of the 
>>>first hop from the client enforcing a requirement that media 
>>>security be used between the UAC and UAS, or if there is some 
>>>expectation that the proxy will in fact control the receipt and 
>>>encryption/decryption of the media.
>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Apr 2010 00:45:54 -0400

Hey Peter,
Have you looked at RFC 3840?
Wouldn't just registering a new feature tag for sdes-srtp in IANA be what you need?  
Why do you need an option-tag, and why does this need to be in sec-agree?

-hadriel

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Dawes, Peter, VF-Group
> Sent: Wednesday, April 28, 2010 4:15 AM
> To: [email-masked]
> Subject: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01
> 
> Hello All,

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 29 Apr 2010 11:08:02 +0200

hello,

RFC 3840 does not help here. We need a solution where the UA can
indicate its support for sdes-srtp, but also where the SBC (P-CSCF) can
indicate its support for sdes-srtp. Both needs to happen at registration
time.  

RFC 3840 does only cover UA indicating support, but not SBC indicating
support.

regards
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Hadriel Kaplan
Sent: Thursday, April 29, 2010 6:46 AM
To: Dawes, Peter, VF-Group; [email-masked]
Subject: Re: [dispatch] New I-D:
draft-dawes-dispatch-mediasec-parameter-01

Hey Peter,
Have you looked at RFC 3840?
Wouldn't just registering a new feature tag for sdes-srtp in IANA be
what you need?  
Why do you need an option-tag, and why does this need to be in
sec-agree?

-hadriel

> Subject: [dispatch] New I-D:

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Apr 2010 12:58:31 -0400

> From: Leis, Peter (NSN - DE/Munich) [mailto:[email-masked]]
> Sent: Thursday, April 29, 2010 5:08 AM
> To: Hadriel Kaplan; Dawes, Peter, VF-Group; [email-masked]
> 

Right, but I'm trying to figure out why that is.  I mean what's the reason the UA needs to know at Registration time that it's next-hop b2bua can do srtp, instead of letting SDP handle it?

I *think* the answer is so that it can later send an INVITE with an SDP offer without failing the request - is that the reason?

> RFC 3840 does only cover UA indicating support, but not SBC indicating

Actually, in a way it does.  An SBC is a B2BUA.  As a UA, it can indicate feature tags.  What it *can't* do is indicate it in the REGISTER response it sends to the UA.  But the UA could send an OPTIONS to the B2BUA and get it in a feature tag of the response to the OPTIONS.  I know it sucks to send more SIP messages, but I don't see how to avoid that and be consistent with the SIP architecture.  It's really weird for a REGISTER response to indicate media capabilities of the Registrar.

-hadriel

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 30 Apr 2010 10:17:17 +0200

> From: ext Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2010 6:59 PM
> To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group; 
> [email-masked]
> Subject: RE: [dispatch] New I-D: 
> Right, but I'm trying to figure out why that is.  I mean 
> what's the reason the UA needs to know at Registration time 
> that it's next-hop b2bua can do srtp, instead of letting SDP 
> handle it?
> 
> I *think* the answer is so that it can later send an INVITE 
> with an SDP offer without failing the request - is that the reason?
> 

Right

> Actually, in a way it does.  An SBC is a B2BUA.  As a UA, it 
> can indicate feature tags.  What it *can't* do is indicate it 
> in the REGISTER response it sends to the UA.  But the UA 
> could send an OPTIONS to the B2BUA and get it in a feature 
> tag of the response to the OPTIONS.  I know it sucks to send 
> more SIP messages, but I don't see how to avoid that and be 
> consistent with the SIP architecture.  It's really weird for 
> a REGISTER response to indicate media capabilities of the Registrar.
> 

use of OPTIONS was discussed, but due to the additional signalling, it
was discarded.

The indication of network support for SDES-SRTP in response to REGISTER
is not included by the registrar, but by the network element placed at
the edge (the SBC/B2BUA)

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Apr 2010 11:46:39 -0400

> Sent: Friday, April 30, 2010 4:17 AM
 
OK, and I also agree that's a real problem.  That issue was raised in the IETF in 2006/2007.  There was a very simple proposal to avoid that, in draft-kaplan-mmusic-best-effort-srtp, but the decision of the MMUSIC WG was to instead use draft-ietf-mmusic-sdp-capability-negotiation to accomplish it.  That draft is now in the RFC editor's queue.  I know it's a lot of processing overhead, but that was the decision.  And I think 3gpp has put support for that into some release or other.

> use of OPTIONS was discussed, but due to the additional signalling, it

Considering all of the other signaling already required (subscription to reg-event, subscription to presence, xcap, possibly subscription to Config server) isn't an OPTIONS just a nit at this point?  And that way this could be a general solution, instead of a 3gpp-specific one.

> is not included by the registrar, but by the network element placed at

I know, but from the UA's perspective the REGISTER response is coming from the Registrar, possibly through proxies.  There's no logical/conceptual model in the IETF for a REGISTER response to indicate media capabilities of some middle hop of the REGISTER.

-hadriel

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Apr 2010 09:52:05 -0600

There has been more than one talks to 3GPP folks about how to do intercept with DTLS-SRTP and the folks involved were well aware of the undetectable requirement. Though I'm not infested in discussing wiretap at IETF, I do believe it is possible to construct a system several different way that meet the requirements I am aware of. (And it is possible to do without B2BUA but it seem the system here could do in the SBC)

>> Also, DTLS-SRTP does not meet the requirement for lawful interception to be undetectable.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html