Subject: RE: [Sip-security] A minimalist security framework for SIP

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 26 Nov 2001 00:26:40 -0500

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Sunday, November 25, 2001 11:12 PM
> To: Charles Kalmanek
> Cc: [email-masked]
> Subject: Re: [Sip-security] A minimalist security framework for SIP
> 
> 
> 
> > When RTP translators are present, it seems that they are an endpoint
> > either of the IPsec SA or the SRTP session.  Is there a major
> > difference?
> 
> Not that I can tell, but others have pointed out more important
> differences.
> 
> > Exactly.  We have been trying to determine under what scenarios
> > digest+enhancements might be acceptable.  I'm not sure there are
> > many.
> 
> I think it remains a good low-cost solution for e2e authentication
> (where IPsec and TLS wouldn't do), in particular REGISTER and 
> SUBSCRIBE,
> but also INVITE. IPsec and TLS have costs, as discussed 
> earlier, both in
> terms of implementation complexity and delay.

Its not clear to me that shared secrets will exist end-to-end often enough
to be really useful, especially in the case of interdomain operation. In
that case, the big question is whether we need the enhance digest stuff for
user<->proxy; TLS/IPSec would be easier to specify and meet all the security
needs. I think the latency is a non-issue for persistent connections, the
real issue is the cost of maintaing an extremely large number of such open
connections. I still don't feel anyone has provided any concrete data on
that.

For the e2e case, I think the only workable models are (1) some kind of
transitive trust situation, as has been discussed already, (2) some
mechanism for automatically establishing a shared secret after the first
call. This would be similar to the SSH model - you could ensure that someone
who calls again is the same person that called last time. That works well
for INVITE, but its not clear its useful for SUBSCRIBE.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 26 Nov 2001 09:08:33 -0500

> to be really useful, especially in the case of interdomain operation. In

Agreed; that's why I emphasized REGISTER and SUBSCRIBE, which are more
likely to go to the home domain. (SUBSCRIBE for various SIP-related
events, not buddy lists.)

> user<->proxy; TLS/IPSec would be easier to specify and meet all the security

I think this is mainly an issue of complexity. TLS is non-trivial for
embedded systems and for IPsec, I wouldn't want to foist IKE on anybody,
let alone embedded systems. Maybe son-of-IKE / JFK make this a more
viable proposition.

> connections. I still don't feel anyone has provided any concrete data on

Agreed; hopefully, we'll have our TLS implementation running by year's
end and should be able to do those experiments across our range of
platforms (Linux, WinNT, Solaris, Tru64, FreeBSD).

> for INVITE, but its not clear its useful for SUBSCRIBE.

The problem is that active MIM attacks require externally signed
certificates, not just D-H. Thus, you still need a client-level PK
infrastructure.

---

From: "C. R. Kalmanek" <[email-masked]>
Date: Mon, 26 Nov 2001 13:19:03 -0500

Comments inline.

> let alone embedded systems. Maybe son-of-IKE / JFK make this a more

IPsec doesn't imply IKE.  You can use pre-shared keys, Kerberos,
Passport
(which is/will be Kerberos), IKE, JFK...

> certificates, not just D-H. Thus, you still need a client-level PK

You don't necessarily need PKI, which is complex and I may not live
long enough.  As Jonathan says, transitive trust works.  Kerberos
works.  Or, I can provision public keys without getting into the 
complexity of certs, cert revocation, etc.