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

From: [email-masked]
Date: Fri, 26 Apr 2002 09:01:26 -0400

Waiting is not a significant problem if he concern is that the connection
is going to be hijacked. The connection can go ahead  on the reception of
the first message and if a later illicit response is received the
connection can be broken.  The connection can be made using an alternative
server. Missing responses, it could be argued are not a problem since there
will undoubtedly be many interactions between the client and a server a a
real situation. One occurrence of  an attempt at theft would be enough to
disqualify the server.

I too apologise if I am belabouring the point. The issue is not to secure
the protocol but to have means to protect the user from a specific type of
attack. If this can be done by a simple method that does not require an
elaborate cryptographic implementation then I don't see why it would be a
bad thing to toss a few simple ideas around. Indeed, the idea of using a
certificate system to identify the server seems to me only an indirect and
possibly uncertain means of security against a theft attack. The client
could securely authenticate the server that steals its connections.

Melinda Shore <[email-masked]>@ietf.org on 04/26/2002 07:42:38 AM

Sent by:  [email-masked]

To:   "Pete Cordell" <[email-masked]>
cc:   <[email-masked]>

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

At 12:19 PM 4/26/02 +0100, Pete Cordell wrote:
>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.

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

_______________________________________________
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: "Christian Huitema" <[email-masked]>
Date: Mon, 29 Apr 2002 14:47:23 -0700

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

---

From: Randy Turner <[email-masked]>
Date: Mon, 29 Apr 2002 15:57:16 -0700

In the STUN server SSL connection procedure, the STUN server is going to
provide a certificate to the client, correct?  How much certificate
validation would be required by the client to properly "trust" the
certificate? How would the client be provisioned with "trusted root certs"?
This seems like a fair amount of code, on top of the TLS/SSL wrapper. But I
agree that it is probably less than the previously mentioned certificate
method(s).

Randy

-----Original Message-----
From: Christian Huitema
To: Pete Cordell; Melinda Shore
Cc: [email-masked]
Sent: 4/29/02 2:47 PM
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

 

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 29 Apr 2002 17:14:40 -0700

Validating the certificate of TLS servers is pretty standard stuff --
you check that the name on the certificate is the one you expect, and
that it has been issued by an authority you trust. A default list of
trusted authorities + keys can be programmed in the device -- for
example, there is one shipped with every copy of Windows. We could
rat-hole for a long time about the actual trust one should give to these
authorities, but remember what is at stake: the mapping of an IP
address, not the transfer of billions of dollars...

-- Christian Huitema

> From: Randy Turner [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 3:57 PM
> To: Christian Huitema; 'Pete Cordell '; 'Melinda Shore '
> Cc: [email-masked] '
> This seems like a fair amount of code, on top of the TLS/SSL wrapper.
But
> I

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 29 Apr 2002 19:27:36 -0500

Well, requiring TLS support would require that STUN clients implement TCP.
And certificate processing. And do some complicated asymmetric key
operations. TLS adds significantly more RTTs (ClientHello, etc - TLS set-up)
to the total count than the previous CMS-based mechanism, although
admittedly the TLS Record Layer is probably bless intensive than CMS on a
per-message basis. Overall, I would still consider this to be a relatively
heavyweight system.

Of course, a heavyweight, PKI-based mechanism to deliver a shared secret to
a STUN client might be useful in some architectures. I think we should
acknowledge, though, that there are other reasonable ways that a shared
secret might be communicated to a STUN client. STUN's job as a protocol
should be to use that shared secret in the STUN authentication process,
regardless of how clients happen to learn the secret. 

I believe that such a TLS-based mechanism to acquire shared secrets, if we
were to design it, should be optional for STUN clients, and indeed it
doesn't even need to be part of the STUN protocol at all. I'd be surprised
if there wasn't some pre-existing mechanism in the IETF portfolio of
standards for the secure downloading of shared secrets in this sort of
fashion - and if not, I'd suggest this work should be undertaken as a
separable mechanism tooled to this purpose rather than some sort of
extension grafted onto STUN.

Either way, there would be some independent STUN protocol work to be done to
show how such a shared secret could be used in the STUN authentication
process. I think that is work that should be undertaken regardless of
whether or not TLS will be used to communicate these shared secrets. Is the
midcom WG going to develop a timetable for examining work along these lines?

Jon Peterson
NeuStar, Inc.

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Monday, April 29, 2002 2:47 PM

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 30 Apr 2002 12:11:08 -0500

IMO, we should have support for both the options - (1) an (out-of-band)
pre-shared secret based mechanism, and (2) a TLS based shared-secret/mapping
download mechanism (Huitema's proposal), with (1) being mandatory to
implement and with (2) supported by servers who would accept STUN requests
from unknown clients. 

The client would first attempt (1) by setting a flag in the STUN request
(indicating its preference for shared secret mechanism) and sending a
challenge in the same request. If the server has a shared secret matching
the challenge, then it would respond with the MAC in the STUN response. If
the server doesn't have a shared secret with the client and it accepts
requests from unknown clients, then it would set the flag in the STUN
response to a value indicating that it doesn't have a shared secret with the
client but it accepts STUN requests from clients with whom it doesn't have a
pre-shared agreement. Its upto the client to decide whether it would accept
the mapping (in this STUN response) or set-up a TLS session with the server
to download the shared secret, lifetime and the mapping.

The reason I'm arguing for having both options (and many times in the past
I've heard that multiple security options are bad), is that there would be
many many scenarios where a pre-shared secret would exist (and be adequately
maintained) between the client and the service provider that can simply be
reused for STUN authentication. On the other hand, I do acknowldge that as
many situations without an apriori association would also exist. So we
probably need both. 

Sanjoy

> Sent: Monday, April 29, 2002 7:15 PM
> To: Randy Turner; Pete Cordell ; Melinda Shore 
> Cc: [email-masked]
> > In the STUN server SSL connection procedure, the STUN 
> server is going
> to

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 30 Apr 2002 12:19:13 -0700

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

The STUN protocol already incorporates a 128 bit transaction ID, which
is a random number selected by the client and copied in the response.
The signature covers that number, which provides a very efficient
protection against replay attacks.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 30 Apr 2002 12:17:41 -0700

> Options are a generally a bad thing, and in security they can
> be a very, very bad thing (_pace_ IKE).  They can lead to
> interoperability problems, negotiation-down attacks, and
> increased complexity in implementation and testing.  In this
> case we don't need to worry about a negotiation-down attack, but
> we should be aware that given what this protocol does it's highly
> vulnerable to a known-plaintext attack.  That would be mitigated by,
> at a minimum, not reusing keys.

It is true that in any key-hash signature algorithm, the attacker sees
the plain text and the hash. Using a user generated password as key
material in this context would be very weak, since user generated
passwords can fall to dictionary attacks. This is the reason why I
proposed that the server provides the user with a password, which could
well be a 128 binary string of appropriate randomness -- it does not
have to be user friendly. It would be extremely hard to reverse this
kind of key, even if you know the plaintext. I don't think we have to
worry about that.

-- Christian Huitema

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 30 Apr 2002 14:40:19 -0500

TLS does use a public key system (probably RSA) to protect the generation of
session keys (using something like AES). But just to be clear from an
overhead perspective, that AES session key will actually secure the payload
(i.e. the STUN protocol running over TLS) in Christian's example, including
the STUN-specific shared secret. So in other words, TLS for STUN-shared
secret acquisition would use a public key to negotiate a session key in
order to secure another session key.

My argument against CMS was never that it was insecure, just intensive, both
on the wire and to implement. This TLS proposal has the necessary security
properties, but it is also probably overkill. I still think it could be
presented as an option (in some environments you'll get TLS for free, and
your STUN server's economy won't be upset by the additional overhead of
processing TLS set-up) - but again, surely that won't be true in all
environments.

Jon Peterson
NeuStar, Inc.

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 5:58 AM
> To: Peterson, Jon
> Cc: [email-masked]
> At 07:27 PM 4/29/02 -0500, Peterson, Jon wrote:
> >STUN's job as a protocol
> It's probably more common than not that public keys are
> used to protect sessions that are created to either reach
> key agreement or simply send keys (public key cryptography
> being more expensive computationally than symmetric key
> cryptography), and Christian's proposal is very much in
> keeping with how keying is done in IETF and other protocols.
> 
> Are there other opinions on this proposal?
> 
> Melinda
>

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 30 Apr 2002 12:39:34 -0700

> However, I am still confused about whether this proposal (TLS to
obtain
> shared secrets) solves the problems Jon raised. It does not eliminate
> the need for TCP, certs, or any of the other "heavy" stuff. If you
allow
> for provisioned shared secrets rather than using TLS to obtain a
> short-lived one, it does solve his objection of the need for PKI under
> all conditions, although all servers would need to implement it for
> sure...

The main advantage of the TLS proposal is that you can reuse well known
software components, and also that you perform a lesser number of public
key operations. In a SIP context, TLS is pretty much a "must implement"
anyhow, so I don't think it creates a particular burden to the endpoint.

<soapbox>
I don't know whether Jon really believes that he can go away with a UDP
only implementation of SIP, but if that is the case the security of STUN
should be the least of his concerns. SIP over UDP can be attacked in
dozen of creative ways, without even having to resort to fake STUN
messages.
</soapbox>

-- Christian Huitema

---

From: Melinda Shore <[email-masked]>
Date: Tue, 30 Apr 2002 15:59:16 -0400

At 02:40 PM 4/30/02 -0500, Peterson, Jon wrote:
>the STUN-specific shared secret. 

Not exactly - a TLS channel would be established for key
agreement, and the key would then be used to calculate an
HMAC for the UDP-transported STUN answer packets.

>properties, but it is also probably overkill. 

Yes and no.  Keying is generally the hardest thing to get
right when using crypto technologies, so we shouldn't be
surprised that it's an issue in this case.  We know there's an
easy-to-implement security exposure here and we really do
have to protect against it.  Visualize your reaction if
there were a report in the trade press that company <XXX>
released a product that had an obvious security flaw that
it knew about in advance and chose not to correct.  I don't
want to give away the moral authority to snark at other
people's security goofs.

Melinda

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 30 Apr 2002 15:35:40 -0500

I support Jonathan's call flow below for using the Digest-like approach.
HTTP Digest provides adequate protection against chosen plain-text attack
(which is deemed worse kind of attack than known plain-text) by using
'cnonce' or client nonce as shown in the call flow below. These nonces are
sufficiently randomly generated for every transaction to make-up for the
inadequecy of long-lived secrets.

For TLS you still have to perform the RSA or Diffe-Hellman key exchange,
which is processing intensive. The minimum number of messages exchanged is,
I think, eight. The server will download certs unless anonymous DH is used.
In short, TLS brings a lot of excess baggage, which should be avoided if not
required.

So my proposal would be to-
1) Make Digest (with both client and server nonce) mandatory
2) Support TLS when its needed (i.e., when there's no shared secret) and the
server is willing to build an security association on the fly.

Thanks,
Sanjoy

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 2:33 PM
> To: Melinda Shore
> Cc: Christian Huitema; [email-masked]
> Melinda Shore wrote:
> > At 12:17 PM 4/30/02 -0700, Christian Huitema wrote:
> > I don't think we need to worry about it with your proposal
> > (while acknowledging that there are some really, really terrible
> > random number generators out there).  We do need to worry about
> > it with long-lived pre-shared keys.
> 
> Agreed its a problem with long-lived pre-shared keys. That problem can
> be mitigated using a four-way handshake:
> 
>       request
> C --------------> S
>    response w/ server nonce
> C<-----------------S
> 
>    request w/ hash over (secret,server-nonce), client nonce
> C----------------> S
> 
>    response w/ hash over (secret,client-nonce)
> C<---------------- S
> 
> of course, the hashes also include the content of the message 
> as well as
> the nonce and secret. This is full mutual-auth, and is the 
> same flow as
> used by http digest for that purpose.
> 
> 
> However, I am still confused about whether this proposal (TLS 
> to obtain
> the need for TCP, certs, or any of the other "heavy" stuff. 
> If you allow
> -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: "Sanjoy Sen"<[email-masked]>
Date: Tue, 30 Apr 2002 16:31:13 -0500

Even in the shorter term, STUN is applicable for H.323, Megaco, MGCP, RTSP -
many of these clients would not support S/MIME or TCP.

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 4:16 PM
> To: Peterson, Jon
> Cc: [email-masked]
> On Tue, Apr 30, 2002 at 03:11:03PM -0500, Peterson, Jon wrote:
> > Actually, I think STUN has applicability beyond SIP - if STUN were
> > SIP-specific, I wouldn't have raised any concerns about CMS (since
> > personally I would like to encourage all SIP entities to 
> support S/MIME).
> > But STUN is really targeted at a whole class of UDP applications 
> 
> Before we start thinking about whole classes of UDP applications,
> let's remind ourselves that developing STUN is interim work.  Taken
> from the charter:
> 
> "In the interim, a solution is needed that allows applications to
> operate in the presence of midcom-unaware middleboxes. To support
> this, the midcom group will develop or document a protocol or approach
> that allows clients to indirectly obtain address bindings from midcom-
> unaware middleboxes, through communications with server elements on
> the public side of the middlebox. The key goals for this effort are
> rapid delivery of a simple solution (since it is an interim solution),
> consistency with the midcom framework, and security. In particular,
> any proposed interim approaches will address (and document) the
> architectural and pragmatic concerns described in [UNSAF]."
> 
> The architectural and pragmatic concerns that are documented in
> http://search.ietf.org/internet-drafts/draft-iab-unsaf-conside
rations-01.txt
are meant to apply to this work.  In particular, see Architectural
Considerations (Section 4.) bullet 1.:

  Precise definition of a specific, limited-scope problem that is
  to be solved with the UNSAF proposal.   A short term fix should
  not be generalized to solve other problems; this is why  "short
  term fixes usually aren't".

				regards,
					Ted Hardie

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 30 Apr 2002 16:34:21 -0500

Agreed - but the charter doesn't call out to SIP or any other application in
particular. The short term problem that the charter does suggest we are
fixing is application traversal of midcom-unaware middleboxes. I was merely
suggesting below that we not artificially restrict this problem to SIP - I
think we would in that case fall short of the chartered goal.

Personally, I think STUN has a great UNSAF story - it doesn't increase the
value of middleboxes in any obvious way, it only addresses NAT traversal
(rather than 'firewall traversal' of questionable legitimacy), it has a good
exit strategy... well, and everything else that is already recounted in the
UNSAF considerations of the STUN draft. Applications other than SIP that run
over UDP deserve to be able to use STUN for NAT traversal.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, April 30, 2002 2:16 PM
> To: Peterson, Jon
> Cc: [email-masked]
> > personally I would like to encourage all SIP entities to support
S/MIME).
rations-01.txt

				regards,
					Ted Hardie