Subject: Re: [Sip] A proposal for breaking the DTLS-SRTP vs RFC4474 gateway deadlock

From: Eric Rescorla <[email-masked]>
Date: Tue, 01 Jul 2008 19:32:58 -0700

At Tue, 24 Jun 2008 12:48:20 -0700,
Eric Rescorla wrote:
> 
> 
> Dean,
> 
> This sounds like an excellent way to proceed. I'll generate some candidate text
> and send it to the list in the next few days.

As promised, here's my proposed text:

   Because DTLS-SRTP uses RFC 4474 to bind the media keying material to
   the SIP signalling, the assurances about the provenance and security
   of the media are only as good as those for the signalling.  There are
   two important cases to note here:

   o  RFC 4474 assumes that the proxy with the certificate "example.com"
      controls the namespace "example.com".  Therefore the RFC 4474
      authentication service which is authoritative for a given
      namespace can control which user is assigned each name.  Thus, the
      authentication service can take an address formerly assigned to
      Alice and transfer it to Bob. This is an intentional design
      feature of RFC 4474 and a direct consequence of the SIP namespace
      architecture.
   o  When phone number URIs (e.g.,
      'sip:[email-masked]') are used, there is no
      structural reason to trust that the domain name is authoritative
      for a given phone number, although individual proxies and UAs may
      have private arrangements that allow them to trust other domains.
      This is a structural issue in that PSTN elements are trusted to
      assert their phone number correctly and that there is no real
      concept of a given entity being authoritative for some number
      space.

   In both of these cases, the assurances of DTLS-SRTP provides in
   terms of data origin integrity and confidentiality are necessarily
   no better than SIP provides for signalling integrity when RFC 4474
   is used. Implementors should therefore take care not to indicate
   misleading peer identity information in the user interface.
   e.g. If the peer's identity is
   sip:[email-masked], it is not sufficient to
   display that the identity of the peer is +17005551008. In cases
   where the UA can determine that the peer identity is clearly an
   E.164 number, it may be less confusing to simply identify the call
   as encrypted but to an unknown peer.

   In addition, some middleboxes (B2BUAs and Session Border
   Controllers) are known to modify portions of the SIP message which
   are included in the RFC 4474 signature computation, thus breaking
   the signature.  This sort of man-in-the-middle operation is
   precisely the sort of message modification that 4474 is intended to
   detect.  In cases where the middlebox is itself permitted to
   generate valid RFC 4474 signatures (e.g., it is within the same
   administrative domain as the RFC 4474 authentication service), then
   it may generate a new signature on the modified
   message. Alternately, the middlebox may be able to sign with some
   other identity that it is permitted to assert. Otherwise, the
   recipient cannot rely on the RFC 4474 Identity assertion, and the
   DTLS-SRTP call set up will fail or be marked as a call with an
   unknown peer.

-Ekr

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Tue, 1 Jul 2008 21:45:43 -0500

> As promised, here's my proposed text:

Seems close enough for now. One could say more, but why bother?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Jul 2008 07:54:26 -0400

>    as encrypted but to an unknown peer.

While I understand the logic above, it isn't very satisfying.
People are constructing sip based phone systems that must compete with 
traditional phone systems. If the sip based system shows no identity 
when a traditional system can display the identity of the same caller, 
then the sip system will be perceived and broken and non-competitive.

There will of course then be a temptation to do whatever is necessary 
to make the product competitive.

And displaying the full URL is often not a good alternative. At best it 
will be perceived as "geeky" and incomprehensible by grandma.

	Thanks,
	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Jul 2008 09:53:16 -0700

I think that seem to highlight all the problems so I can live with  
that if we can just get this done.

Cullen <with my individual contributor hat on>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Jul 2008 10:05:06 -0700

On Jul 2, 2008, at 4:54 AM, Paul Kyzivat wrote:

> People are constructing sip based phone systems that must compete  
> with traditional phone systems. If the sip based system shows no  
> identity when a traditional system can display the identity of the  
> same caller, then the sip system will be perceived and broken and  
> non-competitive.
>
> There will of course then be a temptation to do whatever is  
> necessary to make the product competitive.

What about changing

>> it may be less confusing to simply identify the call

to

it may be less confusing to simply identify the call as encrypted but  
to an unknown peer or to identify the call as insecure and show only  
the 17005551008 portion of the peers identity.

I'm not sure if that is better or worse but it seems to be one of the  
few way we have to address the issue Paul raised.

Cullen <in my individual contributor roll>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Jul 2008 13:18:31 -0400

Cullen Jennings wrote:

> it may be less confusing to simply identify the call as encrypted but to 
> an unknown peer or to identify the call as insecure and show only the 
> 17005551008 portion of the peers identity.
> 

If we had a way to indicate that the identity is untrusted in the 
display to the user, that might be acceptable.

BUT, we have a world full of devices that don't have an established way 
to indicate that. So when the call ends up going to one of them, there 
remains the choice of displaying the (untrusted) number with no 
disclaimers, or not displaying it.

The PSTN world has the same issue. Their choice has typically been to 
display it. That may have been justified once, when the phone network 
was relatively closed and those with the ability to forge their identity 
were few. Its no longer true, for a variety of reasons. And we are 
making it increasingly less true.

Perhaps we just have to accept the fact that entirely untrusted 
callerids will be displayed with no indication that they are suspect. 
But that then devalues doing anything secure, since the users won't be 
able to tell the difference.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 2 Jul 2008 11:43:09 -0700

> able to tell the difference.
True enough but consider that we are providing a service here far  
beyond anything the PSTN offers. My PSTN phone has no way of  
displaying if the caller id is secure or not - that is because the  
PSTN does not offer security caller-id in any sense of the why we are  
using secure here. The PSTN does not have a way of telling me no one  
is sitting outside my house with a but-set and listening to my call  
because the PSTN simply is not capable of offering that service.

We all know that it is trivial to spoof caller-id on the PSTN, and it  
is trivial to do on path "taps" to listen in on a POTS call. The user  
interface of POTS devices was not designed in any way to able to  
indicate that this a call was not "secure" in this way because it was  
never "secure" against these and more importantly, whatever level of  
"secure' it was, it was about the same for all calls so there was no  
need for an variant indication of level of security.  Now in SIP, we  
have some calls that are "secure" in this way and some that are not -  
we need some user interface to indicate that. I'm not surprised that  
the user interfaces designed for the PSTN are not capable of  
indicating this - I see no way around that.

So this leads us to why I think Dean's proposal is the right path  
forward. It gets us to go publish and complete the best approach we  
know how to deal with this problem now while clearly indicating the  
limitations of this approach when trying to use the PSTN or VoIP  
systems that closely emulate the PSTN in addressing architecture,  
transitive trust architectures, and user interfaces. I mostly agree  
with the points you are making, I just think that the ideal solution  
of security beyond what the PSTN was deigned for and 100% backwards  
compatibility with the PSTN is impossible and this approach is well  
worth publishing because it does provide real solutions for a  
significant number  of deployment models.

Cullen <in my individual contributor role>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 02 Jul 2008 15:29:48 -0400

inline:

> then the sip system will be perceived and broken and non-competitive.

Its not just a UI problem - the problem is that the identity really IS 
just +17005551008 - without the domain. I don't need the domain to dial 
it from a phone. So even if the UI could render a domain, I don't think 
it makes sense to do so.

That said, another possible approach here is to more loosely couple 
DTLS-SRTP to 4474. It is my understanding that what DTLS-SRTP needs is 
integrity of the signaling to protect the fingerprint from modification. 
Any mechanism which provides message integrity would do. RFC4474 is one 
way, but there are others. HBH TLS, for example, would also provide 
integrity services, though not against rogue servers. Of course, we 
don't have protection against rogue servers with 4474 either in cases 
where phone numbers are used...

So my suggestion is to have DTLS-SRTP just state that it requires some 
form of integrity services from signaling, to list some choices in what 
that can be. I think its also really important to point out that, even 
in the absence of any message integrity mechanisms at all, it requires 
an ACTIVE attack in order for a third party to eavesdrop or modify 
media. Whereas with sdescriptions, passive attacks can be launched if an 
attacker can observe the keying material at some point along the 
signaling path. That alone is a big improvement IMHO.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
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: Dean Willis <[email-masked]>
Date: Wed, 2 Jul 2008 14:47:54 -0500

On Jul 2, 2008, at 2:29 PM, Jonathan Rosenberg wrote:
>>
>
> Its not just a UI problem - the problem is that the identity really  
> IS just +17005551008 - without the domain. I don't need the domain  
> to dial it from a phone. So even if the UI could render a domain, I  
> don't think it makes sense to do so.

The domain of the E.164 is unimportant (or arguably non-existent).  
What are important are: 1) the identity of the SIGNER of the Identity  
header field, and 2) What kind of claims they are making about the  
strength of their identity assertion. RFC 4474 provides for #1, but  
allows for no differentiation in #2. So what I was hoping the  
disclaimer in DTLS-SRTP would do is provide that disclaimer, something  
like "Authentication servers may not be able to verify the orignator  
of a call received from the PSTN, but need to add an Identity header  
for DTLS-SRTP. Therefore, recipients of requests having RFC 4474  
Identity header fields used with DTLS-SRTP MUST NOT presume that the  
Identity header asserts anything about the originator of the call."

If we extended RFC 4474 to have "strength of assertion" indicators,  
then  we wouldn't have to have this warning.

> DTLS-SRTP to 4474. It is my understanding that what DTLS-SRTP needs  
> is integrity of the signaling to protect the fingerprint from  
> modification. Any mechanism which provides message integrity would  
> do. RFC4474 is one way, but there are others. HBH TLS, for example,  
> would also provide integrity services, though not against rogue  
> servers. Of course, we don't have protection against rogue servers  
> with 4474 either in cases where phone numbers are used...

True.  Dan and others have proposed alternative integrity techniques  
derived from RFC 4474.

> So my suggestion is to have DTLS-SRTP just state that it requires  
> some form of integrity services from signaling, to list some choices  
> in what that can be. I think its also really important to point out  
> that, even in the absence of any message integrity mechanisms at  
> all, it requires an ACTIVE attack in order for a third party to  
> eavesdrop or modify media. Whereas with sdescriptions, passive  
> attacks can be launched if an attacker can observe the keying  
> material at some point along the signaling path. That alone is a big  
> improvement IMHO.

It also requires that the integrity function be testably present by  
the UA. We don't want another "last hop exception", where the proxy in  
front of the UA provides the integrity check.

---

From: Dan York <[email-masked]>
Date: Mon, 7 Jul 2008 10:30:15 -0400

On Jul 2, 2008, at 1:18 PM, Paul Kyzivat wrote:

> BUT, we have a world full of devices that don't have an established  
> way to indicate that. So when the call ends up going to one of them,  
> there remains the choice of displaying the (untrusted) number with  
> no disclaimers, or not displaying it.
>
> The PSTN world has the same issue. Their choice has typically been  
> to display it. That may have been justified once, when the phone  
> network was relatively closed and those with the ability to forge  
> their identity were few. Its no longer true, for a variety of  
> reasons. And we are making it increasingly less true.
>
> callerids will be displayed with no indication that they are  
> suspect. But that then devalues doing anything secure, since the  
> users won't be able to tell the difference.

DY> Perhaps this is where we need the device manufacturers to step in  
and provide some UI indication that the identity *is* trusted.  If we  
think about the world of the web, people have gotten used to seeing  
that there is a "lock" icon or a changed address bar when they go to a  
"secure" website with the correct certificate.  We can argue about how  
many people actually check that icon or browser bar before doing their  
online ordering or banking, but nonetheless it is there.

DY> I don't know that there's any way you can go back and retrofit old  
devices to say something is *insecure* or *untrusted*, but it would  
seem that for *new* devices as they are built in the future and  
support the kinds of identity authentication discussed here it would  
be possible to have a UI indication of a *trusted* identity.  If one  
of the market leaders were to do this with their IP phones or  
softphones - and were to market this new capability, it might cause  
others in the market to follow.

DY>Of course, the user experience would be better if this was a common  
icon or symbol across vendors phones/user agents... and it gets  
increasingly complicated as we aren't only connecting "phones" but  
also other user agents, applications, servers, etc.  Still, it would  
seem that the logic would be rather simple "If the identity is  
trusted, display this symbol".  (A challenge, of course, is that many  
IP devices have limited display space, and there is the issue of  
perhaps also wanting a symbol to indicate that a call is *encrypted*.   
A call could be encrypted, have a trusted identity or be *both*  
encrypted and have a trusted identity.)

DY> It's not immediately clear to me that this is something that the  
IETF can tackle (vendor UIs), but it might be something that another  
industry organization like the SIP Forum could take on.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free