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

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 3 May 2010 15:32:19 +0200

comments inline 

> -----Original Message-----
> From: ext Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Friday, April 30, 2010 5:47 PM
> To: Leis, Peter (NSN - DE/Munich); Dawes, Peter, VF-Group; 
> [email-masked]
> Subject: RE: [dispatch] New I-D: 
> draft-dawes-dispatch-mediasec-parameter-01
> 
> 
> 
> > -----Original Message-----
> > From: Leis, Peter (NSN - DE/Munich) [mailto:[email-masked]]
> > Sent: Friday, April 30, 2010 4:17 AM
> > To: Hadriel Kaplan; Dawes, Peter, VF-Group; [email-masked]
> > 
> > > -----Original Message-----
> > > From: ext Hadriel Kaplan [mailto:[email-masked]]
> > > Sent: Thursday, April 29, 2010 6:59 PM
> > >
> > > 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
>  
> 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.
> 

The requirement in 3GPP is, that the UE has to know whether or not the
network (P-CSCF) will support SDES-SRTP before the session takes place,
if it wants to employ End2AccessEdge media plane security. This will
ensure that the IMS UE shares the media keys only with the P-CSCF and
not with some other entity. In addition, in 3GPP there is a requirement
that the UE knows whether media plane security is established between
itself and the network (i.e. End2AccessEdge), or whether media plane
security is established between itself and the far end. 

As you said, CapNeg has a lot of processing overhead, and in addition,
it does not solve the requirements I have listed.

> 
> > > > RFC 3840 does only cover UA indicating support, but not SBC
> > > indicating
> > > > support.
> > >
> > > 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.
> 
> 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.
> 
> 
> > 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)
> 
> 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: "Elwell, John" <[email-masked]>
Date: Fri, 7 May 2010 16:17:07 +0200

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leis, Peter 
> (NSN - DE/Munich)
> Sent: 03 May 2010 14:32
> To: ext Hadriel Kaplan; Dawes, Peter, VF-Group; [email-masked]
> Subject: Re: [dispatch] New I-D: 
> not with some other entity. 
[JRE] Why would the UE "want to employ End2AccessEdge" media plane security, as opposed to E2E media plane security? I would have thought the UE would always prefer the latter. Furthermore, the UE should not use keys that have value outside this particular communication session, so if they get passed on beyond the P-CSCF, no harm is done. In fact, if they reach the remote UA, you can end up with E2E security, which would be great from the UE's perspective.

> In addition, in 3GPP there is a 
> requirement
[JRE] That would be interesting to know, but it is a more general problem - any B2BUA can terminate SRTP, and SIP does not provide any mechanism to indicate whether SRTP is truly end-to-end or just end-to-some-B2BUA. Also a gateway to TDM will terminate SRTP, and SIP does not provide any means of indicating whether SRTP is truly end-to-end or end-to-first-TDM-gateway.

John

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 20 May 2010 11:04:40 +0200

hello,

sorry for the late reply.

The requirments for media-plane security in 3GPP IMS have been defined
in TS 33.328 http://www.3gpp.org/ftp/Specs/html-info/33328.htm . 

For SDES SRTP there are two modes defined, one is end2end and one is
end2accessedge. We need to provide a solution for both modes.

And for end2accessedge we do have a requirement that the UE knows
whether or not the network (P-CSCF) will support SDES-SRTP before the
session takes place as described below.

Peter

> From: ext Elwell, John [mailto:[email-masked]] 
> Sent: Friday, May 07, 2010 4:17 PM
> To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, 
> Peter, VF-Group; [email-masked]
> [JRE] Why would the UE "want to employ End2AccessEdge" media 
> plane security, as opposed to E2E media plane security? I 
> would have thought the UE would always prefer the latter. 
> Furthermore, the UE should not use keys that have value 
> outside this particular communication session, so if they get 
> passed on beyond the P-CSCF, no harm is done. In fact, if 
> they reach the remote UA, you can end up with E2E security, 
> which would be great from the UE's perspective.
> 
> [JRE] That would be interesting to know, but it is a more 
> general problem - any B2BUA can terminate SRTP, and SIP does 
> not provide any mechanism to indicate whether SRTP is truly 
> end-to-end or just end-to-some-B2BUA. Also a gateway to TDM 
> will terminate SRTP, and SIP does not provide any means of 
> indicating whether SRTP is truly end-to-end or 
> end-to-first-TDM-gateway.
> 
> John
> 
> >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 20 May 2010 15:43:09 +0200

Peter,

I could not locate the particular requirements in the referenced document, which does not seem to have a Requirements section as such. Please cite the particular requirements that answer my questions and point to the section/paragraph where rationale for those requirements is given.

The Internet Draft will need to be enhanced to give more rationale for requirements, rather than rely on reference to a relatively large external document that allegedly has requirements hidden somewhere within it.

Thanks,

John 

> Sent: 20 May 2010 10:05
> To: Elwell, John; ext Hadriel Kaplan; Dawes, Peter, VF-Group; 
> [email-masked]

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 May 2010 07:53:43 +0200

hello John,

33.328 does not have a particular requirements section. It is the
stage-2 specification for the feature "media plane security" and as such
provides architecture and functional flows for the feature. I have
refered to this as "requirements".

Clause 4 of the docuement gives an overview and describes that two
solutions based on SDES are required, namely end2end and end2accessedge
media protection. The need for two modes based on SDES SRTP is reflected
throughout the specification where in every clause you find a sub-clause
for end2end and a sub-clasue end2accessedge. Clause 7 provides the
registration and session setup procedures, again different for end2end
and end2access edge.

So end2end and end2accessedge are described as two different and
distinct use cases.

One goal for end2accessedege security as specified in TS33.328 is to
allow to achieve media plane security (on the access leg) fully
independant of of any capabilities of clients on the far end side.

33.328 was developped based on requirements documented in 33.828
http://www.3gpp.org/ftp/Specs/html-info/33828.htm

Clause 4 describes the use cases whith 4.1.2 describing end2accessedge
(access media protection).

regards
Peter

> Sent: Thursday, May 20, 2010 3:43 PM
> I could not locate the particular requirements in the 
> referenced document, which does not seem to have a 
> Requirements section as such. Please cite the particular 
> requirements that answer my questions and point to the 
> section/paragraph where rationale for those requirements is given.
> 
> The Internet Draft will need to be enhanced to give more 
> rationale for requirements, rather than rely on reference to 
> a relatively large external document that allegedly has 
> requirements hidden somewhere within it.
> 
> Thanks,
> 
> John 
> 
> > > From: ext Elwell, John 
> [mailto:[email-masked]]

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 May 2010 09:15:01 +0200

Peter,

Rather than having to trawl through several 3GPP specifications to find requirements, it would be better to state them clearly, with motivation, in the Internet Draft, so that DISPATCH has something concrete on which to base its discussions.

I don't think I received satisfactory answers to the following questions that I posted on 2010-05-07 (apologies if I missed the answers):

First I asked:
"Why would the UE "want to employ End2AccessEdge" media plane security, as opposed to E2E media plane security? I would have thought the UE would always prefer the latter. Furthermore, the UE should not use keys that have value outside this particular communication session, so if they get passed on beyond the P-CSCF, no harm is done. In fact, if they reach the remote UA, you can end up with E2E security, which would be great from the UE's perspective."

Second, in response to your statement "The requirement in 3GPP is, that the UE has to know whether or not the network (P-CSCF) will support SDES-SRTP before the session takes place, if it wants to employ End2AccessEdge media plane security. This will ensure that the IMS UE shares the media keys only with the P-CSCF and not with some other entity." I asked the question:

"That would be interesting to know, but it is a more general problem - any B2BUA can terminate SRTP, and SIP does not provide any mechanism to indicate whether SRTP is truly end-to-end or just end-to-some-B2BUA. Also a gateway to TDM will terminate SRTP, and SIP does not provide any means of indicating whether SRTP is truly end-to-end or end-to-first-TDM-gateway."

In addition, I am curious to know whether the proposed mechanism will work when there is a proxy between the UA and the P-CSCF, e.g., a proxy/B2BUA in an enterprise or residential network. Is there a danger that the proxy/B2BUA will apply end2AccessEdge security (between the UA and itself), leaving the hop between proxy/B2BUA and the P-CSCF unprotected? The so-called requirement of the UA to provide security on the first hop is fulfilled, but the critical hop to the P-CSCF is not secured.

There have been extensive discussions on the DISPATCH and the former SIP lists over the last couple of years or more about authenticated identity and how that can be used to give some guarantee to the user as to where secure media terminates, without any resolution. A solution that just guarantees security on a first hop does not really take us further forward. As Hadriel pointed out, there is the SDP capability negotiation solution, as well as other solutions proposed in the past.

John

> Sent: 26 May 2010 06:54

---

From: "Leis, Peter (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 May 2010 11:07:44 +0200

John,

pls see inline 

> Sent: Wednesday, May 26, 2010 9:15 AM
> Rather than having to trawl through several 3GPP 
> specifications to find requirements, it would be better to 
> state them clearly, with motivation, in the Internet Draft, 
> so that DISPATCH has something concrete on which to base its 
> discussions.
> 
> I don't think I received satisfactory answers to the 
> following questions that I posted on 2010-05-07 (apologies if 
> I missed the answers):
> 
> First I asked:
> "Why would the UE "want to employ End2AccessEdge" media plane 
> security, as opposed to E2E media plane security? I would 
> have thought the UE would always prefer the latter. 
> which would be great from the UE's perspective."

[PETER] if the UE knows that the network support media plane security,
then the UE can employ this mechanism in order to secure the access
link. This mechanisms is independant of support for SDES-SRTP in the UE
on the far end. From a network provider point of view this is a
desirable feature as it provides a level of security similar to what is
known from exsting cellular networks. 

> 
> Second, in response to your statement "The requirement in 
> 3GPP is, that the UE has to know whether or not the network 
> (P-CSCF) will support SDES-SRTP before the session takes 
> place, if it wants to employ End2AccessEdge media plane 
> security. This will ensure that the IMS UE shares the media 
> keys only with the P-CSCF and not with some other entity." I 
> asked the question:
> 
> "That would be interesting to know, but it is a more general 
> problem - any B2BUA can terminate SRTP, and SIP does not 
> provide any mechanism to indicate whether SRTP is truly 
> end-to-first-TDM-gateway."

[PETER] IF the UE knows that the network supports SDES-SRTP (i.e. P-CSCF
in collaboration with Access-Gateway), then this can be taken into
account when deciding whether or not to ask for SRTP. In the end this
has an effect on how fast the session setup will be, as the UE can avoid
unsuccessfuall session setups. As there are two distinct use cases,
namely end2end and end2accessedge, there is a requirement in a 3GPP
environment to let the UE (user) know what level of security has been
applied to the media.

> 
> In addition, I am curious to know whether the proposed 
> mechanism will work when there is a proxy between the UA and 
> the P-CSCF, e.g., a proxy/B2BUA in an enterprise or 
> residential network. Is there a danger that the proxy/B2BUA 
> will apply end2AccessEdge security (between the UA and 
> itself), leaving the hop between proxy/B2BUA and the P-CSCF 
> unprotected? The so-called requirement of the UA to provide 
> security on the first hop is fulfilled, but the critical hop 
> to the P-CSCF is not secured.

[PETER] at least in the IMS architecture (which is the driver for the
requirements in the draft) there is no proxy between the UA and the
P-CSCF. I guess that for enterprise/residential cases this would work as
well, as the "UA" in that case is the PBX/residential gateway
(attachment point to the SSP network) and therefore media is secured
between the PBX/residential gateway and the P-CSCF. In that case it is
NOT the linke between the real endpoints (i.e. the PBX phones or
residential phones) but the link between the attachement point and the
network that is secured.
> 
> There have been extensive discussions on the DISPATCH and the 
> former SIP lists over the last couple of years or more about 
> authenticated identity and how that can be used to give some 
> guarantee to the user as to where secure media terminates, 
> without any resolution. A solution that just guarantees 
> security on a first hop does not really take us further 
> forward. As Hadriel pointed out, there is the SDP capability 
> negotiation solution, as well as other solutions proposed in the past.

[PETER] cellular networks do have access link security, i.e. media
encryption. So I believe there is justification for such a solution

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 May 2010 12:22:57 +0200

> Sent: 26 May 2010 10:08
[JRE] My question was not about network provider benefit, it was about user benefit, or UE benefit. 
You appear to be asking for a solution whereby the UE can ask for single hop SRTP (just to the P-CSCF) and have it refused if the P-CSCF is unable to provide it, rather than allowing an entity beyond the P-CSCF to terminate SRTP. This I do not understand. Why would the UE __want__ to have security only on that hop and not be prepared to have security beyond that hop? As far as I can see, the UE would just want to ask for SRTP and would prefer to have SRTP end-to-end but might accept something less than end-to-end.

> environment to let the UE (user) know what level of security has been
[JRE]The UE could just ask for best effort SRTP - if it is supported by the "far end" (whether this be the P-CSCF or something beyond), SRTP will be used, if not RTP will be used. We have a solution for that already.

> residential phones) but the link between the attachement point and the
[JRE] The proxy/B2BUA acting as PBX might not handle media. Media (and hence media security) will come from the UA behind the PBX, whereas signalling security will come from the PBX. The PBX in this case is not in a position to negotiate media security - that is just passed on from the UA behind the PBX. It seems to me that trying to add media security to RFC 3329 violates this architectural distinction between the hop-by-hop nature of signalling and the end-to-end nature of media. I agree that if you put in a device such as a Session Border Controller (SBC) between the PBX and the IMS network the proposed solution might work, but we should not force the presence of an SBC here.

> encryption. So I believe there is justification for such a solution
[JRE] This does not answer my concern. I am not disputing that security is required. However, we already have a solution for best effort SRTP. The existing solution is not ideal, since it doesn't tell me how far media is secured, only that it is secured at least part of the way to the remote endpoint. What the draft seems to be asking for is a solution that specifically limits SRTP to a single hop, and I dispute the need and the architectural viability of that.

John

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 26 May 2010 13:50:05 +0200

Dear John, see inline 

Thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Elwell, John
Sent: Wednesday, May 26, 2010 12:23 PM
To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, Peter, VF-Group; [email-masked]
Subject: Re: [dispatch] New I-D: draft-dawes-dispatch-mediasec-parameter-01

> > To: Leis, Peter (NSN - DE/Munich); ext Hadriel Kaplan; Dawes, Peter, 
> > VF-Group; [email-masked]
> > Rather than having to trawl through several 3GPP specifications to 
> > find requirements, it would be better to state them clearly, with 
> > motivation, in the Internet Draft, so that DISPATCH has something 
> > concrete on which to base its discussions.
> > 
> > I don't think I received satisfactory answers to the following 
> > questions that I posted on 2010-05-07 (apologies if I missed the 
> > answers):
> > 
> > First I asked:
> > security, as opposed to E2E media plane security? I would have 
> > thought the UE would always prefer the latter.
> > Furthermore, the UE should not use keys that have value outside this 
> > particular communication session, so if they get passed on beyond 
> > the P-CSCF, no harm is done. In fact, if they reach the remote UA, 
> > you can end up with E2E security, which would be great from the UE's 
> > perspective."
> 
> link. This mechanisms is independant of support for SDES-SRTP in the 
> UE on the far end. From a network provider point of view this is a 
> desirable feature as it provides a level of security similar to what 
> is known from exsting cellular networks.

[Thomas] In my understnading there is a considerable user benefit in having some encryption for every call, irrespective of the capabilities of the peer (All 3GPP UEs prior to Rel-9 will not support SRTP media plane security, and in Rel-9 this is an optional feature). Consider an unsecured WLAN air interface as an important use case (3GPP air interfaces would offer encryption at a lower layer). 3GPP focused on the IMS scenario, where the operator is likely to use a walled garden and protect media streams in that manner. A call is likely to either go to a PSTN or some other IMS peer, where a certain amount of protection can also be assumed. So the real vulnerable point is the air interface.

In another use case, the user might not be satisfied with the above level of protection but desire true end-to-end security. While you are correct that in the internet intermediates might spoil this, the IMS is a controlled environment and specificatotions define that intermediates shall pass the media transparentley. For instance, such a call would not be interworked with the PSTN. So true end-to-end security can be guaranteed to a requesting user within the IMS. The drawback is that call setup for end-to-end media security will frequentleq fail, as many peers will not support this.

> 
> > 
> > Second, in response to your statement "The requirement in 3GPP is, 
> > that the UE has to know whether or not the network
> > (P-CSCF) will support SDES-SRTP before the session takes place, if 
> > it wants to employ End2AccessEdge media plane security. This will 
> > ensure that the IMS UE shares the media keys only with the P-CSCF 
> > and not with some other entity." I asked the question:
> > 
> > "That would be interesting to know, but it is a more general problem 
> > - any B2BUA can terminate SRTP, and SIP does not provide any 
> > mechanism to indicate whether SRTP is truly end-to-end or just 
> > end-to-some-B2BUA. Also a gateway to TDM will terminate SRTP, and 
> > SIP does not provide any means of indicating whether SRTP is truly 
> > end-to-end or end-to-first-TDM-gateway."
> 
> [PETER] IF the UE knows that the network supports SDES-SRTP (i.e. 
> P-CSCF in collaboration with Access-Gateway), then this can be taken 
> into account when deciding whether or not to ask for SRTP. In the end 
> this has an effect on how fast the session setup will be, as the UE 
> can avoid unsuccessfuall session setups. As there are two distinct use 
> cases, namely end2end and end2accessedge, there is a requirement in a 
> 3GPP environment to let the UE (user) know what level of security has 
> been applied to the media.

[Thomas] This is debatable from the requirements perspective. 3GPP was of the opinion that a call for which end-to-end security was requested should only succeed with true end-to-end security, or otherwise fail to indicate to the user that this security is not availbale. It is then the users´s choice to set up an unprotected call or not to communicate.

> 
> > 
> > In addition, I am curious to know whether the proposed mechanism 
> > will work when there is a proxy between the UA and the P-CSCF, e.g., 
> > a proxy/B2BUA in an enterprise or residential network. Is there a 
> > danger that the proxy/B2BUA will apply end2AccessEdge security 
> > (between the UA and itself), leaving the hop between proxy/B2BUA and 
> > the P-CSCF unprotected? The so-called requirement of the UA to 
> > provide security on the first hop is fulfilled, but the critical hop 
> P-CSCF. I guess that for enterprise/residential cases this would work 
> as well, as the "UA" in that case is the PBX/residential gateway 

> > 
> > There have been extensive discussions on the DISPATCH and the former 
> > SIP lists over the last couple of years or more about authenticated 
> > identity and how that can be used to give some guarantee to the user 
> > as to where secure media terminates, without any resolution. A 
> > solution that just guarantees security on a first hop does not 
> > really take us further forward. As Hadriel pointed out, there is the 
> > SDP capability negotiation solution, as well as other solutions 
> > proposed
> in the past.
> 

[Thomas] As explained above, the IMS security aims to do better than that for end-to-end security and provide protection for the most vulnerable point with end-to-access-edge encryption.

For end-to-access edge protection, architectural considerations also played a role: only the P-CSCF and controlled BGW need to be updated, not all the entities handling the user plane. This is shurly an argument primarily from an operator´s perspective, but are such arguments forbidden in IETF?

> > > solutions based on SDES are required, namely end2end and 
> > > end2accessedge media protection. The need for two modes based on 
> > > SDES SRTP is reflected throughout the specification where in every 
> > > clause you find a sub-clause for end2end and a sub-clasue 
> > > end2accessedge. Clause 7 provides the registration and session 
> > > setup procedures, again different
> > for end2end
> > > and end2access edge.
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 May 2010 14:37:05 +0200

Thomas,

> From: Belling, Thomas (NSN - DE/Munich)
> [mailto:[email-masked]]
> Sent: 26 May 2010 12:50
> To: Elwell, John; Leis, Peter (NSN - DE/Munich); ext Hadriel
> Kaplan; Dawes, Peter, VF-Group; [email-masked]
> [mailto:[email-masked]] On Behalf Of ext Elwell, John
> specifications to
> outside this
> You appear to be asking for a solution whereby the UE can ask
> for single hop SRTP (just to the P-CSCF) and have it refused
> if the P-CSCF is unable to provide it, rather than allowing
> an entity beyond the P-CSCF to terminate SRTP. This I do not
> understand. Why would the UE __want__ to have security only
> on that hop and not be prepared to have security beyond that
> hop? As far as I can see, the UE would just want to ask for
> SRTP and would prefer to have SRTP end-to-end but might
> accept something less than end-to-end.
>
> [Thomas] In my understnading there is a considerable user
> benefit in having some encryption for every call,
> irrespective of the capabilities of the peer (All 3GPP UEs
> prior to Rel-9 will not support SRTP media plane security,
> and in Rel-9 this is an optional feature). Consider an
> unsecured WLAN air interface as an important use case (3GPP
> air interfaces would offer encryption at a lower layer). 3GPP
> focused on the IMS scenario, where the operator is likely to
> use a walled garden and protect media streams in that manner.
> A call is likely to either go to a PSTN or some other IMS
> peer, where a certain amount of protection can also be
> assumed. So the real vulnerable point is the air interface.
[JRE] I am not disputing that, but the vulnerable air interface can exist at both ends, and securing one end without knowing whether the other end is secured does not give much assurance to the user.

>
> In another use case, the user might not be satisfied with the
> above level of protection but desire true end-to-end
> security. While you are correct that in the internet
> intermediates might spoil this, the IMS is a controlled
> environment and specificatotions define that intermediates
> shall pass the media transparentley. For instance, such a
> call would not be interworked with the PSTN. So true
> end-to-end security can be guaranteed to a requesting user
> within the IMS. The drawback is that call setup for
> end-to-end media security will frequentleq fail, as many
> peers will not support this.
>
> >
> > >
> 3GPP is,
> place, if
> [JRE]The UE could just ask for best effort SRTP - if it is
> supported by the "far end" (whether this be the P-CSCF or
> something beyond), SRTP will be used, if not RTP will be
> used. We have a solution for that already.
>
> [Thomas] This is debatable from the requirements perspective.
> 3GPP was of the opinion that a call for which end-to-end
> security was requested should only succeed with true
> end-to-end security, or otherwise fail to indicate to the
> user that this security is not availbale. It is then the
> users´s choice to set up an unprotected call or not to communicate.
[JRE] If the UA just wants SRTP or nothing (rejected call), it can ask for that at present. The P-CSCF could forward the offer and hope that the far end can accept SRTP, and if the far end rejects SRTP the P-CSCF could intervene and accept SRTP. The only thing missing then is some indication to the calling UA as to how far media is encrypted. But as I said earlier, this is a more general problem. It would be good in general to have secure identification of the entity that terminates SRTP, so that the user can assess how secure the call really is.

> [JRE] The proxy/B2BUA acting as PBX might not handle media.
> Media (and hence media security) will come from the UA behind
> the PBX, whereas signalling security will come from the PBX.
> The PBX in this case is not in a position to negotiate media
> security - that is just passed on from the UA behind the PBX.
> It seems to me that trying to add media security to RFC 3329
> violates this architectural distinction between the
> hop-by-hop nature of signalling and the end-to-end nature of
> media. I agree that if you put in a device such as a Session
> Border Controller (SBC) between the PBX and the IMS network
> the proposed solution might work, but we should not force the
> presence of an SBC here.
>
> > >
> [JRE] This does not answer my concern. I am not disputing
> that security is required. However, we already have a
> solution for best effort SRTP. The existing solution is not
> ideal, since it doesn't tell me how far media is secured,
> only that it is secured at least part of the way to the
> remote endpoint. What the draft seems to be asking for is a
> solution that specifically limits SRTP to a single hop, and I
> dispute the need and the architectural viability of that.
>
> [Thomas] As explained above, the IMS security aims to do
> better than that for end-to-end security and provide
> protection for the most vulnerable point with
> end-to-access-edge encryption.
>
> For end-to-access edge protection, architectural
> considerations also played a role: only the P-CSCF and
> controlled BGW need to be updated, not all the entities
> handling the user plane. This is shurly an argument primarily
> from an operator´s perspective, but are such arguments
> forbidden in IETF?
[JRE] I don't dispute that. I was commenting on an earlier statement (from Peter I think) that suggested it would be the UE's wish to have media security only as far as the edge, and I did not buy that argument.

You did not comment on my architectural concern about the single-hop nature of RFC 3329 versus the end-to-end nature of media, and how that would work in certain PBX environments when attaching to IMS. So notwithstanding our slight differences of opinion concerning the requirements, I still have this architectural concern. Any shortcomings relating to the negotiation of media security should, in my opinion, be handled in SDP.

John

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 May 2010 18:23:08 +0200

Firstly lets remove some of the discussion about end-to-end.

If the user wants end-to-end security, then a mechanism (in fact two currently) is provided for that, and end-to-access-edge will not be invoked for any media where the user requests that. I do not really see a use case for providing fallback to end-to-end security where end-to-access-edge is not provided. To me the use cases are different and distinct. I am also not sure what keys would end up being used if this occurred.

Thus, it is intended that user user knows at the time of registration as to whether end-to-access-edge security is available, and therefore at the point of sending an INVITE, the user's UA (or the user themselves) can determine which one they want to use.

My understanding of the use case for the end-to-access-edge security is that it is to protect to hop on which absolutely no security might exist at all. So on 3G, all data is protected to a certain extent, and then the IMS signalling is protected a stage beyond that. Hoever on other access technologies, there would not be this underlying level of protection for the data, and therefore it becomes a matter for the user to use end-to-access-edge security to replace that deficiency for all the media paths passing over that access technology.

So in the question you raise about the attached proxy/gateway, e.g. an attached PBX, and how that would work, for this use case the importance is only on the local hop, and therefore if the proxy/gateway wanted to use the capability, then it would do the same as the P-CSCF in the reverse direction. I must admit we haven't worked through the implications of doing that on the call request itself. And none of this would prevent the PBX end user using end-to-end security with the remote users.

regards

Keith

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Wednesday, May 26, 2010 1:37 PM
> To: Belling, Thomas (NSN - DE/Munich); Leis, Peter (NSN -
> DE/Munich); ext Hadriel Kaplan; Dawes, Peter, VF-Group;
> [email-masked]
> > To: Elwell, John; Leis, Peter (NSN - DE/Munich); ext
> Hadriel Kaplan;
> > Dawes, Peter, VF-Group; [email-masked]
> > [JRE] My question was not about network provider benefit,
> it was about
> > user benefit, or UE benefit.
> > You appear to be asking for a solution whereby the UE can ask for
> > single hop SRTP (just to the P-CSCF) and have it refused if
> the P-CSCF
> > is unable to provide it, rather than allowing an entity beyond the
> > P-CSCF to terminate SRTP. This I do not understand. Why
> would the UE
> > __want__ to have security only on that hop and not be
> prepared to have
> > security beyond that hop? As far as I can see, the UE would
> just want
> > to ask for SRTP and would prefer to have SRTP end-to-end but might
> benefit in
> > having some encryption for every call, irrespective of the
> > capabilities of the peer (All 3GPP UEs prior to Rel-9 will
> not support
> > SRTP media plane security, and in Rel-9 this is an optional
> feature).
> > Consider an unsecured WLAN air interface as an important use case
> > (3GPP air interfaces would offer encryption at a lower layer). 3GPP
> > focused on the IMS scenario, where the operator is likely to use a
> > walled garden and protect media streams in that manner.
> peer, where
> > a certain amount of protection can also be assumed. So the real
> > vulnerable point is the air interface.
> [JRE] I am not disputing that, but the vulnerable air
> interface can exist at both ends, and securing one end
> without knowing whether the other end is secured does not
> give much assurance to the user.
>
> >
> > In another use case, the user might not be satisfied with the above
> > level of protection but desire true end-to-end security.
> While you are
> > correct that in the internet intermediates might spoil
> this, the IMS
> > is a controlled environment and specificatotions define that
> > intermediates shall pass the media transparentley. For
> instance, such
> > a call would not be interworked with the PSTN. So true end-to-end
> > security can be guaranteed to a requesting user within the IMS. The
> > drawback is that call setup for end-to-end media security will
> > frequentleq fail, as many peers will not support this.
> >
> > >
> > > >
> supported
> > by the "far end" (whether this be the P-CSCF or something beyond),
> > SRTP will be used, if not RTP will be used. We have a solution for
> > that already.
> >
> security was
> > requested should only succeed with true end-to-end security, or
> > otherwise fail to indicate to the user that this security is not
> > availbale. It is then the users´s choice to set up an
> unprotected call
> > or not to communicate.
> [JRE] If the UA just wants SRTP or nothing (rejected call),
> it can ask for that at present. The P-CSCF could forward the
> offer and hope that the far end can accept SRTP, and if the
> far end rejects SRTP the P-CSCF could intervene and accept
> SRTP. The only thing missing then is some indication to the
> calling UA as to how far media is encrypted. But as I said
> earlier, this is a more general problem. It would be good in
> general to have secure identification of the entity that
> terminates SRTP, so that the user can assess how secure the
> call really is.
>
> >
> > >
> > > >
> mechanism
> > Media (and hence media security) will come from the UA
> behind the PBX,
> > whereas signalling security will come from the PBX.
> > The PBX in this case is not in a position to negotiate
> media security
> > - that is just passed on from the UA behind the PBX.
> > It seems to me that trying to add media security to RFC
> 3329 violates
> > this architectural distinction between the hop-by-hop nature of
> > signalling and the end-to-end nature of media. I agree that
> if you put
> > in a device such as a Session Border Controller (SBC)
> between the PBX
> > and the IMS network the proposed solution might work, but we should
> > not force the presence of an SBC here.
> >
> > > >
> > [JRE] This does not answer my concern. I am not disputing that
> > security is required. However, we already have a solution for best
> > effort SRTP. The existing solution is not ideal, since it
> doesn't tell
> > me how far media is secured, only that it is secured at
> least part of
> > the way to the remote endpoint. What the draft seems to be
> asking for
> > is a solution that specifically limits SRTP to a single hop, and I
> better than
> > that for end-to-end security and provide protection for the most
> > vulnerable point with end-to-access-edge encryption.
> >
> considerations also
> > played a role: only the P-CSCF and controlled BGW need to
> be updated,
> > not all the entities handling the user plane. This is shurly an
> > argument primarily from an operator´s perspective, but are such
> > arguments forbidden in IETF?
> [JRE] I don't dispute that. I was commenting on an earlier
> statement (from Peter I think) that suggested it would be the
> UE's wish to have media security only as far as the edge, and
> I did not buy that argument.
>
> You did not comment on my architectural concern about the
> single-hop nature of RFC 3329 versus the end-to-end nature of
> media, and how that would work in certain PBX environments
> when attaching to IMS. So notwithstanding our slight
> differences of opinion concerning the requirements, I still
> have this architectural concern. Any shortcomings relating to
> the negotiation of media security should, in my opinion, be
> handled in SDP.
>
> John
>
> >
> >
> >
> > >
> > > >
> > > > John
> > > >
> > > >

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 May 2010 18:54:47 +0200

Keith,

The point is, the PBX would know from the security agreement that e2ae security is available at the P-CSCF. However, a UA behind the PBX, when it initiates a call, a) does not know whether it will be routed to an IMS network, and b) does not know details of the security agreement between the PBX and the P-CSCF. So it may or may not request e2e security, and if it does request e2e security and that fails, I don't see how it can request e2ea security (between the PBX and the P-CSCF). If somebody could explain this, it would help.

John

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: 26 May 2010 17:23
> To: Elwell, John; Dawes, Peter, VF-Group; [email-masked]
> If the user wants end-to-end security, then a mechanism (in
> fact two currently) is provided for that, and
> end-to-access-edge will not be invoked for any media where
> the user requests that. I do not really see a use case for
> providing fallback to end-to-end security where
> end-to-access-edge is not provided. To me the use cases are
> different and distinct. I am also not sure what keys would
> end up being used if this occurred.
>
> Thus, it is intended that user user knows at the time of
> registration as to whether end-to-access-edge security is
> available, and therefore at the point of sending an INVITE,
> the user's UA (or the user themselves) can determine which
> one they want to use.
>
> My understanding of the use case for the end-to-access-edge
> security is that it is to protect to hop on which absolutely
> no security might exist at all. So on 3G, all data is
> protected to a certain extent, and then the IMS signalling is
> protected a stage beyond that. Hoever on other access
> technologies, there would not be this underlying level of
> protection for the data, and therefore it becomes a matter
> for the user to use end-to-access-edge security to replace
> that deficiency for all the media paths passing over that
> access technology.
>
> So in the question you raise about the attached
> proxy/gateway, e.g. an attached PBX, and how that would work,
> for this use case the importance is only on the local hop,
> and therefore if the proxy/gateway wanted to use the
> capability, then it would do the same as the P-CSCF in the
> reverse direction. I must admit we haven't worked through the
> implications of doing that on the call request itself. And
> none of this would prevent the PBX end user using end-to-end
> security with the remote users.
>
> regards
>
> Keith
>
>
>
>
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 26 May 2010 19:35:59 +0200

If it wants end-to-end security and that fails, then end-to-access-edge security will not form an acceptable substitute.

In the case of an attached PBX, it would be the policy of the PBX that would determine the need to use end-to-access-edge security for all its individual users, or not. I do not see the end user forming part of this decision process, or indeed needing to. The only case where that would get overridden is where the end user requests end-to-end security and gets it, on a per SDP offer / answer basis.

Keith

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, May 26, 2010 5:55 PM
> To: DRAGE, Keith (Keith); Dawes, Peter, VF-Group; [email-masked]
> The point is, the PBX would know from the security agreement
> that e2ae security is available at the P-CSCF. However, a UA
> behind the PBX, when it initiates a call, a) does not know
> whether it will be routed to an IMS network, and b) does not
> know details of the security agreement between the PBX and
> the P-CSCF. So it may or may not request e2e security, and if
> it does request e2e security and that fails, I don't see how
> it can request e2ea security (between the PBX and the
> P-CSCF). If somebody could explain this, it would help.
>
> John
>
> fact two
> > currently) is provided for that, and end-to-access-edge will not be
> > invoked for any media where the user requests that. I do not really
> > see a use case for providing fallback to end-to-end security where
> different
> > and distinct. I am also not sure what keys would end up
> being used if
> > this occurred.
> >
> registration
> > as to whether end-to-access-edge security is available, and
> therefore
> > at the point of sending an INVITE, the user's UA (or the user
> > themselves) can determine which one they want to use.
> >
> security
> > is that it is to protect to hop on which absolutely no
> security might
> > exist at all. So on 3G, all data is protected to a certain
> extent, and
> > then the IMS signalling is protected a stage beyond that. Hoever on
> > other access technologies, there would not be this
> underlying level of
> > protection for the data, and therefore it becomes a matter for the
> > user to use end-to-access-edge security to replace that
> deficiency for
> > all the media paths passing over that access technology.
> >
> proxy/gateway, e.g. an
> > attached PBX, and how that would work, for this use case the
> > importance is only on the local hop, and therefore if the
> > proxy/gateway wanted to use the capability, then it would
> do the same
> > as the P-CSCF in the reverse direction. I must admit we
> haven't worked
> > through the implications of doing that on the call request
> itself. And
> > none of this would prevent the PBX end user using
> end-to-end security
> > with the remote users.
> >
> > regards
> >
> > Keith
> >
> >
> >
> >
> >
> interface can
> > > exist at both ends, and securing one end without knowing
> whether the
> > > other end is secured does not give much assurance to the user.
> > >
> > > >
> > > [JRE] If the UA just wants SRTP or nothing (rejected
> call), it can
> > > ask for that at present. The P-CSCF could forward the
> offer and hope
> > > that the far end can accept SRTP, and if the far end rejects SRTP
> > > the P-CSCF could intervene and accept SRTP. The only
> thing missing
> > > then is some indication to the calling UA as to how far media is
> > > encrypted. But as I said earlier, this is a more general
> problem. It
> > > would be good in general to have secure identification of
> the entity
> > > that terminates SRTP, so that the user can assess how secure the
> > > call really is.
> > >
> > > >
> > > > >
> > > > > >
> > > [JRE] I don't dispute that. I was commenting on an
> earlier statement
> > > (from Peter I think) that suggested it would be the UE's wish to
> > > have media security only as far as the edge, and I did
> not buy that
> > > argument.
> > >
> single-hop
> > > nature of RFC 3329 versus the end-to-end nature of media, and how
> > > that would work in certain PBX environments when
> attaching to IMS.
> > > So notwithstanding our slight differences of opinion
> concerning the
> > > requirements, I still have this architectural concern. Any
> > > shortcomings relating to the negotiation of media
> security should,
> > > in my opinion, be handled in SDP.
> > >
> > > John
> > >
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > John
> > > > > >
> > > > > >
> > > > > > > stage-2 specification for the feature "media
> plane security"
> > > > > > > and as such