Subject: Re: [SIP] T2 and 182 Queued

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 11:51:12 -0800 (PST)

> There are three separate attacks: flooding the SIP server from your real
> address (nothing you can do about it, you can suppress ICMP, but you can
> call the FBI or sysadmin and do router-level packet filtering if things
> persist), flooding the SIP server from a bogus address (again, nothing
> to be done, but at least ICMP should limit the secondary damage) and the
> smurf-like attack of using a SIP server as a "force multiplier" to some
> other innocent, but valid address.

and TCP solves the last two.

btw, imagine an attack where a malicious user issues SIP invites from bogus
addresses, but routable addresses, with a source port of 7 (echo port).

I'd like to see a SIP server withstand one of those attacks.

PatC

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 25 Jan 2001 14:23:57 -0600

Patrice,
RE: your comment " I'd like to see a SIP server withstand one of those
attacks.". I believe that we have firewalls to provide the single point of
failure in the event of DoS attacks, among other things. Yes you harden a
server to a point, but the firewalls along the path should provide the
protection against DoS. When I speak of firewalls I mean the architecture
that consists of the routers, intrusion detection systems, and the actual
"firewall" device. Even in a public network you should have a firewall in
place to filter before it gets to the public server.

I believe that the methods and policies used to protect against denial of
service attacks should be implemented at the firewall.

If we implement it at the server level there is the possibility to add
latency in processing times on the server itself.

I also believe that SIP awareness needs to be implemented on firewalls and
intrusion detection systems.

A global PKI would seem to be a natural progression if implemented at the
firewall level, when speaking of server complexes, and one that I would like
to see pursued. Once authenticated to the firewall one could "assume" a
minimal level of end-to-end security/accountability or "trust" in relation
to SIP communications.

Along the same lines, has any further work been done with the draft, or are
there similar drafts, draft-ietf-mmusic-sip-sec-00.txt by P. Kirstein, G.
Montasser-Kohsari, and E. Whelan.

If there is another list covering this I would like to find out so that I
can join it.

I am glad that this is being addressed now and would like to encourage this
discussion to continue, if not here then in another forum along these lines.

That's just my humble opinion.

Thanks in advance for any information on the above draft,

Christopher A. Martin
Security Integration Engineer, IPCOMM
MCI/WorldCom
972-729-4569

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Patrice Calhoun
> Sent: Thursday, January 25, 2001 1:51 PM
> To: Henning G. Schulzrinne
> Cc: Anders Kristensen; David Frascone; [email-masked]
> Subject: Re: [SIP] T2 and 182 Queued
>
>

---

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 25 Jan 2001 14:32:01 -0600

You bring up good points. Here are some other areas of concern that will
need to be addressed by firewall vendors regarding topology and information
disclosure.

There are many issues to consider besides DoS attacks with SIP. With the
potential for internal topology to be disclosed in Record-Route, Via, and
other fields scanning tools based on SIP could easily be created to gather
the information needed to make directed attacks/intrusions on internal
networks.

A PKI could provide a form of accountability that would be necessary to
insure confidence in SIP services, as well as quicker response to tracking
DoS attacks by using the authentication as a starting point. Perhaps even at
the certificate level.

Just something else to ponder,
Christopher A. Martin
Security Integration Engineer, IPCOMM
MCI/WorldCom
972-729-4569

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 12:39:09 -0800 (PST)

> place to filter before it gets to the public server.

Of course. fixes have been done to minimize SYN attacks, but building a
protocol with a specific architecture in mind is a bad decision, IMHO. Many
people will deploy SIP servers, and perhaps not have firewalls.

(in any case, it sounds so much simpler to fix the protocol than to require
firewalls)

> latency in processing times on the server itself.

sure, unless you mandate TCP, which already fixes these problems. Perhaps
there are other ways, and I wouldn't be against looking at different solutions.
> intrusion detection systems.

see above.

> minimal level of end-to-end security/accountability or "trust" in relation

Putting a cert on the SIP server is a quarter (or even less) of the problem.
The issue then is to distribute certificates with ANYONE that will communicate
with your SIP server (and I DO mean anyone!). If my grand-mother wants to call
you, must she first go to her favorite PKI vendor and get a signed cert?

> If there is another list covering this I would like to find out so that I

ditto.

PatC

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Thu, 25 Jan 2001 15:54:58 -0500

Patrice Calhoun wrote:

> (in any case, it sounds so much simpler to fix the protocol than to require

Suggestions are welcome, but I would guess that any such fix will
increase the message complexity of the non-DoS case and thus reduce
overall throughput. For example, use of TCP and IPsec definitely will,
due to the extra round-trip times and TCP-level messages.

Thus, with a datagram protocol it is probably provably impossible to
prevent flooding of the server, SIP or otherwise. (DNS, for example, has
the same issue, as does any other query-response protocol.) The only
means to avoid the amplifier effect is to require a handshake (IPsec,
TCP, whatever) before sending more than one message.

All TCP SYN flood mechanisms simply minimize the amount of state that is
committed on the server prior to completion of the handshake.
Fortunately, SIP authentication will minimize the amount of state, if
not computation.

For SIP, the standard (basic or digest) authentication provides such a
handshake. If somebody attacks you with a non-authenticated request,
reject immediately with 401/407. Don't send 100 or (if under attack)
additional 401s. A non-malicious INVITEr will retransmit the INVITE if
the 401 got lost. This solves the multiplier problem.

Digest already echoes back parts of the challenge, so this is as good as
the standard IPsec anti-clogging mechanism. We don't seem to know
anything better at this point, SIP or otherwise.

Basic is of dubious merit, but probably the CPU effort is sufficiently
low not to matter. (The larger expense is likely to be the lookup of the
name in larger installations, not the hash comparison.)

> there are other ways, and I wouldn't be against looking at different solutions.

TCP does not fix the problem in any magic way. See above.

> you, must she first go to her favorite PKI vendor and get a signed cert?

No, but see our approach in sipd for a workable, albeit less than 100%
secure mechanism of authentication of "first-time callers".

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

---

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 25 Jan 2001 15:04:51 -0600

This is just an assumption on my part, but as SIP gets implemented as a
service by many providers couldn't the user receive a cert as part of the
sign up process, using the providers public certificate server.

With this type of scenario the provideer would have information on file
about the user which is where accountability would come in. I am in no way
an authority on certificate authorities, this is just an thought on my part.

Chris

> Sent: Thursday, January 25, 2001 2:39 PM
> To: [email-masked]
> Cc: 'Patrice Calhoun'; 'Henning G. Schulzrinne'; 'Anders Kristensen';
> 'David Frascone'; [email-masked]
> Subject: RE: [SIP] T2 and 182 Queued
>
>
> > Patrice,

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 13:23:38 -0800 (PST)

> due to the extra round-trip times and TCP-level messages.

ok, but I wasn't talking about adding IPSec. 

btw, I would venture a guess that a protocol that is not subject to DoS, is
better than a slightly faster one.

> TCP, whatever) before sending more than one message.

The only way is to require a round trip, or that every datagram is secured
(see below).

> name in larger installations, not the hash comparison.)

ok, so we mandate authentication. How will you "[email-masked]" call me
"[email-masked]"? I guess there are a couple of ways: 1. Mandate that a
security relationship exists between columbia and sun (unlikely to happen
soon, but possible), and require that we send SIP messages to our respective
proxies instead of to each other's servers. 2. Mandate that we share a
security relationship with each other's servers (even less likely) 3. require
a round trip to ensure that the request wasn't spoofed.

seems like #3 above is the simplest.

> TCP does not fix the problem in any magic way. See above.

I must have missed the part where you explained why it didn't fix the problem
:( > 
> secure mechanism of authentication of "first-time callers".

Could I get a pointer?

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 13:27:23 -0800 (PST)

> an authority on certificate authorities, this is just an thought on my part.

yes you could, but then you would have to explain to your customers why they
can only receive calls from people that are in your little boys club :)

My problem is that I envisoned SIP as taking over alot of today's PSTN calls,
and if this requires that every person gets a cert that has the same trusted
root CA, it will take a long time.

Maybe it's just my imagination :(

PatC

---

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 25 Jan 2001 17:45:30 -0600

> > > (in any case, it sounds so much simpler to fix the

Firewalls are a fact of life on any network providing services to the
public. The appearance of openness is merely that. Firewalls are in place
for logging, access controls, separation of the physical devices that they
protect, etc.

I dont believe that we are recommending firewalls for the end user, although
I would make the recommendation if my opinion were asked, but any
responsible service providor would implement a firewall to maintain the
integrity of the services offered.

> btw, I would venture a guess that a protocol that is
not
> subject to DoS, is
> > the same issue, as does any other query-response protocol.

I would hazard to say that all protocols are vulnerable to denial of service
attacks, including IPSec (for instance if enough packets are crafted and
blasted to a device running IPSec, with an incorrect encrytpion key, in a
short period of time one could exhaust the devices capability to respond to
authenticated traffic). You may prevent amplification attacks but you dont
prevent outages due to denial of service unless you implement detection for
them.

) The only
> > TCP, whatever) before sending more than one message.

TCP , however, is not a security mechanism as its only real job is to
provide a reliable connectionless transport.

In a way SIP is providing the same mechanism in its handshake process, TCP
waits for an acknowledgement before sending the next segment, SIP waits for
an acknowledgment before opening a media stream.

IPSec is viable on a hop by hop basis for SIP but when you get into
different realms with security policies in place the firewall would break
the IPSec traffic if NAT were enabled. Since we are talking about SIP
through IPSec on a host device may not be a bad thing, unless a denial of
service were attempted to bring down the IPSec tunnel as described above.
The issue would be administering end user keys for service networks
providing the proxy services.

> The only way is to require a round trip, or that every

It is the mechanism to detect and redirect this traffic to a different
destination such as a sandbox that will truly protect any protocol.

> proxies instead of to each other's servers.

IMHO, yes (but thats just my opinion).

2. Mandate that we share a
> security relationship with each other's servers (even less
> likely)

Refer to Henry Sinnreich's draft,
draft-sinnreich-interdomain-sip-qos-osp-01, which goves a good example of
how this security relationship may be made possible.

 3. require
> seems like #3 above is the simplest.

Number three is good on a hop-by-hop basis, but requires IPSec setup between
various domain gateways (i.e., routers or firewalls), which is a matter of
trust any way you cut it. It still does not prevent the main topic of this
thread which wa prevention of DoS, as I see it.

It is often simpler for the same realm communicating over open public
address space that can administer their own equipment, but harder to gain
trust of/or even trust the many providers that may wish to interoperate.

It would seam to me that if we are talking about providers that offer SIP
services communicating with each other, it would be easier to utilize a
public PKI/Cert server. Just an idea.

In closing,
I agree that a protocol should be designed with security in mind, but at the
same time if you dont reuse the standards available for the task or even
emerging standards designed to address teh very issues it will only hinder
acceptance due to the drawbacks of making it secure and more complex, rather
than keeping it simple.

Chris Martin.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 25 Jan 2001 17:50:16 -0600

I am thinkning of a more public Cert server solution that cooperate with
provider cert servers for verification rather than one providers offering,
but then that sounds like DNS heirarchy and operation, doesnt it.

But I am still doing my reading and research when it comes to cert
servers...

> Sent: Thursday, January 25, 2001 3:27 PM

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 16:08:13 -0800 (PST)

> for logging, access controls, separation of the physical devices that they

I wasn't debating that firewalls don't exist, I am sitting behind one at home.
The issue is that we cannot state that a protocol is designed properly because
it can site behind a firewall. 

more below.

> prevent outages due to denial of service unless you implement detection for

yes, and one can send 64k pings, but that's not the issue. My point is that it
is our responsibility to not create new DoS attacks. As you state, there are
plenty, so we should be adding more to the know DoS list.

> provide a reliable connectionless transport.

I think that the initial message got lost in these threads. Please refer to
the original e-mail I sent on this thread. I never stated that TCP is a
security mechanism. I simply stated that TCP's handshake mechanism makes it
less susceptible to certain attacks, such as those we've already identified.

> an acknowledgment before opening a media stream.

The scenario we provided earlier allows a malicious user to fill up a queue
with bogus requests, the use of TCP makes this much more difficult. I think
that Dave also proposed another solution.

> providing the proxy services.

I understand the limitations of IPSec, and I am NOT arguing against the
existing SIP authentication mechanisms (or even proposing the use of IPSec).
If IPSec can be used, hence a PKI or pre-shared key, then the same security
association can be re-used for SIP. 

I think you've misunderstood my comment.

> how this security relationship may be made possible.

being somewhat close to AAA, I am aware how such schemes may work. But this is
really not what this thread was all about :)

> thread which wa prevention of DoS, as I see it.

Correct, so you keep implying that I'm proposing IPSec, but again, this was
not my intention. You can still use the existing SIP authentication mechanisms
even over TCP, right?

> public PKI/Cert server. Just an idea.

Here I do agree. My point is that ALL providers would have to participate.
That will take some time. If the goal is to move everyone off of the PSTN (or
at least lots of people), then we need to consider that MANY ISPs and
corporations will be involved. That's one big PKI, and I don't see that
happening anytime soon (but again, I could be wrong).

> acceptance due to the drawbacks of making it secure and more complex, rather

fair enough. here is my closing statement :)

I believe that it is our responsibility of ensuring that our protocols do not
introduce new DoS attacks. 

As an FYI, I am *NOT* trying to stop the development of SIP here. I actually
DO like SIP (as a call control protocol). 

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Thu, 25 Jan 2001 16:18:06 -0800 (PST)

> but then that sounds like DNS heirarchy and operation, doesnt it.

Unfortunately, that's not *quite* the way it works. However, it is possible
for multiple corporations to have their own certificate repository, and only
dish out their own certs (and, of course, CRLs). However, for everyone across
domains to trust each other, they can either co-sign everyone's cert (not
going to happen), or find a trusted root to sign their certs (more likely). 

One problem, of course, is that CA are typically disconnected from the
network, and have plenty of physical security. Not one would expect from a
public (or free) service.

One interesting side effect with PKIs, is that the argument of speed (hence
the reason for using datagrams) is eliminated when users need to find
certificate servers for a domain, retrieve the certificate, validate the
certificate authority chain (which requires retrieving additional
certificates), and checking against the CRL.

However, I am sure that someone such as Verisign would be most accomodating in
becoming the root server :)

> But I am still doing my reading and research when it comes to cert

Aren't we all :(

PatC

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 26 Jan 2001 10:44:59 -0600

> better than a slightly faster one.

This is true, and as you mentioned in an earlier email, I may have addressed
more than one email with my last few responses. I wasnt trying to imply that
you were talking about adding IPSec, merely agreeing that it is a viable
solution, although limiting.

Thats what heppens when I dont find the first email in a thread and answer
in the middle of it.  :^)

Chris

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jan 2001 08:51:52 -0800 (PST)

> you, must she first go to her favorite PKI vendor and get a signed cert?

   False. PKCROSS is your friend.

		  Mike

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 08:54:53 -0800 (PST)

>    False. PKCROSS is your friend.

ok, I assume this is KINK (and I have no idea what's going on in KINK). So
this only requires a global Kerberos infrastructure (meaning all kerberos
servers trust each other), and all users must be registered with their local
Kerberos server. Is this correct?

(again, I don't see how this has ANYTHING to do with the original thread,
where I pointed out a potential DoS flaw, and requested some help from the WG
to see how this could be closed).

PatC

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jan 2001 09:03:46 -0800 (PST)

> due to the extra round-trip times and TCP-level messages.

   I assume you're mainly talking about the UA-UA traffic
   which assumes no previous communication, in which case
   I agree. However UA->proxy, proxy-proxy, etc will
   likely benefit from caching affects of keeping the SA's
   up for some potentially indefinite time.

 > Fortunately, SIP authentication will minimize the amount of state, if

   If I had to pick my poison, I'd rather get hopwise
   crypto and strong authentication out of the overhead.
   
 > the 401 got lost. This solves the multiplier problem.

   Not really. Basic can easily be replayed, and digest
   can as well, assuming that you're using the commonly
   instantiated version which doesn't run a MAC over
   the whole message with a new nonce for each message.
   I assume that you'd consider per message challenges
   unacceptible overhead.
   
		Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jan 2001 09:13:34 -0800 (PST)

> prevent outages due to denial of service unless you implement detection for

   Correct. However, IPsec/TLS/etc -- other than
   queuing of packets -- does not create state or
   lead to amplification attacks. Unless you are
   concerned with attacks from within (ie, an
   authenticated user trying to do the deed), 
   IPsec and its kin can only be slagged only by a
   brute force attack which is, I suspect, the best
   you can hope for with DoS.

 > the IPSec traffic if NAT were enabled. 

   Then you have to live with ALG's (proxies,
   B2BUA's). This is an artifact of NAT and
   firewalls and is not specific to SIP.

		    Mike

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 26 Jan 2001 11:30:05 -0600

Michael Thomas writes,
>    firewalls and is not specific to SIP.
True, after all firewalls are supposed to be implemented to satisfy the
needs of the protocol and not the other way around.

From my point of reference to clear up where I am coming from, I am speaking
from a b2b type scenario where the above may be the case, rather than a
public scenario.

 >  I assume that you'd consider per message challenges

I would like to see some method that results in the public UA wishing to
communicate with a private UA, via proxies, firewalls, gateways, which has a
form of accountability built inwhich prevents the abuses that can be
performed when hash or digest are implemented, which is why I brought up
some form of PKI or certificate server scenario. As it is, authentication
from what I have seen in call flows, only occurs during the intial invite to
a proxy, in such a scenario using UA to Proxy to UA.

You mentioned PKCROSS earlier, I think I will look into this.

Thanks,
Chris

---

From: Michael Thomas <[email-masked]>
Date: Fri, 26 Jan 2001 09:33:24 -0800 (PST)

> Kerberos server. Is this correct?

   KINK is orthogonal to PKCROSS. The statement was that the
   only way to have a PKI was to have everybody get a certificate.
   This is not the case. PKCROSS allows the PKI to be scaled at
   the level of the KDC, not the user. Users may or may not use
   certs to do their initial authentication. This allows the PKI
   requirements of certs with cross realm trust implications to 
   be scaled down 3-5 orders of magnitude. Maybe more.

 > to see how this could be closed).

   The assertion was made -- repeatedly -- that base level
   crypto was not a feasible and/or deployable mitigation
   for DoS attacks for a variety of reasons. Given this 
   false premise, serveral people think that we ought to
   do all sort of horrendous things to SIP to prevent the
   myriad of ways that SIP allows an unauthenticated and/or
   spoofed user to cause state, etc, to be stored on the
   device under attack. Unlike TCP which has a relatively 
   simple state machine, SIP probably has hundreds of
   these opportunities and each would need to be painstakingly
   weighed with DoS opportunity vs. performance/complexity
   in mind. I see absolutely no reason for optimism here.

   This alone -- not to mention that crypto gives lot of
   other benefits -- sounds like a far more tractable
   solution for SIP. 

		Mike

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 09:40:11 -0800 (PST)

>    other benefits -- sounds like a far more tractable

OK, as I mentioned, I was open to other solutions other than requiring
TCP, as long as they worked.

So, if I am to understand, authentication in SIP is mandatory and schemes that
do not provide replay protection are not supported, correct?

PatC

---

From: James Undery <[email-masked]>
Date: Fri, 26 Jan 2001 17:50:50 +0000

> TCP, as long as they worked.

TCP is not a solution I could just as easily DoS your server with TCP. If you
totally remove UDP from the spec it may require a DDoS but it is still possible
for a person to produce a script kiddie simple program to take out a SIP server if
TCP is your only protection. The solution I feel lies out side the scope of RFC
2543 and its successors and in proper network configuration using IPSec,
firewalls, routers et al where appropriate.

James Undery

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 09:58:40 -0800 (PST)

> totally remove UDP from the spec it may require a DDoS but it is still
> possible for a person to produce a script kiddie simple program to take out
> a SIP server if TCP is your only protection. The solution I feel lies out
> side the scope of RFC 2543 and its successors and in proper network
> configuration using IPSec, firewalls, routers et al where appropriate.

sigh. seems like we are going around in circles....

TCP provides protection against the attacks Dave and I mentioned, namely
spoofed source IP address. Since TCP does require the 3 way handshake, it
would be VERY difficult for a hacker to mount a successful SIP attack.

But, as you state, TCP can still be attacked, but these attacks are better
known, and many operating systems, routers and firewalls already have
protection against the known ones.

so, to restate my (and the position from IESG and their security advisors)
position, is that protocols MUST NOT introduce "new attacks".

Once more I state (and did so in the e-mail you replied to) that mandating
authentication is a workable solution. My question was whether we could
mandate a non-replayable authentication scheme for all SIP messages.

PatC

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 26 Jan 2001 12:00:10 -0600

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Friday, January 26, 2001 11:40 AM
> To: Michael Thomas
> Cc: Patrice Calhoun; [email-masked]; 'Henning G.
> Schulzrinne'; 'Anders Kristensen'; 'David Frascone';
> [email-masked]
> >  > where I pointed out a potential DoS flaw, and requested
> some help from
> > the WG
I would disagree with this, and I know that you do to, replay prevention
needs to be implementd at some level, like at the provider level, not the
edge. Security should be a multilayered beast in the IP world.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 26 Jan 2001 12:04:20 -0600

> firewalls, routers et al where appropriate.

True, and this at an interdomain and/or core level where necessary.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 10:06:02 -0800 (PST)

> edge. Security should be a multilayered beast in the IP world.

Sorry, the above doesn't parse :)

I do not disagree with myself, I was actually being honest. If some level of
authentication is required, then an additional replay protection method MUST
be enforced. This could be done through timestamps, nonces (which are
patented, btw), or other mechanisms. Either way, I don't see how providers
guarantee replay protection (or even why I would trust some unknown entity to
provide replay protection).

PatC

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 26 Jan 2001 12:10:05 -0600

> would be VERY difficult for a hacker to mount a successful SIP attack.

Actually tcp does not prevent spoofing the source IP address. There are
hijack utilities in use today that perform this very task, and TCP is the
vulnerability exploited in these attacks, some of them do this by guessing
the TCP sequence numbers, others do it another way.

IPSec is the only real method to prevent spoofing and replay attacks.

> mandate a non-replayable authentication scheme for all SIP messages.
I agree with this, we do need to mandate this type of scheme, but I believe
that a non replayable mechanism would not be digest or hash authentication,
rather PGP or possibly S/Mime may offer this level of protection.

---

From: "Christopher A. Martin" <[email-masked]>
Date: Fri, 26 Jan 2001 12:18:21 -0600

Its all about trust.  :^)

If along the way, during the TCP handshake someone were to decide to
takeover, from the TCP ACK, by hijacking the session, how would this be
prevented by the authentication methods supplied with SIP to date(not
including PGP in this statement, which would be many levels better than
digest and hash), TCP or not?

Chris.

> Sent: Friday, January 26, 2001 12:06 PM
> Cc: 'Patrice Calhoun'; 'Michael Thomas'; 'Henning G. Schulzrinne';
> 'Anders Kristensen'; 'David Frascone'; [email-masked]

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 10:21:07 -0800 (PST)

> IPSec is the only real method to prevent spoofing and replay attacks.

S. Bellovin, "Defending Against Sequence Number Attacks", RFC 1948, May 1996.

I know that most serious operating system and router vendors do not ignore
such threats. Random sequence numbers are difficult to guess.

> rather PGP or possibly S/Mime may offer this level of protection.

Now I understand the confusion, we are talking about different problems. 

Yes, I agree that PK authentication would provide non-repudiation, and hence
be more difficult to forge than symmetric authentication schemes. However,
even assymetric based authentication protocols can be subjected to replay
attacks. Forging, or password theft is a different problem, but one that must
also be considered.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 26 Jan 2001 10:23:45 -0800 (PST)

> Its all about trust.  :^)

of course :)

> digest and hash), TCP or not?

Agreed. If someone can redirect routes and intercept your packets, then you
are SOL.

PatC

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 03:23:17 -0800

>    up for some potentially indefinite time.

Unless you prohibit the sending of messages outside of such a security
context, this doesn't help with DOS attacks. In other words: unless you
can assume that every caller /upstream server (that you care about) has
IPsec, this doesn't help much. This may help with moving the problem
from the UA to the upstream proxy, but I doubt that for a protocol
designed to allow random communication, requiring IPsec is even a
midterm-feasible solution. For one, you probably need 256 MB of RAM to
implement IKE, so that this is not exactly a proposition for mobile
terminals :-)

>From what I can tell, intercept is mostly a theoretical threat, at least
for the DOS attacks that we're talking about here. Snooping remote
traffic is far from trivial unless you have compromised on of the
routers along the way. Also, the end system can implement simple
mechanisms that limit the ability for replay, very similar to the
windowing mechanism used in the IPsec anti-clogging mechanism.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 03:30:11 -0800

> patented, btw), or other mechanisms.

I believe that is an urban legend. Use of nonces may be patented in some
scenarios, but the basic concept of its use in various circumstances,
such as the one in Digest, has been known since the 1970s. If you're
trying the patent-scare tactic, please provide appropriate citations,
not just rumors.

---

From: Patrice Calhoun <[email-masked]>
Date: Sat, 27 Jan 2001 10:04:46 -0800 (PST)

> trying the patent-scare tactic, please provide appropriate citations,

Sigh.

May I ask why you automatically assume I have ill-intentions, as opposed to
providing the WG with what I consider valuable information?

In any case, the patent I was referring to can be found in RFC 2002, and I
quote: "A.2. IBM Patent #5,148,479

   This patent, also assigned to IBM, may be relevant to those who
   implement nonce-based replay protection as described in Section
   5.6.2.  Note that nonce-based replay protection is an optional
   feature of this specification.  Timestamp-based replay protection, on
   the other hand, (Section 5.6.1) is a requirement of this
   specification."

PatC

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 17:20:21 -0500

> providing the WG with what I consider valuable information?

Sorry, didn't mean it to come across that way - unfortunately, I've
heard this type of argument ("I don't like X, and btw, it's patented") a
few too many times. You basically said "I don't like Digest, and btw,
you can't use its replay protection since it's patented."

>    the other hand, (Section 5.6.1) is a requirement of this

The same mechanism is used in IPsec and I've not heard anybody being
required to get a license from IBM. At least,
http://www.ietf.org/ipr.html does not mention it in that context, as far
as I can tell. More relevantly, RFC 2617 (Digest authentication) doesn't
make any such claims. RFC 2617 is not exactly a stealth RFC, so one
would imagine somebody raising it if this were an issue.

---

From: Patrice Calhoun <[email-masked]>
Date: Sat, 27 Jan 2001 14:33:40 -0800 (PST)

> 
> Sorry, didn't mean it to come across that way - 
no problem.

> unfortunately, I've

hmmm... don't recall saying I don't like Digest. I have no problems with md5,
hmac-md5, hmac-sha1, or any other hashing algorithms used. I was simply
raising a point regarding someone's comment regarding Nonce's, which has been
a problem in Mobile IP.

> would imagine somebody raising it if this were an issue.

I presume no one from IBM has been looking at IPSec that hard, and I won't
raise the issue there too. We can use Nonces all we like, that's not my point,
I was just providing my nonce experience that I came across in another WG.

PatC

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 17:41:36 -0500

> raising a point regarding someone's comment regarding Nonce's, which has been

However, nonce-based replay protection is a core part of RFC 2617
(Digest Authentication), which is what we're talking about here.

> I was just providing my nonce experience that I came across in another WG.

The relevant RFC is RFC 2617, which describes Digest authentication, as
used in HTTP and SIP.

---

From: Patrice Calhoun <[email-masked]>
Date: Sat, 27 Jan 2001 14:51:12 -0800 (PST)

OK, and I see that HTTP uses Nonce as well. Regardless of the status of
Nonces, I believe we both agree that replay is required.

In any case, this isn't really germane to the original DoS topic. I feel like
I've provided the patent information I thought the WG needed to know, and we
can now move on.

Thanks,

PatC

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 Jan 2001 17:15:06 -0800 (PST)

Henning Schulzrinne writes:
 > IPsec, this doesn't help much.

   Er, uh, so? Cisco's VPN doesn't have provisions for
   IPsec-lacking remote security gateways. If you don't
   have IPsec, tough cookies. I don't see any reason
   why proxies and/or UA's would not take that obvious
   step if they were interested in stopping any number
   of attacks.

 > This may help with moving the problem

   Oh, please. IPsec takes about the same amount of 
   code/data space as TLS, much of which is common
   functionality. If the terminals use that
   sort of cop out of why it's OK to transmit my
   stock transaction POST's in the clear, Ralph
   Nadar ought to consider a 21st century version
   of _Unsafe at Any Speed_.

 > routers along the way. 

   It's not just DoS attacks, obviously. And given 
   the rise of shared and unsecured media (802.11,
   hello?) I think that anybody who thinks that
   this is "theoretical" deserves what they get.

 > Also, the end system can implement simple

   Huh? With Digest? Do tell.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 20:31:04 -0800

>    step if they were interested in stopping any number

By definition, VPNs are pre-configured. Phone calls aren't.

>    of _Unsafe at Any Speed_.

I doubt that devices will support TLS, either, at least not all of them.
After all, most web transactions are not on TLS, either. (And most
embedded web servers don't support TLS.)

>    this is "theoretical" deserves what they get.

Yes, the listener on the local 802.11 can spoof your requests. We're
talking about DOS attacks, which tend to be longer range. 

>    Huh? With Digest? Do tell.

See the discussion in RFC 2617 for details and trade-offs.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 Jan 2001 17:45:32 -0800 (PST)

> By definition, VPNs are pre-configured. Phone calls aren't.

   You're splitting hairs. If a proxy and/or UA wants
   to subject itself to the infinite variety of attacks
   that can happen when you don't use crypto, fine;
   there's no protocol police to arrest you for doing
   stupid things.

   Tell me Henning: are you suggesting that from an IETF
   standpoint we should be endorsing non-crypto based
   fake "security"?

 > embedded web servers don't support TLS.)

   Sure. They sold cars with exploding fuel tanks too.
   Are you suggesting that we should endorse bad designs?

 > talking about DOS attacks, which tend to be longer range. 

   By this arguement, Basic is completely adequate too.

   As I've said, DoS attacks are but one piece of security.
   I don't understand why you insist on trying to frame
   the discussion as if the only consideration with 
   security were DoS attacks. If that were the only 
   consideration, you might have a point. It isn't.

		      Mike

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 27 Jan 2001 21:33:46 -0800

I'm not disagreeing with providing as much security as possible.
However, given the 20k lines implementation complexity of IPsec and IKE,
it is simply at this point unrealistic to say "let's simply put MUST
implement IPsec in the draft and be done with it". That's why a range of
security solutions, some better than others, is useful, depending on the
threat model and the cost trade-offs. I'd have rather have people
implement Digest than nothing (and rather implement IPsec and/or TLS on
top of that). We've made progress in that almost all SIP implementations
nowadays implement Digest authentication. Given the sorry state of
public key infrastructures right now and the uncertainties which model
will prevail (all the KINK and PKCROSS stuff is pretty much wishful
thinking right now, after all), it is rather premature to require IPsec
or TLS, say.

Unlike VPN boxes and PCs, IP phones are consumer devices that need to
sell at not much more than $100. In a few years, that $100 may include
enough memory to run Linux or another real OS. Right now and for the
next few years, it's an embedded OS with a few hundred KB of memory at
the low end. Having built such devices, I can tell you from experience
that this makes TCP iffy and IPsec with IKE/TLS an impossibility, given
what else you have to support to have an operational device.

For proxy servers, TLS with web-like certs may be deployable right now,
although probably again as a means for server verification, not client.
(I.e., Digest or Basic on top of SSL, as is typical for web servers.)

It is instructive to see how much progress secure email has made over
the years, even though the issues there are somewhat simpler (e.g.,
latency is not an issue) and software has been available for a  number
of years now. I wish it were different, but it's clear that the forcing
mechanism hasn't been there to get people to regularly use crypto on
that. SIP is rather similar to email in many ways, including random,
non-pre-configured configuration and a range of devices.

We've talked about authentication in general ad nauseam on this list,
with the same arguments again and again between the "realists" and the
"maximalists". We continue to disagree about the availability and
timeframe of a client-level keying infrastructure and no amount of email
is going to resolve this, given that the current reality is clearly that
we have at best some approximation of domain-level authentication (in
TLS certs for web servers) and preconfigured secrets. We can speculate
how fast this reality is likely to change, but I doubt we'll make much
progress.

That's why I wanted to focus on DOS attacks, which seems at least a
somewhat new topic.

Comparing things to exploding fuel tanks is not particularly helpful
here.

>    standpoint we should be endorsing non-crypto based

I'd like to give people a range of choices, rather than making
unrealistic prescriptions, with the outcome that the default choice
(nothing) gets implemented.

>    Are you suggesting that we should endorse bad designs?

We should endorse designs that can be as secure as other services that
are similarly situated and can be operated and manufactured at
resasonable cost. After all, the safety of a Volvo compared to a Geo
Metro has reasons and costs...

>    By this arguement, Basic is completely adequate too.

Well, for DOS Basic is probably a good first defense. For almost all
attackers, it will be very difficult to create a valid password, so it
would get rid of all but the most sophicated DOS attacks. Again, as
stated, given that we've ground general authentication into list dust a
few times, I'm concentrating on the topic at hand.

>    consideration, you might have a point. It isn't.

See above. We can solve, to a degree similar to current TCP services,
the DOS part without having to wish upon a new world order of security
infrastructures. That's progress.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 Jan 2001 19:24:57 -0800 (PST)

> thinking right now, after all), it is rather premature to require IPsec

Henning,

The cost of implementing strong crypto on a
consumer class box is probably less than $1. Maybe
less than $.50. Moore's law will make the cost of
crypto an utterly insignificant cost in the
future. Also: MEGACO and MGCP mandate the use of
IPsec, and the main feedback there was the worry
that third party IP stacks might not be able to
get IPsec and as a result they put in an
intermediate solution of requiring application
layer AH headers. I believe that the current
consensus is that that was probably not necessary.

Digest is worse than nothing at all (Basic at
least doesn't cop an attitude that it's anything
less than inadequate): as currently -- and likely
forever -- implemented does not provide basic
security features like replay protection,
bidirectional authentication or confidentiality.
For the SIP WG to suggest that it is the least
common denominator will do far more harm than
good: it will merely postpone the day that
effective strong crypto is used until _after_ the
phone phreaks phind phun.

 > the years [...]

No it's not. Mail has twenty years of baggage
to contend with. Neither SIP or MEGAGO/MGCP have
to deal with that particular intractablity.

 > That's why I wanted to focus on DOS attacks, which seems at least a

And the answer is the same and you don't like the
answer again. Quelle surprise.

What I don't buy is that the SIP WG should spend
one iota of time on dealing with DoS attacks on
unsecured transactions. It comes with the
territory and the sooner we can point to the
obvious advice, "use strong crypto", the sooner we
can get back to the things that people in this WG
are capable of solving. Every other half step is
a complete waste of time.

		     Mike

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 28 Jan 2001 10:11:01 -0500

Michael Thomas wrote:

> consumer class box is probably less than $1. Maybe

This is bogus. Have you tried to actually built one of those boxes? I
have and I know the prices for SRAM and DRAM, which are still major
components of the end system cost.

> IPsec, and the main feedback there was the worry

Megaco and MGCP are also almost exclusively run without IPsec right now
(Apparently, they aren't used all that much, but that's a separate
problem). Plus, they are fixed-association devices across a single
network hop, so none of the difficulties we're discussing here apply.

> security features like replay protection,

You keep repeating this, but that still doesn't make it correct.

> to deal with that particular intractablity.

This is not a baggage issue. All modern email clients, probably
representing 90+% of email messages sent or received (such as Eudora,
Netscape and Outlook), are crypto-cabable. Still, basically nobody uses
it.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 28 Jan 2001 13:18:19 -0800 (PST)

> components of the end system cost.

   Yes, as a matter of fact I have. I just looked on Pricewatch
   and ram seems to be going for about $.33/M and flash is going
   about $1-2/M. I just size'd pluto and klips and got about 400k.
   An embedded system could easily shave quite a bit of that down,
   but even if it didn't we're talking about less than $1 _retail_
   cost.
   
 > problem). 

   The IETF isn't the protocol police, &tc. Are you
   saying that MEGAGO/MGCP should just face reality
   and put - oh say - digest authentication in too?

 > Plus, they are fixed-association devices across a single

   May I ask how you plan to do/scale cross realm Digest
   since you're throwing the PKI scaling spectre around?
 
 > You keep repeating this, but that still doesn't make it correct.

   \/\/hatever. Be my guest. Build insecure boxes for
   specious reasons. Declare the problem intractable
   and substitute non-scalable fake security instead.
   Maybe we can have a great big group hug after we
   properly fawn over the emperor's new cloths.

		 Mike