Subject: RE: [Sip] TLS section

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 28 Jan 2002 17:55:30 -0600

More below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, January 28, 2002 2:32 PM
> To: Peterson, Jon
> Cc: 'Michael Thomas'; [email-masked]
> Subject: RE: [Sip] TLS section
> 
> 
> Peterson, Jon writes:
[snip]
> 
>    I find it confusing because it's not correct
>    in a pretty large way. That is, reading this
>    tells me that the authors (maybe you! :) are 
>    conflating message integrity/encryption with
>    credentials.

Addressing this point any further would be splitting hairs, and most likely
wasting our time. We'll attempt to bulletproof this language a bit.

> 
>    Frankly, I'd give up any other distinction than the
>    two obvious ones: 
> 
>    o IPsec allows use of UDP
>    o TLS currently has an API to access the
>      credentials, while IPsec requires that
>      API to be built.

I agree those are important considerations, and I think they come across in
the document. We'll attempt to prune around these points so as not to offend
any delicate sensibilities.

>  > 
>  > The security solutions section, 22.3.2, suggests a way that this
>  > transitivity might be used in a real-life deployment. Although it's
>  > distasteful to you, I think it jibes with the core needs of SIP.
> 
>    We all know how to ignore the transitive
>    problem. That's as simple as ignoring it.
>    The other problem with this paragraph is
>    that it implies there's some quantifiable difference
>    between TLS or IPsec here. There isn't;
>    neither can help you, nor will they impede your
>    memory cells from losing all knowledge of
>    the transitive trust problem.
> 

SIP is predicated on trusting intermediaries that route sessions, it's true.
If the fact that many elements may conspire to route a session is a bug, and
not a feature, then perhaps your problem is with SIP itself. So I guess I
agree that you have to 'ignore' it, or at least work around the fact that
there are intermediaries. 

I also do agree that the passage illustrating transitivity with Alice and
Bob does not represent a relationship that can only be instantiated by TLS -
that just happened to land here because transitivity was mentioned.

>    <predicatable>
> 
>    Nothing addresses security for UDP and thus the
>    spec is incomplete.
> 
>    </predicatable>

Today, SIP clients can use UDP without using IPSec, and that won't change if
we make IPSec mandatory to implement. Now that UDP and TCP are both
mandatory in UAs, clients have a choice - either use UDP, which has no
recommended lower-layer security mechanism in the specification, or use TCP,
which you can secure with TLS. I don't see how this is 'incomplete' just
because a UA can choose to communicate in an insecure fashion. If all proxy
servers support TCP and TLS, then it sounds to me like a client that
supports TLS can always make a secure connection.

> 		Mike

_______________________________________________
Sip mailing list  https://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: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 16:23:16 -0800 (PST)

> supports TLS can always make a secure connection.

   It's incomplete because a perfectly valid transport
   mode -- UDP -- doesn't have a perfectly valid MUST
   IMPLEMENT security scheme. What you're saying is
   "if you want security, use TLS". That is not
   helpful for when you use UDP. 

   Frankly, I think this debate would be much better
   served by talking about what the *real* 
   implication is here: deprecating UDP. Are you
   and the rest of the authors ready to do that?
   Making UDP a poor relation to TCP has the same
   effect. So we either keep it as a valid option
   or deprecate it altogether. One or the other.
   This current wishy-washiness is the worst of
   all worlds.

	Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 28 Jan 2002 19:50:16 -0500

"Peterson, Jon" wrote:

> recommended lower-layer security mechanism in the specification, or use TCP,

The primary concern mentioned is integrity. Proxy authentication
addresses this about as well as IPsec without key exchange (modulo the
need to fix the Digest problems, but they need to be fixed regardless of
the choice of lower-layer crypto).

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Mon, 28 Jan 2002 19:59:57 -0500

Michael Thomas wrote:
> 
> Henning G. Schulzrinne writes:
>  > addresses this about as well as IPsec without key exchange
> 
>    You can't be serious.

Thanks for your helpful response.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 16:54:07 -0800 (PST)

You can't be serious.

	     Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2002 17:46:32 -0800 (PST)

> Thanks for your helpful response.

   Anybody who claims that a challenge/response
   protocol -- which does not purport to protect
   every message, prevent replays, etc, etc -- 
   is either sadly misinformed, or not serious.

   Take your choice.

	     Mike

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 29 Jan 2002 08:54:04 +0200

>    and the rest of the authors ready to do that?

i'm not an author, but a couple of weeks ago we had (and i guess still
have) problems with udp fragmentation.  now if udp would also require
ipsec, then there is one more good argument to deprecate udp (as i
already suggested in connection with the udp problems).

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 29 Jan 2002 08:48:43 +0200

Peterson, Jon writes:

 > which you can secure with TLS.

i don't know ipsec well, but from ipsec vpn stuff i have got an
impression that setting up ipsec sessions requires either some kind of
pki or pre-shared keys, whereas i can do my internet banking over tls
without that.

i definitely don't want to make the sip ua any more complicated to
configure than what it already is.  can someone confirm or deny that if
i run sip/udp/ipsec, there is no additional configuration in the ua
because of ipsec?  if additional configuration is needed, then i'm
STRONGLY against mandating ipsec.

i know that if i would use hip instead of ipsec, there would be no
configuration needed, because in hip each party can generate its own
keys without coordination with the other parties.

-- juha

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 29 Jan 2002 09:30:28 +0200

Hello Juha,

> pki or pre-shared keys, whereas i can do my internet banking over tls

Both IPsec and TLS require some sort of authentication set-up. TLS
has just one possibility, PKI, and is typically used with the current web
server PKI hierarchy. IPsec does that as well, but also has optional pre-shared
keys as an alternative. TLS configs are usually in your browser's security setup window
while IPsec configs are usually in the OS setups, though they sometimes
can also be controlled from an application via commands or APIs.

One difference IPsec and TLS typically have is that TLS may be
run in one direction only, where only the server side is being
authenticated. This lessens the need to enroll certs for the clients,
which could be major issue. However, I'm not sure this is true
fundamental difference in the protocols. At least some IPsec
implementations I know can be configured to accept self-signed
certs. Hence, if the clients generate their own certs (but don't enroll
them anywhere), require the same CA roots from the server as
TLS does, and if servers accept self-signed certs I think the effect
is the same as in TLS.

> STRONGLY against mandating ipsec.

Different configuration than in the TLS case, but in both cases some
configuration is indeed needed. All this can be hidden from the user
and roots can default to Verisign, but some configuration is needed.

> keys without coordination with the other parties.

HIP can indeed do this, but that doesn't mean that if you generated your
own keys I'm ready accept your INVITEs.

Jari

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 29 Jan 2002 10:04:05 +0200

> and roots can default to Verisign, but some configuration is needed.

i don't get this.  are people suggesting that if i use ipsec then the
proxy server doesn't anymore need to authenticate the ua with
username/password like it is done today with digest or basic
authentication?

my understanding is that ipsec (and may be also tls) doesn't
authenticate the user of the computer, but only the computer itself.  if
so, it could not replace the username/password authentication, but would
be just used to protect the integrity and privacy of the authentication
process.  this is why i can do my banking from anyone's browser.

if username/password authentication is always used anyway, then there
should be no need to authenticate the parties at the underlying
transport (ipsec or tls) layer, right?  it would be enough that the
transport provides security and integrity of the username/password
authentication process.  therefore, i don't see any need for the
transport to use any kind of pki or pre-shared key stuff, and therefore
i don't see any need for the user to configure anything in the ua
because of the transport.

in summary, if i use username/password authentication, then the sip spec
MUST NOT mandate any transport layer security solution that requires ANY
authentication of the parties at the transport layer.  a solution that
can make sure that the communication channel is secure and integrated,
MUST be sufficient.

 > own keys I'm ready accept your INVITEs.

of course not.  you would accept my invite because of my
username/password.

-- juha

---

From: "Jari Arkko" <[email-masked]>
Date: Tue, 29 Jan 2002 10:39:52 +0200

> process.  this is why i can do my banking from anyone's browser.

Specifically, in your banking application the bank actually *does*
get authenticated using certs, and as a side-effect a protected
"tunnel" is established to protect your communications. [With no
certs or anything for the bank side, protected communications
could not be securely established!] After all this, *you* get
authenticated by the passwords.

> because of the transport.

See above. Getting security and integrity for the tranport does force
you to configure something - or at least your browser vendor to default
something for you. The question that can be asked, however, is whether
TLS-like one-sided thing or TLS/IPSec-like two-sided thing should be
used. It seems that both TLS and IPsec are capable of both alternatives.

> of course not.  you would accept my invite because of my

Ah, now I see better what you mean. But assuming you *are* trusting
the integrity and confidentiality of your "transport", do you know if HIP
is secure against MitM, if there's no configuration? You seem to be implying
something akin to the opportunistic IPsec methods, but I'm not sure
if that has been defined for HIP yet.

Jari

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jan 2002 19:06:47 +0200

Hi,

UDP is still useful when you are sending small messages. If you want to
send large messages, use TCP. But if, by any chance, your message is
small, you can avoid the three way handshake by using UDP. I do not see
why because some (or many) applications will use large messages, the
rest of the applications that do not use them have to pay the price of
the 3-way handshake as well.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 29 Jan 2002 21:31:15 +0200

Hi,

I do understand the reasons for using TCP, but why does it have to be a
"MUST"? My node may never send messages so big, and it may be used in a
network where it will never receive messages such big.

Also, there may be nodes which will always communicate with a specific
outbound proxy, so they may use a "static" SCTP association for that.

So, saying that nodes handling big messages shall use TCP (or similar)
is ok, but making TCP mandatory for EVERY node is another issue...

I also don't think we shall throw away UDP, and always use TCP, because,
as Gonzalo said, in most cases UDP will be just fine.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 02:23:18 -0500

> is ok, but making TCP mandatory for EVERY node is another issue...

The problem is this. You can control what you can send, but not what you
will receive. If I send you a 2000 byte sip message, the spec says that
your proxy has to use TCP to send it to you. If you don't support TCP,
you won't get it.

-Jonathan R.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 02:30:49 -0500

>    helpful for when you use UDP.

Agreed, it is not. IMHO, we need a non-transport oriented solution as
the baseline for UA to proxy security functions. I believe that baseline
is digest. While it certainly has many weaknesses that are well known,
it is better than nothing, and has the benefit of being implementable
and solving a reasonable class of attacks. TLS is better for smaller
deployments, where the scale issues are not so bad that you can pay for
the persistent connections. IPSec is not likely to be any better in
terms of scale, since both have the same state issues. Once you move
away from persistent connections, TLS suffers heavily from expensive
setups that you will effectively repeat for each call, increasing
latency and overhead. IPSec is similar; I dislike its keying mechanisms
as well, but let us not dive into that, since its not really important
for this point. So, since both TLS and IPSec have fatal flaws for large
deployments, digest is preferred as the only broadly workable solution
there.

-Jonathan R.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2002 09:49:48 +0200

Hi,

>your proxy has to use TCP to send it to you. If you don't support TCP,

The question is: when will you send me a 2000 byte sip message? When you
use some specific SIP feature (eg instant messaging), or for a "basic"
session setup?

IF the argument is that the messages will be too big in "basic"
situations, ie in situations where ANY (or, at least ALMOST ANY) UA node
could be involved, I guess TCP must be supported. But, my argument (I
don't have any numbers to prove this, and there are probably others who
know about this more than I do) is that 2000 bytes will be enough for
normal/basic situations.

Using TCP for interproxy communication is ok, but if the UAS doesn't
support TCP the last proxy before the UAS will have to try to find
another server, or return an error response.

Another question is: since the INVITE may be the only big message during
the session, can I then switch from TCP to UDP in the middle of the
session? What if there is an open TCP connection, but I still want to
use UDP?

Last, I don't have anything against TCP as such, but I just wonder if
making a bunch of transport protocols mandatory for SIP is the right way
to go - both from a protocol architecture point of view, but also from a
pure technical point of view (you have to fit yet one more protocol in
the small PDA...).

Regards,

Christer Holmberg
Ericsson Finland

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 30 Jan 2002 10:37:46 +0200

> use some specific SIP feature (eg instant messaging), or for a "basic"

try to send a regular invite that includes digest authenticatin header
and goes through three proxies each adding its record route, and viola,
your invites is bigger than 1500 bytes when it hits the destination ua.

for this reason ANY ua that plans to participate openly in sip
telephony, for example, is liekly to get (uncompressed) messages that
are larger than 1500 bytes.  therefore, if the ua doesn't either support
ip fragmentation (not recommened) or tcp, it will be out of luck.

-- juha

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Jan 2002 11:01:50 +0200

Hi,

>your invites is bigger than 1500 bytes when it hits the destination ua.

Well, I guess you have a point there. However, this also depends on the
security mechanism used, and if the security mechanism itself
authenticates the user. It also depends on when compression will be
used, and how much it will help.

The question is also who the caller on the SIP level authenticates
himself with, ie if the authenticatin data has to be sent all the way to
the UAS in the first place.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 30 Jan 2002 10:50:58 -0500

Also, despite various political correctness issues, UDP will work unless
you have a conflation of two things:

- messages greater than (say) 1,500 bytes
- a NAT between the last-hop proxy and the UA
OR
- a highly lossy link (> 5% loss, say)

(With 10% loss, the probability that a two-fragment packet won't make it
is about 19%, assuming independent losses.)

Thus, I suspect that a robust implementation that will find a UDP-only
(e.g., RFC 2543) implementation will attempt to send a larger UDP packet
anyway. At least that way, there's a chance that it will succeed. In
many cases of interest, the chance is actually close to 100%. (E.g., in
our local network, with existing UDP-only SIP phones and no NATs and
maybe a one-in-a-million packet loss ratio. For others, where the proxy
is an ALG, this holds for NAT-challenged networks as well.)

I'll go to UDP political correctness training now, thank you.

Henning

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Jan 2002 08:20:16 -0800 (PST)

> I'll go to UDP political correctness training now, thank you.

   I guess we should go together because I'm having
   a hard time imagining how the situation with SIP
   could be even 1/10th as bad as the punishment that
   HTTP 1.0 caused the net. I think the net is more
   resilient than most people give it credit for.
   The simple solution of mandating TCP
   implemention but not forcing its use (even when
   you'd fragment) until there's some *real*
   empirical evidence that the amount of
   fragmentation caused by SIP causes global
   harm seems a lot more prudent than the
   compromise in bis right now. If we're
   eventually proven wrong (and properly
   reeducated), we simply get out the word that
   TCP is safer and more robust which would only
   require a small change on the UA's.

   BTW: I think that the MUST TCP is probably a 
   good thing generally and not just because of
   message size considerations.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 30 Jan 2002 08:32:30 -0800 (PST)

> your proxy has to use TCP to send it to you. If you don't support TCP,

Jonathan,

I'm having a real hard time understanding why it
is beneficial to the net if the UAC accepts the
TCP connection for a large response and then
immediately shuts down the connection. That seems
like an extra 6 messages to me. I'm assuming that
the UAC probably prefers UDP for some reason --
like it or the proxy/UAS doesn't want to keep the
TCB around long term, etc.

Now, I have less disagreement if the UAC initiates
a large message, but as with my previous mail to
Henning, I'm worried that this might even be
tempest in a teapot.

	Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 11:44:29 -0500

> TCB around long term, etc.

This is an excellent point, to be sure.

Clearly, it becomes an issue as that message becomes larger.
The question is, where do you draw the line? Apparently,
a reasonable place to draw it as at the path MTU, since a host
of other bad things begin to happen when you get there. 

As I point out in a previous note, the fact that there is a gradual
worsening of UDP impact as messages increase in size is good for
us from an adoption perspective; it means that since its not
a major problem today, continued usage of UDP won't really 
massacre the net like http 1.0 did, but by the time the real
problems role around, we'll be ready with TCP enabled UA.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 30 Jan 2002 11:41:09 -0500

> is about 19%, assuming independent losses.)

Right; this is how we get backwards compatibility. I have no false
assumptions that the world will all of a sudden have TCP endpoints once
bis issues as an rfc; I suspect that it will be a LONG time until most
endpoints support TCP, and that UDP with occassional fragmentation will
continue to exist. Mandating TCP is really aimed at pushing UA in a
direction where we can be sure that SIP becomes more "net friendly", and
there are no awful surprises down the road when someone does decide to
send that 1M SIP message.

-Jonathan R.