Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Apr 2002 17:11:47 -0400

At 04:28 PM 4/25/02 -0400, [email-masked] wrote:
>If a client knows the range of reasonable addresses, it should receive then
>it can determine autonomously that a rogue server has sent it a fraudulent
>address with no specific cryptographic capability in the client. 

It can guess but it can't know for certain.  Certainly, in
the case where the NAT is being provided by the service
provider and is not on the customer premises, as with cable,
there's no way for the client to know what a reasonable 
public address might look like.  And then there's the continuing
problem of multihomed networks or nested NATs ...

This might be a reasonable thing for a manufacturer to add to 
the client but it's not a substitute for properly securing the 
protocol when we know there's an easy-to-perform attack against
it in anticipated deployed configurations.  

Melinda

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: "Cullen Jennings" <[email-masked]>
Date: Thu, 25 Apr 2002 18:33:12 -0700

In the case of my particular home cable modem with a residential NAT behind
it, I do know the DNS name of my public address. It looks like my cable
modems MAC address followed by service providers domain. I also run dynamic
DNS from my NAT so I even have a reasonable human readable DNS address for
the public side of my NAT.

I agree that this does not sound like a very good solution - I'm not sure
how an average user would configure it - but it is interesting to note that
there seem to be a fair number of cases where it is feasible to make a
fairly intelligent guess at what the IP range of valid DNS address might be.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Melinda Shore
> Sent: Thursday, April 25, 2002 2:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [midcom] WGLC - Alternatives for 'securing' STUN
>
>

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 26 Apr 2002 12:19:49 +0100

Can I go back to basics then and just check my understanding...

As I understand it the problem is that you might get an impostor (Mallory or
whatever his name is) supplying you with an invalid MAPPED-ADDRESS.

(stun-00 also says "...the attack is only possible for attackers outside of
the NAT when the NAT is full cone."  I'm not sure this is true.  If Mallory
does source address spoofing it should slip back through the NAT nicely.
But it's convenient to assume this is true for the time being so I'll stick
with it!)

There seem to be two ways Mallory can operate -

1) Mallory is sitting on the path of the STUN request and on seeing it go
past, generates a spoof response.
2) Mallory compromises the STUN server.

In the first case, I assume that the client will get both the genuine and
faked response (especially if they do retries).  Is that reasonable?  If
that's the case the client can surmise that something is up.

In the second case, if it is only a vulnerability in the case of full cone,
perhaps the client can run the STUN test off of a number of STUN servers
(maybe 3 or 4) and cross check results on the theory that not all of them
are likely to be compromised at the same time by the same person.  Even if
they were all compromised by the same person, it is unlikely they would all
give the same results if the tests were done at the same time (they wouldn't
have enough time to agree on their story).

Running the test multiple times is probably not as bad as it at first
sounds.  You wouldn't need the cookie exchange, so you get two tests for the
price for one there.  All the crypto stuff has got to be a burden on the
servers as well (hence the need for the cookie) so removing that ought mean
you can cope with many more tests.

The client could also log addresses that it thought were genuine so that it
wouldn't have to double check those every time.

(Excuse me for banging on about this, but I feel that sometimes it's
important to explore other possibilities before going with something that is
going to be quite hard to implement - even if the chance of finding
something is relatively small.)

Pete.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Apr 2002 07:42:38 -0400

>that's the case the client can surmise that something is up.

It's not a reliable test because: 1) it's not possible to detect
UDP packet loss (if the legitimate response is lost), and 2) how
long would we have to wait before deciding that we're only getting
one answer?

In terms of the server having been compromised, all bets are off
in that case, anyway.  Even if the protocol were highly secure, 
losing the private key would be enough to give the whole thing
away.  While there are things that can be done to mitigate the
effects of a system compromise there's no real protect against
it for our purposes.

Melinda

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 26 Apr 2002 14:18:16 +0100

----- Original Message -----

> UDP packet loss (if the legitimate response is lost),

Retries or trying a different server would resolve that.  Trying different
servers would be a better option.

> and 2) how

About as long as I wait to decide I'm not going to get a reply from any
other STUN test.

I could actually assume that the first response was genuine and carry on
with that.  If I subsequently found that another response came in, I would
only then start thinking about what to do with it (maybe tearing down the
call).

Pete.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Apr 2002 10:11:12 -0400

>servers would be a better option.

No, because you don't know if you've lost a packet.  That
is to say, the attacker's packet gets through and the
legitimate packet does not.  If you think that too unlikely
to be of concern, consider typical internet packet loss 
statistics and the situation where the attacker is on the
local network.  

>only then start thinking about what to do with it (maybe tearing down the

In the typical telephone call you have one outbound media
channel.  You would not discover the problem until subsequent
telephone calls were placed, and then only if 1) the client
was retaining state between calls, and 2) the call wasn't
followed by a subsequent successful attack.

Melinda

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 29 Apr 2002 10:13:10 +0100

I see the problem a bit like this...

If I have a message written in Chinese on a bit of paper and I want to know
what it says I have two options:

1) I can take it to the Chinese Embassy (in my case in London) and ask them
to give me an official translation, and sign it to say its authentic.

2) I can ask a number of Chinese people locally to translate it.  If I get
consistent results then I can be fairly sure that that's what the message
says.

(2) is what I'm suggesting here (simultaneously send 3 or 4 packets to 3 or
4 different servers and compare their results).  In my case it saves me from
going all the way to London.

(2) may also be even more reliable than (1) if the message happens to be in
something like Iraqi and I go to the Iraqi embassy for a translation!

Given that this is a light-weight protocol and a short term solution, I feel
that it is more likely that such a scheme will be implemented than if it
requires heavy-weight encryption.  I think a cryptographic solution will
hinder STUNs adoption for the following reasons:

- On the client side the cryptography is something you probably wouldn't do
on the first iteration.  After you got unsecure STUN going you'd probably
move on to other things.  Once you'd moved on it would always be on that
list of things to do, but always below many other things that seem
necessary.

- It will make it harder for people to deploy STUN servers.  Server
providers will be unlikely to provide servers if they are not fully
functional (it reflects bad on them).  They would rather NOT provide a
server than provide a half baked server.  That would limit the proliferation
of servers.

- Bear in mind also that good cryptography is not just about factoring large
numbers etc, it's about securely storing keys etc.  This is hard to do and
server providers may not be willing to hand their private keys over to a bit
of free-ware.

- If something is difficult to implement, individuals will be less inclined
to implement it and companies will be less inclined to make copies publicly
available.  This will limit the proliferation of STUN servers.

Overall, something to worry about.

I also feel we are making the association between 'secure ==> cryptographic'
as a knee jerk reaction.  While this relationship is often the case, I don't
believe it always is.  For example, hiding one message within a second
innocent looking message has been a secure way of conveying messages for
years, but it's not what we would recognise as cryptographic here.

Still, if you think adopting a cryptographic solution is the only way we'll
convince the IESG that it's secure, then I guess cryptographic is the only
way to go!

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Apr 2002 13:43:00 -0400

Sorry for my absence on this thread.... my email back log is enormous at
the moment...

> going all the way to London.

It is most certainly NOT the same thing. Each stun request will have a
different source port in many cases (symmetric NAT) because you are
going to a different destination. Depending on the nat, it might even
have a different source IP address. This approach is no substitute for
real security, and in fact, is much worse, since it will lull people
into a false sense that it provides it, when it doesnt.

> something like Iraqi and I go to the Iraqi embassy for a translation!

With an authenticated server, you know who you are talking to. I suggest
you don't send STUN requests to the iraqi stun servers. That solves the
problem. With your approach, since you don't know who you are talking
to, you might talk to an iraqi server, which happily reports false
mapped addresses. Indeed, your approach introduces a dos attack. I can
run a server that always hands out incorrect mapped addresses. A client
sends a a real server, and then to me, trying to validate the answer. I
report a false answer. The client can't tell which is right, so it ends
up dropping the call. Nice DOS attack.

> list of things to do, but always below many other things that seem

The point of a security considerations section is to make people aware
of the problems that might happen if you don't use security. If they
still don't care, then they are asking for trouble.

> server providers may not be willing to hand their private keys over to a

I have no idea what this means. 

> available.  This will limit the proliferation of STUN servers.

By this argument we shoud do away with cryptographic based security in
all protocols. I don't think so.

> years, but it's not what we would recognise as cryptographic here.

Whether this technique counts as cryptography, I don't know. But, I see
little value in arguing about the definition of the term. 

The best way to provide security is to map your problem to other known
problems, and then apply  known secure solutions. This is a known
problem, with multiple known solutions (each with known limitations and
issues). I suggest we use one rather than try to cook up some heuristic
which will only sometimes work.

-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