Subject: Re: [dispatch] TCP and SCTP connection reuse draft

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 01 Oct 2009 09:53:14 -0500

Cullen Jennings wrote:
> The security of this draft seems, uh, bad. It's so bad that I am having 
> a really hard time believing I actually am understanding it correctly. 
> Help me make sure that I have this right.
> 
> Cisco and ACME are part of the AT&T trust domain and get sip trunking 
> from AT&T. Cisco sends a via that has ACME on the alias to AT&T. There 
> is nothing AT&T can do to validate this. Now Cisco has hijacked all of 
> ACME's call. If the trust domain consisted of just one party, well I see 
> how this might be secure, sort of, but it seems to fall apart as the 
> trust domain expands.

Cullen: Two observations in trying to drill down to the problem
definition here.  First, I want to make sure that we are not
assuming the case of a virtual server sending requests on
different connections.  While this was solvable for the TLS
case, it is not for the TCP case.

Second, maybe I am not understanding the gist of what you
wrote above, but the connection reuse is between adjacent
nodes.  In your example above, ATT will reuse the Cisco
connection when requests from ACME need to go to Cisco and
reuse the Acme connection when requests from Cisco need
to go to Acme.  If my understanding is incorrect, can you
please amplify with a boxes and arrow diagram or something
along those lines?

Thank you,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 1 Oct 2009 20:02:54 -0700

So consider an case where the service provider proxy called sp.com has  
a rule that maps incoming phones call to +1 123 555-1xxx to enterprise  
A's proxy at a.com. If you resolve a.com in DNS you get an IP/port of  
1.2.3.4:5060. Now b.com wants to hijack all the calls of enterprise A.  
It sends an an message to sp.com over a TCP connection and sends it  
with an VIA something like

Via: SIP/2.0/TCP 1.2.3.4;branch=z9yadayada;alias

The next call comes into to the sp destined to the phone number +1 234  
555 1666. The SP maps this to a.com and does a DNS lookup on this and  
gets 1.2.3.4. It then looks in the alias table and sees that it  
already has an alias for this and sends the INVITE over the TCP  
connection that goes to b.com. It seems that reading the security  
section I get the idea that the things that stops this from happening  
is that b.com would have to be in the Spec(T) trust domain or else the  
alias parameter would be ignored. This seems like fairly week  
protection.

I also have questions about how this all works with SCTP which there  
are multiple IP addresses and the attacker starts changing them but  
that more complex case is probably not worth discussing if I am still  
confused about the simpler TCP case.

Seriously, I hope I am failing to understand how the security in the  
draft works.

On Oct 1, 2009, at 7:53 , Vijay K. Gurbani wrote:

> Cullen Jennings wrote:
>> The security of this draft seems, uh, bad. It's so bad that I am  
>> having a really hard time believing I actually am understanding it  
>> correctly. Help me make sure that I have this right.
>> Cisco and ACME are part of the AT&T trust domain and get sip  
>> trunking from AT&T. Cisco sends a via that has ACME on the alias to  
>> AT&T. There is nothing AT&T can do to validate this. Now Cisco has  
>> hijacked all of ACME's call. If the trust domain consisted of just  
>> one party, well I see how this might be secure, sort of, but it  
>> seems to fall apart as the trust domain expands.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 02 Oct 2009 09:20:16 -0500

Cullen Jennings wrote:
> So consider an case where the service provider proxy called sp.com has a 
> rule that maps incoming phones call to +1 123 555-1xxx to enterprise A's 
[...]

Cullen: Yes, you are absolutely right in your example.

> It seems that reading the security section I get the idea 
> that the things that stops this from happening is that b.com would have 
> to be in the Spec(T) trust domain or else the alias parameter would be 
> ignored. This seems like fairly week protection.

We could possibly derive some heuristics like saving the DNS
name in the connection object as well, but the fact remains
that despite any heuristics, the primary security mechanism
is the tie-in to Spec(T).  It is weak and not enforceable
to a great degree, but I believe it is the only option.

Do you think the dependency on Spect(T) is not sufficient
to get the draft through the IESG?  What are our options if
that is indeed the case?

One option is to do nothing, but I think that is a
disservice to the community that is using TCP connection
reuse already.  Better to have some guidelines than none.

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Oct 2009 10:38:40 -0400

IIUC, the key to avoiding the hyjacking that Cullen points out is that 
the server must not accept the alias unless it can authenticate the 
request containing the alias as coming from something responsible for 
the address carried in the alias.

*How* that authentication is done can be defined in Spec(T), but the 
requirement to do it should be spelled out in the draft.

	Thanks,
	Paul

Vijay K. Gurbani wrote:
>> A's 
>> It seems that reading the security section I get the idea that the 
>> things that stops this from happening is that b.com would have to be 
>> in the Spec(T) trust domain or else the alias parameter would be

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 02 Oct 2009 16:50:56 -0500

> requirement to do it should be spelled out in the draft.

Paul: Thank you for shedding some light on the amorphous Spec(T).
So, procedurally speaking, what should we do to move this work
forward?

Note that the requirement of complying to Spec(T) is already
there in the draft (S6); what is unsure is how to specify
a Spec(T) that provides for this authentication?  Clearly
Digest cannot be used if the neighbors interested in doing
connection reuse are proxies.  Can we simply leave it at
saying that nodes in a Spec(T) for TCP connection reuse have
a policy to trust each other (and leave that policy unspecified)?

I hope I am making sense ...?

Thanks,

- vijay

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 03 Oct 2009 14:42:45 -0400

> I hope I am making sense ...?

I'm not a security expert. What I said was at the limit of my 
understanding of this. That whole Spec(T) thing has always been obscure 
to me.

I had in mind the use of digest. That would work if the neighbors are 
both UAs. (Unfortunately it seems this might be a common case, with SBCs 
talking to one another.) But if that is not the case, then it certainly 
isn't apparent to me what the answer would be.

Maybe Cullen to shed more light based on that observation. Or maybe it 
doesn't help at all.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 4 Oct 2009 02:01:01 +0200

>From what I remember Spec (T) doesn't quite work like that.

What Spec(T) essentially does is put down on paper the questions that need to be satisfactorily answered for your peer to determine whether you are trustworthy in regard to the identify or not. 

There is thus an element of "Do the answers to these questions match the level of authentication that I wish to have on identity within my own trust domain?". 

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: Friday, October 02, 2009 10:51 PM
> To: Paul Kyzivat
> Cc: [email-masked]; Jain, Rajnish; Hadriel Kaplan
> Subject: Re: [dispatch] TCP and SCTP connection reuse draft
> 
> Paul Kyzivat wrote:
> So, procedurally speaking, what should we do to move this 
> work forward?
> 
> there in the draft (S6); what is unsure is how to specify a 
> Spec(T) that provides for this authentication?  Clearly 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 
> Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 05 Oct 2009 16:02:59 -0500

> Maybe Cullen to shed more light based on that observation. Or maybe it 

Paul: Thanks for your help.  I have talked to Cullen
about this draft in the past, but clearly the security story
still needs more work.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 05 Oct 2009 16:06:14 -0500

DRAGE, Keith (Keith) wrote:
> What Spec(T) essentially does is put down on paper the questions that
> need to be satisfactorily answered for your peer to determine whether
> you are trustworthy in regard to the identify or not.

Keith: Thanks for your input.  So, the question is how strong
is this guarantee supposed to be?  Is it supposed to be
cryptographically strong? or is it something that can be very
elastic?

Thanks,

- vijay