Subject: RE: [Sip] Bis-5: TLS as secure transport for SIP

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 3 Nov 2001 12:44:29 -0600

This is different from bis-04, yes. rfc2543bis-05 is an Internet-Draft, not
an RFC. A number of proposed changes to the SIP standard (largely those
proposing to resolve open issues) have been introduced in this draft in the
hopes of inciting list discussion and bringing these issues to consensus. I
don't think that list discussion and consensus is a prerequisite for the
release of an Internet-Draft.
 
The characterization of TLS as a transport protocol "like TCP and UDP"
derives first and foremost from the fact that 'tls' is a valid token that
can appear in the 'transport-param' parameter of a URL (as can 'udp', 'tcp'
or 'sctp') or 'sent-protocol' field of a Via header. SIP-over-TLS has an
assigned port (5061). It is assumed in the SIP standard (as it is elsewhere
in Internet standards) that TLS is running over TCP. The authors of bis are
aware that TLS does not run over UDP.
 
That much said, this should be clarified to prevent confusion, although I
think the characterization of TLS as a transport protocol (since it does
purport to add security to the transport layer) is not terribly misleading
in its context.
 
Jon Peterson
NeuStar, Inc

-----Original Message-----
From: Shieh, Hugh [mailto:[email-masked]]
Sent: Friday, November 02, 2001 4:20 PM
To: [email-masked]' <mailto:[email-masked]'> 
Subject: [Sip] Bis-5: TLS as secure transport for SIP

line: 2977. It was recommended that TLS as a secure transport for SIP. 

This is different from what's in bis04, has this been discussed and agreed
on the list? 

Since TLS relies on some reliable transport protocol (e.g., TCP) at lower
layer, TLS will not work directly on top of UDP.

I am also confused by the sentence in 2970-2973. TLS is NOT a transport
protocol like TCP or UDP, the primary goal of the TLS Protocol is to provide
privacy and data integrity for an underline reliable transport protocol like
TCP.

Regards, 

-Hugh

---

From: "Shieh, Hugh" <[email-masked]>
Date: Mon, 5 Nov 2001 10:21:28 -0800

See my comments inline.

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Saturday, November 03, 2001 10:44 AM
To: 'Shieh, Hugh'; [email-masked]'
Subject: RE: [Sip] Bis-5: TLS as secure transport for SIP

[Shieh, Hugh] I was not questioning the procedure of releasing an ID, just
trying to understand the reason behind the change. 

[Shieh, Hugh]  Will the authors of bis recommend a secure transport for UDP?
Or by recommending TLS, the authors recommend TCP instead of UDP as the
recommended SIP transport protocol?

Jon Peterson
NeuStar, Inc

-----Original Message-----
From: Shieh, Hugh [mailto:[email-masked]]
Sent: Friday, November 02, 2001 4:20 PM
To: [email-masked]' <mailto:[email-masked]'> 
Subject: [Sip] Bis-5: TLS as secure transport for SIP

Regards, 

-Hugh

---

From: "Shieh, Hugh" <[email-masked]>
Date: Mon, 5 Nov 2001 10:52:50 -0800

Mike,

I totally agree with you here. I would also like to know what should we
recommend for secure UDP transport since UDP has to be supported by all SIP
element at a minimum.  
Complexity of IKE does not mean the complexity of IPsec. There are other
ways to setup the security Association for IPsec. 3GPP is considering to
support IPsec in the terminal with a security mode setup other than IKE. 
It took quite a few years for IPsec to be considered generally mature, it
will take a few years for any new application level hop-by-hop protocol to
reach that mature status.

-Hugh

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Monday, November 05, 2001 9:43 AM
To: Peterson, Jon
Cc: 'Jari Arkko'; Shieh, Hugh; [email-masked]
Subject: RE: [Sip] Bis-5: TLS as secure transport for SIP

I frankly think that TLS is a non-starter since it
doesn't work with UDP. Henning disagrees, but I've
yet to hear what should be RECOMMENDED for UDP.
IPsec at least meets the UDP requirement, but
there seems to be a fair amount of concern that
it's too heavy weight. The other alternative is
doing something at application level for
hop-by-hop. Before we went there, I'd want to be
convinced that base transport mode IPsec minus key
distribution, tunnels, minimal crypto support etc,
is in fact significantly smaller than a customized
application layer crypto solution. While I'm
willing to believe the "smaller" part, I'm pretty
dubious about the "significant" part.

Also: KINK gives IPsec the ability to create SA's
in two messages (as opposed to 8-9 for IKE and,
what, 4-5 for TLS?) without *any* public key
cryptography. Manual keying is also possible,
and I'm sure that somebody is going to eventually
start keying up SA's with AAA (which I would be
a lot more receptive to if they actually
confronted the general problem rather than the
one-off hacks they're doing for, say, MIP).

	      Mike

Peterson, Jon writes:
 > The proposed RECOMMENDED for TLS is not without controversy - there are a
 > number of diverse architectures in which SIP will undoubtedly be
deployed,
 > and it is tough to say whether any recommendation should be made at all
 > since nothing will satisfy the requirements of every architecture. 
 > 
 > So why recommend TLS for SIP (as opposed to IPSec)? Three reasons come to
 > mind that, while they are necessarily somewhat general, apply to the most
 > common architectures in which TLS and IPSec are used:
 > 
 > - Because TLS secures just a single SIP connection. rfc2543bis should
 > provide a means of securing SIP that is independent of securing other
 > services or connections. In some architectures it would be a serious flaw
if
 > the security association that allows you to authenticate SIP messages
sent
 > to a proxy were also used to authenticate, say, telnet sessions to a
proxy -
 > but this is often desirable for architectures in which IPSec is used.
 > 
 > - Because use of TLS is reflected in the SIP protocol. The application
 > therefore has direct knowledge of the use of a secure transmission
 > mechanism, and uses this knowledge to populate the 'sent-protocol' in Via
 > headers or the 'transport-param' in various URI. In fact, an application
 > could even inspect the trail of Via headers to determine how many hops of
a
 > signaling chain went over TLS. In many IPSec VPN architectures,
 > authentication and encryption are performed outside the context of the
 > application (at an operating system level, or even on a separate network
 > host) - precluding any application-layer visibility into security
 > associations.
 > 
 > - Because a proxy server or user agent might not just want to know THAT a
 > message was authenticated, but WHAT identity that authentication proved.
 > Again, in many IPSec architectures when authentication is performed
outside
 > the context of the SIP application, the application has no way to gain
 > access to this identity. A proxy server or user agent may want to make
 > behavioral decisions based on policies that apply to the identity of
 > requestors. This isn't to say that TLS doesn't admit of architectures in
 > which streams are aggregated or the identity of the originating party is
not
 > passed to applications that want to view them for whatever reason, but it
 > seems easier for a TLS proxy to introduce some token into SIP signaling
 > identifying the originator of the request than it would be for, say, a
 > router implementing an IPSec VPN.
 > 
 > I understand why 3G mobile networks (which have something in common with
 > large VPNs) might want to use IPSec for security - it is perfectly valid
for
 > a great number of architectures. The reasons given above are necessarily
 > generalizations, and nothing in rfc2543bis05 is intended to discourage
the
 > use of IPSec when appropriate. Some parties working on the SIP standard
just
 > felt that SIP should have a 'story' about non-HTTP-based security that
went
 > beyond some hand-waving about lower layers taking care of it. Of course,
 > that's why it isn't a MUST, or even a SHOULD - just a RECOMMENDED.
 > 
 > I'd be interested to hear how others feel about the use of RECOMMENDED
for
 > TLS, or indeed the whole discussion of TLS and IPSec (given that the text
 > always could use some improvements and tweaking). Is it useful to have
any
 > recommendation here? Or even a discussion of these two popular
alternatives?
 > 
 > 
 > As for e2e security, there is now a mention in 20.3 of secure MIME types,
 > which are probably as close as we'll get to e2e signaling security. The
 > problem of header transparency in useful SIP architectures really
precludes
 > encrypting most of the headers - although secure MIME types might be able
to
 > assist this in some fashion.
 > 
 > Jon Peterson
 > NeuStar, Inc
 > 
 > > From: Jari Arkko [mailto:[email-masked]]
 > > Sent: Friday, November 02, 2001 11:07 PM
 > > To: Shieh, Hugh; [email-masked]
 > > Subject: Re: [Sip] Bis-5: TLS as secure transport for SIP
 > > 
 > > 
 > > [Sip] Bis-5: TLS as secure transport for SIP
 > > I have been wondering about this too, and have the same 
 > > questions as Hugh
 > > did. Furthermore, I have trouble understanding the trust 
 > > model explanations in
 > > lines 2967-2973. TLS and IPsec are both hop-by-hop models, so 
 > > they're both
 > > suited to environments where either one hop is sufficient 
 > > protection, or where
 > > you have some chain of trust. (One true difference the text 
 > > neglects to mention
 > > that TLS could be run in a one-sided manner with certs only 
 > > the server side and
 > > HTTP authentication to the other direction, which eases its 
 > > deployment in
 > > situations where you have a large number of clients towards a 
 > > small number of
 > > servers.)
 > > 
 > > Trouble is, I'm not very happy about either TLS or IPsec/IKE 
 > > on the client
 > > side, if we are talking about the wireless environment. 
 > > Delays, need to
 > > do public key cryptography, etc seem hard issues and I'm not sure we
 > > really need them.
 > > 
 > > As for the communication between servers and proxies there's 
 > > also a couple
 > > of hard requirements to handle. For instance, as [1 sec 6.24] 
 > > points out, there
 > > is a need to make it scalable to a large number of nodes. 
 > > IPsec generally
 > > can deal with this better given that it is typically placed 
 > > on security gateways,
 > > possibly hiding many proxies of an operator behind it. Plus, 
 > > you can tackle
 > > other important traffic within the same tunnels.
 > > 
 > > In the third generation mobile networks, IPsec is going to be used as
 > > a protection to get the network elements talk to each other securely.
 > > For the communication to the 3g terminals, I think we need something
 > > more lightweight than TLS or IPsec/IKE. Perhaps improved versions of
 > > HTTP Digest could do the job. How are we by the way progressing on 
 > > the Undery draft and other proposals in this direction? Are 
 > > they going to be
 > > integrated to RFC 2543 BIS or not?
 > > 
 > > Finally, I think all of this h2h is necessary but I wish we 
 > > could be making
 > > some progress in end-to-end security for SIP as well. I don't 
 > > always see
 > > myself trusting those proxy chains...
 > > 
 > > Jari
 > > [1] 
 > > http://www.ietf.org/internet-drafts/draft-garcia-sipping-3gpp-
 > reqs-00.txt
 > 
 > 
 > 
 > 
 > _______________________________________________
 > Sip mailing list  http://www1.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
 > 
 > _______________________________________________
 > Sip mailing list  http://www1.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: "Peterson, Jon" <[email-masked]>
Date: Mon, 5 Nov 2001 21:59:39 -0600

Well, I was speaking offhand about user agents inspecting Vias and so forth
- just to be clear this practice isn't suggested as a security procedure in
the SIP standard. For one thing, it isn't symmetrical - the initiator of a
request never gets to see those Vias. Also, the presence of a Via header
does not mandate how responses will be routed.

But that much said, any sort of hop-by-hop security across administrative
domains is based on transitivity of trust. If you want to take advantage of
SIP proxy servers for routing, you need to trust them (cryptographically).
You protect the headers of your message by sending them securely to a proxy
you trust, one that will be similarly responsible in relaying the message to
its peers. 

It isn't clear to me that, for example, signing each Via header would
provide much better Via security for this sort of concern than hop-by-hop
TLS. True, you get to evaluate each hop's credentials independently, but if
you assume untrustworthy hosts have access to credentials that you trust
(like the example below, in which an upstream proxy in the chain of trust is
malicious), then that may not make much of a difference in ensuring
integrity or confidentiality.

Jon Peterson
NeuStar, Inc

> Sent: Monday, November 05, 2001 10:45 AM
> To: Vesa Torvinen (LMF)
> Cc: 'Peterson, Jon'; 'Jari Arkko'; Shieh, Hugh; [email-masked]
> Vesa Torvinen (LMF) writes:
>  > I don't understand how a SIP entity can trust on Via or 
> various URI fields/parameters. For example, an untrustworthy 
> proxy could change these fields making a SIP entity 
> downstream believe that TLS was used for certain hops (and 
> change them back to original when the messages are delivered 
> back to upstream). Shouldn't you somehow protect all those 
> fields/parameter which you wanted to use to determine 
> anything about security? 
>  > 
>  > At least the protection of Via headers sounds a bit 
> complicated because they are added by every proxy... 
> 
>   You are correct. In order to protect via's, you need some
>   mechanism for each proxy to sign their via. Before we
>   went there though, I think that the real life threats
>   would need to be examine very carefully. I'm somewhat
>   doubtful that it's high on the threat list considering
>   that most SIP traffic is sent in the clear :-)
> 
> 	    Mike
>

---

From: "Shieh, Hugh" <[email-masked]>
Date: Mon, 5 Nov 2001 23:29:14 -0800

Would love to see Gonzalo's simulation result on call setup delay
distribution. However, by recommending TLS/TCP, does that mean that the
involved proxies have to be stateful (according to line: 2013)? In any case,
UDP is still (or is it?) mandated for all SIP elements, so a solution other
than TLS is still needed for UDP.

-Hugh

-----Original Message-----
From: Henning G. Schulzrinne [mailto:[email-masked]]
Sent: Monday, November 05, 2001 3:56 PM
To: Jonathan Rosenberg
Cc: 'Shieh, Hugh'; 'Peterson, Jon'; [email-masked]'
Subject: Re: [Sip] Bis-5: TLS as secure transport for SIP

Jonathan Rosenberg wrote:

> time, or on the first call, and then reused as needed. I am sure people
will
> dredge up the old HOL blocking issues with TCP. I still am waiting for

Gonzalo Camarillo has done a number of simulations on this here at
Columbia; he should summarize the details, but my summary is "you have
to try really, really hard for it to make a difference".

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Tuexen Michael <[email-masked]>
Date: Tue, 6 Nov 2001 13:55:28 +0100

Dear all,
there will be an update for the next IETF.
Best regards
Michael

Michael Tuexen    Tel.:   +49 89 722 47210
Siemens AG        Fax:    +49 89 722 48212
ICN WN CS SE 5    E-mail: [email-masked]

> From:	Allison Mankin [SMTP:[email-masked]]
> Sent:	Tuesday, November 06, 2001 12:49 AM
> To:	Jonathan Rosenberg
> Cc:	[email-masked]; [email-masked]; [email-masked]; [email-masked]
> > That said, TLS over SCTP would be another option, but is not specified 
> > as far as I know.
> 
> draft-tuexen-tsvwg-tls-over-sctp-00.txt
> 
> A chartered work item in TSVWG - new draft was expected...
> 
> ------
> 
> > 
> > In the case of secured interconnects between proxies that have some kind of
> > administratively agreed upon security relationship, I don't see a whole lot
> > of reason for UDP as opposed to TCP. The connections can be set up ahead of
> > time, or on the first call, and then reused as needed. I am sure people will
> > specific analysis on the impact on sip call set up time distributions. That
> > said, TLS over SCTP would be another option, but is not specified as far as
> > I know.
> > 
> > -Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 7 Nov 2001 23:13:39 -0500

-----Original Message-----
From: Shieh, Hugh [mailto:[email-masked]]
Sent: Tuesday, November 06, 2001 2:29 AM
To: 'Henning G. Schulzrinne'; Jonathan Rosenberg
Cc: 'Peterson, Jon'; [email-masked]'
Subject: RE: [Sip] Bis-5: TLS as secure transport for SIP

>Would love to see Gonzalo's simulation result on call setup delay
distribution. However, by 
>recommending TLS/TCP, does that mean that the involved proxies have to be
stateful 
>(according to line: 2013)? 

Funny you should mention it; I just logged a bug against this one. Turns out
that you don't need to be stateful if you are TLS/TCP in both directions.
This didn't used to be true because of the close coupling of transactions
with transport. With a clean separation now, you don't need to maintain
transaction state in order to maintain "transport state" - the set of
persistent connections.

>In any case, UDP is still (or is it?) mandated for all SIP 
>elements, so a solution other than TLS is still needed for UDP.

For user to proxy, its not clear that a transport level solution is the
right one. Although I have argued that basic/digest over TLS has benefits,
it clearly has scale issues and problems in wireless. So, we still need a
solution there, but its not a transport solution. TLS would still remain as
the recommended transport solution (yeah, yeah, tls isn't a transport; you
know what I mean).

"the bad thing about security technologies is that its so easy to find fault
and impossible to find solutions"

-Jonathan R.

-----Original Message----- 
From: Henning G. Schulzrinne [mailto:[email-masked]] 
Sent: Monday, November 05, 2001 3:56 PM 
To: Jonathan Rosenberg 
Cc: 'Shieh, Hugh'; 'Peterson, Jon'; [email-masked]' 
Subject: Re: [Sip] Bis-5: TLS as secure transport for SIP 

will 

---
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

---

From: Tuexen Michael <[email-masked]>
Date: Thu, 8 Nov 2001 09:27:19 +0100

Dear Jonathan,

I agree with you totally. But providing the funtionality
would require modifications of TLS.

We have discussed this and the result was that the ADs want a
simple soltution which does NOT require any changes of TLS.

Therefore we do allow
- session resumption on the stream so that you do not have
  to do a full handshake on each bidirectional stream. This
  can reduce the CPU usage.
- 'late handshake' which means that you do not have to perform
  the handshake (full or abbreviated) until you want to use
  the bidirectional stream for secure communication. This can 
  help you when you are establishing an association with a lot
  of streams.

Best regards
Michael

> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Thursday, November 08, 2001 5:31 AM
> To:	'Tuexen Michael'; [email-masked]'; Jonathan Rosenberg
> Cc:	[email-masked]; [email-masked]; [email-masked]
> One thing on this draft... you run TLS over each stream separately. Whilst
> it makes sense, it is really awful for applications that use lots of
> streams. It would be nice to be able to protect the entire association with
> a single TLS connection.
> 
> -Jonathan R.
> 
> ---
> > From: Tuexen Michael [mailto:[email-masked]]
> > Sent: Tuesday, November 06, 2001 7:55 AM
> > To: [email-masked]'; Jonathan Rosenberg
> > Cc: [email-masked]; [email-masked]; Tuexen Michael;
> > [email-masked]
> > > Cc:	[email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> > Use [email-masked] for questions on current sip>

---

From: Tuexen Michael <[email-masked]>
Date: Fri, 9 Nov 2001 09:55:18 +0100

Dear all,

just to let you know, one guy at the University of Essen
is looking into the necessary modifcation to use only
one TLS connection per SCTP association. But this is technical
work. 

Today I have no idea, once we have the result, how to preceed in IETF.
I think that it depends on the needs. If the current solution will
work, there is no need for the more complex one. If we have applications
of TLS/SCTP where the more complex solution is really needed and IPSec
is no alternative, than (I would expect that) the chances in the IETF for the more complex solution are better.

Best regards
Michael

> Sent:	Friday, November 09, 2001 6:46 AM
> To:	'Michael Thomas'; Jonathan Rosenberg
> Cc:	'Tuexen Michael'; [email-masked]'; [email-masked]; [email-masked]; [email-masked]
> > Sent: Thursday, November 08, 2001 12:53 PM
> > To: Jonathan Rosenberg
> > Cc: 'Tuexen Michael'; [email-masked]'; [email-masked];
> > [email-masked]; [email-masked]
> > Jonathan Rosenberg writes:
> >    You strive for IPsec, Grasshopper. :-)
> 
> Well, I'm not a big fan as folks are aware, but this mode of operation of
> TLS over SCTP is not useful, so I guess there isn't much other choice
> besides IPSec. One of the big benefits of streams, IMHO, is that you don't
> need to signal to use them. But, now I do if tls is used. 
> 
> -Jonathan R.
> 
> 
> ---

---

From: Robert Sparks <[email-masked]>
Date: Tue, 13 Nov 2001 15:35:17 -0500

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2001 10:14 PM

One part of the transaction state still exists - a proxy needs
enough information to forward responses down the connection 
associated with the transaction.

So, yes a proxy handling just TCP needs to be transaction stateful
given the tools we currently have at hand.

Now, there may be a way to push this bit of state into the
the messages (Jonathan has suggested received plus rport from
sip-nat). This would allow the proxy to only keep the connection
state listed above, searching through them for the right connection
to use when a response shows up.

RjS