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

From: [email-masked]
Date: Tue, 30 Apr 2002 14:10:15 -0400

Is there a sensitivity to replay attacks here?  An attacker sees one valid
exchange and then replay that for any further exchanges it sees. The client
would receive multiple messages with valid signatures.

"Christian Huitema" <[email-masked]>@ietf.org on 04/29/2002
05:47:23 PM

Sent by:  [email-masked]

To:   "Pete Cordell" <[email-masked]>, "Melinda Shore"
      <[email-masked]>
cc:   <[email-masked]>
Subject:  RE: [midcom] WGLC - Alternatives for 'securing' STUN

The threat that we want to mitigate is the faking of the STUN response
by a third party. This is in practice a relatively low level threat,
since this faking is only easy to engineer if the third party has access
to the same shared link as the user -- e.g. a public access wireless
link. But then, third parties with access to the shared link can do all
kind of other bad stuff, e.g. fake a DHCP server or play games with ARP.
If we use a heavy weight method to fight a low-level risk, there is a
great chance that nodes will just use the insecure behavior! So, I agree
that we need something simple.

When Melinda first mentioned "using STUN over TLS", I was very
dubitative: we need to send a UDP packet to the server in order to get
the mapping, so at first sight sending something over TLS does not help
us. However, after the recent discussion, I believe that we may be onto
something with the suggestion to use TLS. The behavior would be the
following:

1) Set a TLS connection to the STUN server.
2) Send request over the TLS connection, asking for mapping and id +
password pair, as well as a life-time indication.
3) Receive mapping, id and password from the server. Close the TLS
connection.

At this point, the client knows whether it is behind a NAT. It also has
an idea of the mapped address.

4) Send a UDP request to the server, mentioning the id.
5) Receive a UDP response from the server, signed using MD5 or SHA and
the password.
6) Check that the signature is correct; if not, ignore.

This simple TLS proposal has many advantages over the current
certificate based procedure. It does implicitly use certificates, since
they are needed to perform the TLS, but it does so through a widely used
procedure: implementation is simple. The signature of the UDP messages
is through a simple key hash, which requires less computation than a
public key operation, and is thus easier to sustain. The id and password
are chosen by the server, which means that some classic tricks can be
used, e.g.:

- embed a form of validity check in the id, which enables some
protections against denial of service attacks,

- algorithmically derive the passport from the id, which reduces the
state in the server to a simple master key -- whose validity can be tied
to the life-time of the id-password pair,

- make sure that the passwords are actually randomized, which thwarts
dictionary attacks against the keyed-hash algorithm.

By allocating a life-time to the password, the server can ensure that
there will be only one TLS exchange for many mapping requests, thus
limiting the overall cost of the system.

Overall, this looks like a plausible alternative to the currently
specified scheme.

-- Christian Huitema

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 30 Apr 2002 15:21:40 -0400

> would receive multiple messages with valid signatures.

Thats what nonces are for. They limit the window of opportunity for
replay attacks. In our case, since the nonce is client generated, you
can use one-time nonces and totally eliminate the possibility of replay
attacks.

-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