Subject: [Sip] RFC 4474 and SBC traversal

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 09:19:21 +0100

SBCs do exist, often for good reasons that Hadriel has expanded on
already. I firmly believe that DTLS-SRTP will not be deployable in a
meaningful way without addressing this problem. Concerning solutions, we
have drafts from Kai and Dan, or perhaps a merger of the two somehow
would work. It also depends to some extent whether we are talking only
about email-style URIs or about E.164-based URIs too.

John
_______________________________________________
Sip mailing list  https://www.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: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 11:50:53 +0300

This issue is totally independent from E.164

I don't like the idea of requiring DTLS-SRTP to provide proof of 
possession of the keying material.

Ciao
Hannes

---

From: "Fischer, Kai" <[email-masked]>
Date: Fri, 4 Apr 2008 11:19:11 +0200

> This issue is totally independent from E.164

Not fully. SBCs may exchange the domain part of the E.164 SIP URI, which
causes a break of the RFC 4474 signature. With email-style URIs a simple
exchange is not possible.

> possession of the keying material.

It is also the other way round. If you use DTLS-SRTP to encrypt RTP, the
terminating domain is interested where the call originates from and in
which domain the SRTP connection is terminated. DTLS-SRTP is not
initially used as mean to establish an identity rather than as the
initial aim to encrypt RTP.

Kai

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 12:24:15 +0300

Hi Kai,

> exchange is not possible.
This is true but this applies to SIP Identity in general and not to 
E.164 number usage with SIP Identity only.
Hence, I would not tie it to this discussion.

> initial aim to encrypt RTP.

I understand the need to know who the end points are. However, tying 
DTLS-SRTP is not a good idea since it
a) increases the liklihood that SIP identity never get's deployed (since 
it is suddently far more complex than before)
b) SIP identity is used also as a identity mechanism in areas where no 
media is exchanged.

Ciao
Hannes

>>> meaningful way without addressing this problem. Concerning 
>>>       
>> solutions, we
>>     
>>> would work. It also depends to some extent whether we are 
>>>       
>> talking only
>>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 04 Apr 2008 10:05:20 +0100

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 04 April 2008 09:51
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] RFC 4474 and SBC traversal
> 
[JRE] Agreed.

> possession of the keying material.
[JRE] I don't understand. Are you saying you don't want to couple
DTLS-SRTP with RFC 4474 or similar?

John

---

From: "Fischer, Kai" <[email-masked]>
Date: Fri, 4 Apr 2008 11:46:50 +0200

> Hence, I would not tie it to this discussion.

My point was, that with E.164 an intermediary SBC is able to exchange
the domain part without a possibility on the terminating side to
recognize the change. With email-like SIP URIs the domain change is not
possible or only with a hack. Two cases need to be differentiated:
-SBC modifies SDP: This results in a necessity to create a new SIP
Identity signature and a change of the domain part in the From header
(valid for both types of SIP URIs email and E.164)
-SBC modifies From header field only: This is applicable to E.164 only
and as far as I have recognized from the past discussions a real world
behavior

> b) SIP identity is used also as a identity mechanism in areas 

Do you propose to not apply RFC 4474 for DTLS-SRTP fingerprint
protection and to rely on something different?

Kai

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 04 Apr 2008 22:51:20 +0300

Hi Kai,

Fischer, Kai wrote:
>>> Not fully. SBCs may exchange the domain part of the E.164 
>>>       
>> SIP URI, which
>>     
>>> causes a break of the RFC 4474 signature. With email-style 
>>>       
>> URIs a simple
>>     
> recognize the change.
>  With email-like SIP URIs the domain change is not
> possible or only with a hack.

I see what you mean.

The issue is that John, in one of his other mails, wants to add this 
relationship between the E.164 number and the corresponding domain. If 
you do not create this relationship then there are attacks possible and 
SIP Identity is just not the right mechanism since there is a domain 
that asserts certain properties and they just don't exist in this 
specific case. Bad luck.

>  Two cases need to be differentiated:

But in general there was the claim that SIP Identity does not work to 
well with SBCs. Dan wrote a draft about it.

>>> It is also the other way round. If you use DTLS-SRTP to 
>>>       
>> encrypt RTP, the
>>     
>>> terminating domain is interested where the call originates 
>>>       
>> from and in
>>     

SIP Identity works nice in certain environments. The fields that are 
covered by the digital signature calculation in SIP Identity have not 
been chosen arbitrarily. When an SBC changes some of the protected 
fields then there are obviously problems.

Imagine a mechanism that wouldn't compute a signature at all then SBCs 
could do whatever they want.
Good for SBCs; not so good for security.

Ciao
Hannes

>>>>> already. I firmly believe that DTLS-SRTP will not be 
>>>>>           
>> deployable in a
>>     
>>>>> have drafts from Kai and Dan, or perhaps a merger of the 
>>>>>           
>> two somehow
>>     
>>>>> Use [email-masked] for new developments on the 
>>>>>           
>> application of sip
>>     
>>>>>   
>>>>>       
>>>>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 4 Apr 2008 16:11:01 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hannes Tschofenig
>

Actually, I think some of the fields chosen for signing did NOT need to be signed, and added nothing tangible; or if they did, the result of it making it unusable in many environments was not worth the specific security issue(s) they prevented. (specifically I am talking about the Contact, CSeq, and Call-Id)

There are plenty of valuable SIP Requests which SBCs don't change bodies/From/To of that could use 4474 as is today, if it did not sign those 3 fields.  For example a MESSAGE request (which does not even have a Contact, but would fail the Call-Id changing).  Or a SUBSCRIBE.  Or an INFO. :)

> Good for SBCs; not so good for security.

Depends on how you define secure, at what layer, and most importantly for whom, but we don't need to get into that on this list. :)

-hadriel

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 6 Apr 2008 15:11:39 +0200

This thread was split out by John so it was a separate thread from the
E164 discussion.

RFC 4474 is a SIP document.

It is appropriate for the SIP WG to discuss perceived issues with a SIP
WG publication.

Regards

Keith 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hannes Tschofenig
> Sent: Friday, April 04, 2008 10:24 AM
> To: Fischer, Kai
> Cc: [email-masked]; Elwell, John
> > Not fully. SBCs may exchange the domain part of the E.164 SIP URI, 
> > which causes a break of the RFC 4474 signature. With 
> email-style URIs 
> > a simple exchange is not possible.
> >   
> encrypt RTP, 
> > the terminating domain is interested where the call originates from 
> > and in which domain the SRTP connection is terminated. DTLS-SRTP is 
> > not initially used as mean to establish an identity rather 
> than as the 
> I understand the need to know who the end points are. 
> However, tying DTLS-SRTP is not a good idea since it
> a) increases the liklihood that SIP identity never get's 
> deployed (since it is suddently far more complex than before)
> b) SIP identity is used also as a identity mechanism in areas 
> where no media is exchanged.
> 
> Ciao
> Hannes
> 
> > Kai
> >
> >   
> >> Ciao
> >> Hannes
> >>
> >>
> >> Elwell, John wrote:
> >>     
> >>> 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
> >>>   
> >>>       
> >> 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
> >>
> >>     
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 07 Apr 2008 15:43:12 -0700

At Fri, 04 Apr 2008 11:50:53 +0300,
> possession of the keying material.

To be honest, I'm not even sure what this means. DTLS-SRTP inherently
provides a proof that the peer you're encrypting to has keying
material that matches whatever was in the fingerprint. That's
a distinct question from whether the fingerprint is cryptographically
bound to the message.

-Ekr

---

From: Dean Willis <[email-masked]>
Date: Tue, 8 Apr 2008 02:50:16 -0500

> a distinct question from whether the fingerprint is cryptographically

Right. The only dependency between DTLS-SRTP and RFC 4474 is integrity  
protection of the key's fingerprint, not the actual key itself. The  
fingerprint is shipped in the SDP, and the key is negotiated in the  
media channel itself using a partial-key combination approach (aka D-H).

The fingerprint is used to relate signaling to media. This works even  
without RFC 4474. What RFC 4474 does is reduce the opportunity for  
somebody on the signaling AND media paths to replace the key, and use  
this to tap the media flow without being noticed by endpoints. It is  
somewhat arguable as to how useful this integrity protection is.

Of course, given that the usual implementation of RFC 4474 is for the  
authentication service that puts in the RFC 4474 Identity header to be  
a proxy that's on the signaling path, this would make it fairly easy  
for that proxy to collude in tapping the call. But if RFC 4474 is used  
end-to-end with client keys, the it provides fairly comprehensive  
protection.

--
Dean