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

From: "Pete Cordell" <[email-masked]>
Date: Wed, 1 May 2002 10:42:24 +0100

Some of this debate might be academic now as I quite like Christian's
proposal, but ...

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>

> Sorry for my absence on this thread.... my email back log is enormous at
> the moment...
>
> Pete Cordell wrote:
> >
> > 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.
>
> 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.
>

Since STUN is not particularly useful in the symmetric NAT case, I don't
consider this a problem.

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

Without a lot of effort I'm not sure that you know that the server isn't
really run by the Iraqis.  They could advertise themselves as quiki-mart
stun servers inc, and appear totally genuine unless you did a full
background check.  It may only be months later that they start syphoning off
information.

If the STUN servers are provided by people like Yahoo and Google maybe
people can trust them as not being an Iraqi front.  Is that enough to trust
them?  Would I trust a server run by Microsoft for example?

> Indeed, your approach introduces a dos attack. I can
> run a server that always hands out incorrect mapped addresses. A client
> sends 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.

This is the problem that was bothering me also.  But then I didn't claim it
was a completely worked out solution.  The whole of security is about threat
and counter-threat, so the discovery of a particular type of attack is no
reason to stop looking for improvements.  If that were the case there would
be no cryptography today.

My premise is that if there is a chance of finding a solution that is an
order of magnitude simpler to do than a cryptographic one, then it is worth
spending a little time looking for it.

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

It all depends on whether the known limitations are considered problems or
not.  From discussions raised recently I got the distinct impression that
the limitations were a problem.  From what I see we do seem to be cooking up
other solutions on the fly with a little bit of this and a little bit of
that.  I have no problem with that, but don't tell me that one way is simply
selecting a standard solution from a manual and the other involves inventing
things.

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

Pete.

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

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

---

From: "Cedric Aoun"<[email-masked]>
Date: Tue, 7 May 2002 10:50:04 +0100

I agree with Jon, we should decouple the acquisition of the shared secret
from its usage in STUN.Since there are 2 methods for the acquisition of the
shared
secret it should be negotiated thru STUN. I think that Sanjoy proposed to
use the
STUN flags for that, but didn't see any comments on it.

Cedric

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 30 April 2002 22:11
To: 'Christian Huitema'; Jonathan Rosenberg; Melinda Shore
Cc: [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

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 - that
suggests to me right off the bat that mandating TCP for STUN might limit the
potential applicability of the protocol. I hope, Christian, that your
ambitions for this protocol are also larger than just SIP.

As far as I can tell (since this question was raised), the main difference
between Christian's proposal and mine is that Christian wants to mandate a
particular way of acquiring the shared secret, a way that I find a little
too expensive (still comparable to the original CMS mechanism, really). I
have a hard time seeing why the acquisition of the shared secret is not a
separable issue - though I agree there is a requirement that the acquisition
itself be appropriately secure. I see no immediate incentive to mandate any
single way of acquiring a secret.

But aside from that, I haven't detected any opposition to the actual use of
the shared secret in STUN. I think agreement on how exactly this shared
secret will be used (i.e. one-way or mutual auth, etc) should be our first
important work item in exploring this proposal. I think this question of how
you learn of keys should be a subsequent work item. In fact, I suspect a
proposal along Christian's lines would best be designed as a separate
protocol unrelated to STUN.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, April 30, 2002 12:40 PM
> To: Jonathan Rosenberg; Melinda Shore
> Cc: [email-masked]
> Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN
> 
> 
> > 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, 07 May 2002 10:19:56 -0400

At 10:50 AM 5/7/02 +0100, Cedric Aoun wrote:
>secret it should be negotiated thru STUN. 

If you're going to negotiate security mechanisms you need to
provide protection against negotiation-down attacks.  It also
seems to me that putting in more protocol mechanism, more bits 
on the wire, and more round trips in order to avoid putting
in more protocol mechanism, more bits on the wire, and more
round trips while making the protocol less secure is probably
not a good tradeoff.

Melinda

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 8 May 2002 12:13:44 -0500

I also have a hard time understanding the need to negotiate a security
mechanism within STUN if we adopt this shared secret approach. Acquiring the
shared secret dynamically rather than statically would not require any
negotiation within STUN as far as I can tell.

Jon Peterson
NeuStar, Inc.

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, May 07, 2002 7:20 AM
> To: Cedric Aoun
> Cc: [email-masked]

---

From: "Sanjoy Sen"<[email-masked]>
Date: Wed, 8 May 2002 14:52:16 -0500

So, are you suggesting that the client can tell at the time of STUN server
discovery whether it has a pre-shared secret or not with the server (
service provider domain)?

> Sent: Wednesday, May 08, 2002 12:14 PM
> To: 'Melinda Shore'; Aoun, Cedric [QPD:MA01:EXCH]
> Cc: [email-masked]
> > >from its usage in STUN.Since there are 2 methods for the 
> acquisition of
> the
> > >shared

---

From: "Sanjoy Sen"<[email-masked]>
Date: Wed, 8 May 2002 15:28:02 -0500

Do we've a rough consensus on moving forward with the shared security
approach for STUN? Echoing Jon, let's keep the dynamic/static download of
shared secret separate from STUN and figure out the syntax/semantics for the
new STUN attributes - realm, client/server nonce, response etc - that might
be needed.

Talking offline with Allison at the SIP/SIPPING Interim meeting this week,
she seemed to think that the shared secret approach was perfectly reasonable
solution for STUN security What I heard was that  - from the IAB point of
view, they would want to discourage STUN clients go hunt out arbitrary STUN
servers in the public Internet in the absence of widescale PKI deployment.
Allison, please correct me if I mis-represent your views in any way. 

Thanks,
Sanjoy

---

From: Melinda Shore <[email-masked]>
Date: Wed, 08 May 2002 16:51:05 -0400

At 03:28 PM 5/8/02 -0500, Sanjoy Sen wrote:
>Do we've a rough consensus on moving forward with the shared security approach for STUN?

No (if what you mean by "shared security" is pre-provisioned symmetric
keys).

Melinda

---

From: "Sanjoy Sen"<[email-masked]>
Date: Wed, 8 May 2002 16:34:32 -0500

I just meant "shared secret". Whether it is statically provisioned or
dynamically generated/downloaded is, IMO, outside the scope of STUN. I would
prefer not to use STUN to download a shared secret. 

What I meant was if we agree on the shared secret part and on a
challenge/response mechanism to do authentication, then the relevant
attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt. This
work can be progressed independent of the shared secret provisioning
mechanism. 

Thanks,
Sanjoy

> Sent: Wednesday, May 08, 2002 3:51 PM
> To: Sen, Sanjoy [NGC:B692:EXCH]; [email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 8 May 2002 15:32:55 -0700

I believe that using a pre-existing shared secret in STUN is very
unsafe. We must have a procedure within STUN to download a secret.
Without a safe way to download the secret, then I would rather stick
with the current text, i.e. CMS.

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Wednesday, May 08, 2002 2:35 PM
To: 'Melinda Shore'; [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

I just meant "shared secret". Whether it is statically provisioned or
dynamically generated/downloaded is, IMO, outside the scope of STUN. I
would prefer not to use STUN to download a shared secret. 

What I meant was if we agree on the shared secret part and on a
challenge/response mechanism to do authentication, then the relevant
attributes/semantics need to be added to draft-ietf-midcom-stun-00.txt.
This work can be progressed independent of the shared secret
provisioning mechanism. 

Thanks, 
Sanjoy

---

From: "Cedric Aoun"<[email-masked]>
Date: Thu, 9 May 2002 09:37:09 +0100

Melinda, 
You have a valid point, that introducing negotiation mechanisms within STUN
will introduce more threats to deal with.
The decision on whether to use TLS or not could happen at other layers, i.e.
the STUN client could know in other ways that it doesn't have any shared
secret with a particular STUN server and therefore decides to use TLS to
download the shared secret from it; if it doesn't support TLS nothing
happens (that's life !).

I think we need to look at the scenarios where STUN will/could be deployed
(at least imagine them):

-All network based free multimedia apps combined with instant messaging
S/W(Yahoo IM, MSN, AOL ...), a pre-shared secret is defined by the user

-Internet content sharing communities (Limewire, Kazaa, Bearshare, Morpheus
...), currently don't require STUN; they may in the future and nothing
prevents that they create user profiles at some point and therefore a
pre-shared secret will need to be configured to secure the access to the
profile (same one to be used in the context of STUN security)

-Enterprise apps, pre-shared secret will be used when enterprise owns the
STUN server

-Carrier managed services, service provider will provide the shared secret
during service registration and web based application allows renewal of the
shared secret

Again since the acquisition of the shared secret is decoupled from its
usage, nothing prevents TLS to be used in the above scenarios.
Cedric

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: 08 May 2002 19:14
To: 'Melinda Shore'; Aoun, Cedric [QPD:MA01:EXCH]
Cc: [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

Jon Peterson
NeuStar, Inc.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 09 May 2002 10:31:20 -0400

At 04:34 PM 5/8/02 -0500, Sanjoy Sen wrote:
>I just meant "shared secret". Whether it is statically provisioned or dynamically generated/downloaded is, IMO, outside the scope of STUN. I would prefer not to use STUN to download a shared secret. 

Here's the problem:  you have the plaintext and you have the hash.
In that context reusing keys is a very, very bad idea.  We also should
care about interoperable implementations.  IETF protocols typically do
try to specify how keying is to be performed.

If security were easy the world would be a very different place, and if
you all were putting as much effort into securing STUN as you are into
avoiding securing STUN we'd end up with something pretty good.  In
the meantime, I feel very strongly that if we're going to knowingly
create a security exposure it's our responsibility to try to protect
the user against it (particularly when it's a high-value attack, like
being able to eavesdrop on every telephone call someone makes).  We can 
strike a balance between complexity and convenience, and
I think the notion of reaching key agreement or even just a key 
download over a TLS-secured channel is something that's relatively
easy to implement and provides reasonable key protection.  We're still
open to alternatives, but they have to provide a degree of security that
isn't trivial to compromise.

Melinda

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 9 May 2002 16:32:16 -0500

I still don't see how this prevents us from working on STUN extensions
needed for the challenge/response mechanism with shared secret. What I'm
asking is to create the placeholder in STUN to allow this mechanism - i.e.,
nonce, realm, response - all these attributes. This is orthogonal (in my
mind) to how the secret is shared. Later on, if we agree (have a consensus)
to add the 'secret download' capability in STUN, that would be one more STUN
extension (probably another new attribute). 

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Wednesday, May 08, 2002 5:33 PM
To: Sen, Sanjoy [NGC:B692:EXCH]; Melinda Shore; [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

I believe that using a pre-existing shared secret in STUN is very unsafe. We
must have a procedure within STUN to download a secret. Without a safe way
to download the secret, then I would rather stick with the current text,
i.e. CMS.

-----Original Message-----
From: Sanjoy Sen [mailto:[email-masked]] 
Sent: Wednesday, May 08, 2002 2:35 PM
To: 'Melinda Shore'; [email-masked]
Subject: RE: [midcom] WGLC - Alternatives for 'securing' STUN

Thanks, 
Sanjoy 

> From: Melinda Shore [ mailto:[email-masked] <mailto:[email-masked]> ]

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 9 May 2002 16:44:43 -0500

> Sent: Thursday, May 09, 2002 9:31 AM
> 
> 
> >I just meant "shared secret". Whether it is statically 
> provisioned or dynamically generated/downloaded is, IMO, 
> outside the scope of STUN. I would prefer not to use STUN to 
> download a shared secret. 
> 
> In that context reusing keys is a very, very bad idea.  

Can you articulate what are the possible threats that you see? You gave an
example threat of 'known plaintext attack' in your message:
http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02189.htm
l

which can be countered using both client side and server side
(sufficiently-randomly-generated) nonces as described by Jonathan's message
flow in the message:
http://www1.ietf.org/mail-archive/working-groups/midcom/current/msg02200.htm
l
and as also discussed in RFC 2617 Section 4.9.

So what're the other threats?

Thanks,
Sanjoy

---

From: Melinda Shore <[email-masked]>
Date: Thu, 09 May 2002 18:00:33 -0400

At 04:44 PM 5/9/02 -0500, Sanjoy Sen wrote:
>which can be countered using both client side and server side (sufficiently-randomly-generated) nonces as described by Jonathan's message flow in the message:

I'm still not clear on why you'd want to send down a nonce but
not a password, and why you want to do a handshake in STUN but
not in a password-sharing mechanism.  If you've got a good key HTTP 
digest is overkill and if you've got a crappy key no mechanism is 
good enough.

Melinda
-- 
Melinda Shore
Strategic Cryptographic Development
Cisco Systems
[email-masked]

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 9 May 2002 17:20:50 -0500

Because, we want to avoid the TLS handshake that would add more roundtrips,
avoid the DH or RSA key exchange and avoid any Certificate download. 

Actually, if I use TLS (or in the same matter IPSec tunnel, as Cedric has
proposed), then I would create the secure transport/tunnel and send all STUN
messages using that.  That's surely an overkill, but an option.

Sanjoy

> Sent: Thursday, May 09, 2002 5:01 PM
> >which can be countered using both client side and server 
> side (sufficiently-randomly-generated) nonces as described by 
> Jonathan's message flow in the message:
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 09 May 2002 18:38:38 -0400

At 05:20 PM 5/9/02 -0500, Sanjoy Sen wrote:
>Because, we want to avoid the TLS handshake that would add more roundtrips, avoid the DH or RSA key exchange and avoid any Certificate download. 

You're still assuming pre-provisioned symmetric keys.  That's
not a reasonable assumption.

>Actually, if I use TLS (or in the same matter IPSec tunnel, as Cedric has proposed), then I would create the secure transport/tunnel and send all STUN messages using that.  That's surely an overkill, but an option.

You can't use TLS for this.  Also, with regard to IPSec, 1) ESP NULL
does no source authentication, and 2) it brings us back to the keying
problem - how would you key SAs between a STUN server and an unaffiliated
client absent a PKI?

Melinda

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 9 May 2002 18:22:36 -0500

> Sent: Thursday, May 09, 2002 5:39 PM

> >Because, we want to avoid the TLS handshake that would add 
> more roundtrips, avoid the DH or RSA key exchange and avoid 
> any Certificate download. 
> 
I don't understand. The exchanges required as described above are
unavoidable if you use TLS. The TLS handshake protocol itself comprises of
at least 8 messages exchanged (& depending on situations, it can be more) -
clientHello, serverHello, serverHelloDone, clientKeyExchange (RSA or DH),
clientChangeCipherSpec, clientFinished, serverChangeCipherSpec,
serverFinished.