Subject: RE: [midcom] Working group last call - STUN (security)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 01:07:54 -0500

I have a long (and belated) comment on STUN's security - I apologize in
advance for raising it only now, and for the fact that this particular point
was hashed out way back during the pre-midcom design team. Specifically, I
am concerned that CMS is a relatively heavyweight security system to
implement. For the most part, these concerns relate to the use of an
asymmetric key messaging system (including certificates) with a such a
low-level protocol. The general ASN.1 protocol overhead,  X.509 certificate
verification (including maintaining root certs on the client, etc), and the
extra TCP RTT required to download certificate chains from a server are a
relatively high cost to pay.

In Minneapolis, Jonathan suggested that implementing CMS would require 10-20
times the amount of code/effort that STUN itself would necessitate. CMS
might not be prohibitive for some applications, such as SIP, which have an
incentive to implement CMS already for S/MIME. However, I'd like to believe
that STUN has broader applicability than SIP, and that the comparative
complexity of the security implementation is therefore a cause for concern.
I fear mandating CMS might either limit the deployment of STUN or limit the
number of implementations that include STUN's security mechanism - both of
which are bad.

Some of the things that make me think CMS might not be the best fit are:

1) Certificate usage doesn't jibe well with the rest of the mechanism today;
so much so that switching to TCP for the certificate transport RTT is
recommended - it certainly wouldn't be ideal to require STUN entities to
implement TCP. One might recommend using CMS without certificates (just
public keys), but then its authentication story wouldn't be much more
powerful than using shared secrets.

As far as I can tell from the draft, and my conversations with some of the
authors, I suspect that each of the various ways in which a client might
discover a STUN server could also provide a means for a secret symmetric key
to be shared with the client. So for example, if the client is
pre-configured with the domain of a STUN server, it could also be
pre-configured with a shared secret at that time. Or if the STUN server were
discovered dynamically (say, on some kind of public matching service that
tracked STUN servers), a shared secret could be passed to the client by such
a matching service at the same time as the STUN server's address - this
assumes that transmitting the secret would require about the same amount of
security as transmitting the domain of the STUN server, which doesn't
immediately sound unreasonable. For example, protocols like SIP might pass
back a STUN server domain and accompanying secret in the application layer
(relying on their own security mechanisms to shield this information from
eavesdroppers). I would suggest that abandonning the complexities of CMS
more than compensates for any trouble associated with learning shared
secrets.

2) CMS really is pretty heavyweight, and it contains a lot of material that
is superfluous to STUN. Here follows the ASN.1 (yes, and having to do ASN.1
seems a little more annoying if you aren't already doing X.509) of the CMS
SignedData message (to which the CMS-SIGNED-DATA attribute in midcom-stun-00
is "exactly equal"):

SignedData ::= SEQUENCE {
  version CMSVersion,
  digestAlgorithms DigestAlgorithmIdentifiers,
  encapContentInfo EncapsulatedContentInfo,
  certificates [0] IMPLICIT CertificateSet OPTIONAL,
  crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
  signerInfos SignerInfos }

Although half of these are optional (including, for STUN, the
EncapsulatedContentInfo, which should be omitted in favor of an external
signature), there is still a lot of unnecessary and redundant material here
in compound objects. For example, SignerInfo above breaks down to:

SignerInfo ::= SEQUENCE {
  version CMSVersion,
  sid SignerIdentifier,
  digestAlgorithm DigestAlgorithmIdentifier,
  signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
  signatureAlgorithm SignatureAlgorithmIdentifier,
  signature SignatureValue,
  unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

Personally, I don't think STUN needs to identify the Digest algorithm at all
in the message - I think we could safely assume just one (MD5) and save
ourselves a few bytes. Similarly, all of the optional certificate-based
material above is unnecessary if you believe the shared secret based
approach described above is sufficient. We also don't need support for
multiple signers of the data (since only one STUN server is involved with
the generation and securing of a response). Filler material like versioning
on the SignedData is also probably unnecessary for STUN (though STUN should
probably have its own version field - but that's a separate issue). I think
STUN should use a much leaner, more stripped-down mechanism that delivers
only the security properties it needs.

3) Confidentiality doesn't seem useful for STUN, and one of the primary
reasons to use CMS is that it can provide confidentiality. That suggests
that a lot of the baseline CMS functionality (all of the EnvelopedData
message, for starters) is unnecessary. On the one hand, this could merely
suggest that a scaled-down profile of CMS should be built for STUN that uses
minimal SignedData only, but on the other hand it further shows that CMS has
a lot of versatility that STUN doesn't need, and that we might be able to
get away with an underlying framework that is more lightweight.

Given my suspicion that there will always be a way for a client to learn of
a shared secret for a STUN server, and given that the core security
properties required for STUN appear to be server-to-client authentication,
replay protection and integrity (no confidentality, no PKI-style
authentication), then it sounds to me like there are already security
systems that satisfy this set of requirements. A good example would be HTTP
Digest authentication (RFC2617). 

In broad strokes, applying HTTP Digest-style security to STUN would probably
entail the creation of a STUN attribute corresponding to RFC2617 'nonce' (in
a twist on HTTP, this attribute would probably be sent by the client in the
request for STUN, since the request is essentially the 'challenge'), as well
as the replacement of SMS-SIGNED-DATA with a much more lightweight STUN
attribute corresponding to the RFC2617 'response', for which the entity-body
would be the remainder of the STUN response. I don't immediately think we'd
need to change anything about the syntax or usage of COOKIE (although it
corresponds to the 'opaque' string in Digest, it would still be provided by
the STUN server). Of course, Digest values would no longer need to be
displayed as printable ASCII characters, which would create some savings
over the HTTP version. If it turns out that STUN could also use mutual
authentication, a STUN version of Digest could provide that as well with the
addition of a 'cnonce'-ish STUN attribute (which, again twisting HTTP, might
be sent by the server). Some behaviorial support for stale nonces would be
required as well - clients would have to resend requests with a fresh nonce
if they receive a server response with a stale nonce. Some language about
how shared secrets are created and managed server-side would also be in
order.

In summary, a STUN version of Digest looks like a more promising path to me
than CMS. I don't think it would be terribly difficult to specify these new
parameters even in the short term, drawing liberally on RFC2617. For a
protocol like STUN, I really think CMS is quite a burden. With a
lighterweight mechanism, maybe the STUN draft could even make the usage of
the security mechanism mandatory.

Jon Peterson
NeuStar, Inc.

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

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Apr 2002 08:47:38 -0400

At 01:07 AM 4/23/02 -0500, Peterson, Jon wrote:
>to be shared with the client.

We talked about the use of self-signed certs, and it's
probably not a good idea in this instance.  If you want to
make sure that you're talking to who you think you're
talking to without taking their word for it, you can't
trust their signature, either.  With the use of DNS, even
if you're capable of transporting the keys, you need a
secure mechanism to push them to the STUN server along
with the identity/credentials of the STUN client.  You 
also would need to trust your DNS server.  It would add 
a great deal of complexity, unfortunately.

Melinda

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 23 Apr 2002 10:17:57 -0500

Jon,

  As perhaps the only member of the pre-Midcom design team supporting the
option of a shared secret mechanism for STUN, I concur with you fully. In
fact, my proposal to my team memebers had been exactly the same as yours -
use a Digest-ish mechanism with two new STUN attributes, one for carrying
the 'challenge' (nonce) and the other for the 'response'. It was turned down
on the argument that anything less than public certs would hamper STUN
adoption, although I tend to think that its the opposite. What we would
likely see are many non-compliant implementations without any
authentication. I think that its feasible to have both the options in the
draft with the shared secret mechanism as the default. 

Sanjoy 

> -----Original Message-----
> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 1:08 AM
> To: [email-masked]'
> Subject: RE: [midcom] Working group last call - STUN (security)
> 
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Apr 2002 12:07:05 -0400

At 10:52 AM 4/23/02 -0500, Peterson, Jon wrote:
>To be clear, I'm not speaking to self-signed certificates (which would still
>require asymmetric keys, X.509 verification, TCP, the extra RTT, and incur
>all of the other penalties described in my note). I'm speaking to
>Digest-like password strings that would be shared by the STUN client and
>server, assuming that there is some way for such a shared secret to be
>communicated to the client - probably the same means by which the client
>learns the domain of the STUN server. 

How would you move keys between the discovery mechanism and the
STUN server?  What I'm concerned about here is that we'd be
creating another path which would require protection.

The problem here, as always, is how to get the keys to everybody
securely.  You can either front-load the processing using something
like STS (which still requires public key operations) or you can 
send down the whole package using something like CMS.  I'm not married 
to CMS, heaven knows, but we do need a solution that doesn't assume 
that keys are shared in advance.

Melinda

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 11:59:32 -0500

Well, as I suggested in my original note, a STUN server discovery mechanism
already requires security. If the domain of your STUN server is
pre-configured statically (you have a STUN server for your enterprise, say -
not a totally unlikely scenario), then of course a shared secret could be
provisioned at that time - presumably no security worries here. If the
domain is discovered dynamically through some protocol other than STUN, then
if that discovery protocol lacked security, attackers could (for example)
spoof a discovery in order to send a fake STUN domain to the client - a
serious problem, comparable to the threat that motivates STUN security. So I
say that if you assume a dynamical discovery mechanism at all, then it
already requires security. Having a dynamic STUN server discovery mechanism
also communicate the shared secret doesn't seem especially problematic to
me. In SIP, for example, it wouldn't be too arduous to communicate a STUN
domain and secret in a response header, and use SIP protocol security to
protect them.

So in short, while transmitting the secret requires security, so does
transmitting the domain of the STUN server. I also argued in my previous
that any amount of inconvenience we suffer on account of discovering secrets
is likely to pale in comparison with the implementation and operation of
CMS. I have a hard time not looking at CMS as a STUN killer.

Jon Peterson
NeuStar, Inc.

> From: Melinda Shore [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 9:07 AM
> To: Peterson, Jon; [email-masked]'
[snip]

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Apr 2002 13:35:09 -0400

At 11:59 AM 4/23/02 -0500, Peterson, Jon wrote:
>If the
>already requires security. 

STUN uses DNS SRV records for discovery.  We can do several
things:  1) rely on DNSSEC, which unfortunately is not widely
deployed, or 2) authenticate the entity whose address is
given to us by the DNS (which we'll have to do anyway).  Asking
the DNS to also distribute keys means 1) adding a new record type
to DNS (I believe), 2) having DNS servers generate keys, and 3) 
finding some way for DNS servers to propagate keys and identity
information to the STUN server as well as the STUN client.  I
don't think that's workable.

We have to be serious about securing STUN and make sure that
the security provides protection in typical deployment scenarios.
The problem we have to solve is this: we need for the server
responses to be authenticatable by the client and we absolutely
cannot assume the pre-existence of a relationship between the
client and the server.  Jonathan proposed CMS, which I don't
think is a terrible solution to that problem.  There may be
other, better mechanisms but I don't see how we can avoid 
requiring a PKI.  We absolutely cannot get around strongly
authenticated server responses.  Is it the size and structure of 
CMS messages that concerns you, or do you object to requiring
the involvement of a CA, or both, or something else entirely?
What if we were to do an authenticated Diffie-Helman and then
run a MAC over the packet?  We'd still need a PKI and to
execute public key operations, as well as more round trips, but 
we wouldn't face the same packet bloat problem that we would 
with CMS.

Melinda

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Apr 2002 10:48:29 -0700

Jon,

The problem with shared secrets is that you really don't want to share
them too many times, which implies that any secret would have to be
specific to a server-client pair. This in turn implies that STUN servers
need to actually identify their clients, which today they don't. I am
not sure that the cost of writing a provisioning system is less than the
cost of implementing CMS. In fact, we have to distinguish between the
client side and the server side.

On the server side, most server platforms that I can think off have
support for cryptographic operations, including certificate operations.
The development cost is not very high, since the ASN.1 stuff that you
object to is already there. There is an operation cost in actually
signing the responses, which may require some hardware support.

On the client side, there are really two cases. Some clients are using
platforms that already have cryptographic capabilities, and thus can
implement CMS without a problem. There may be a CPU cost in the
verification of the signature, but this cost is typically much less than
the actual production of the signature. The clients that do not have CMS
capability can also decide to just live dangerously, and not perform the
signature algorithm...

-- Christian Huitema

> Sent: Tuesday, April 23, 2002 10:00 AM
> To: 'Melinda Shore'; [email-masked]'
> pre-configured statically (you have a STUN server for your enterprise,
say
> -
> domain is discovered dynamically through some protocol other than
STUN,
> then
> serious problem, comparable to the threat that motivates STUN
security. So
> I

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 13:06:31 -0500

Some notes below. I think we may be speaking to slightly different points
here.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, April 23, 2002 10:35 AM
[snip]

> don't think that's workable.

I'm not talking about that kind of 'discovery'. I'm talking about the way
that you discover the STUN domain, not the way that once you have a STUN
domain, you resolve that domain to the IP address of a STUN server. I agree
that none of the DNS-based security systems above are likely to be material
in solving STUN's problems.

I would hope STUN will not be encouraged to make the self-limiting decision
that the domain of the a STUN server must be identical to the target domain
of the service (like SIP) for which STUN support is required. At least, I
haven't read any such limitation into the current draft. In fact, section
9.1 of midcom-stun-00 reads:

   Generally, the client will be configured with a domain name of the
   provider of the STUN servers. 

Again, it seems perfectly reasonable to me that when the client is
configured with a domain name, it could also be configured with a shared
secret - no security issues here. If, on the other hand, we assume there is
some dynamic means through which the client comes to learn the domain name
of a STUN service provider, then (as I have argued) we must acknowledge that
this dynamic means requires security of its own, regardless of whether it
needs to communicate shared secrets. 

DNS should not be a candidate for such a dynamic discovery mechanism,
anyway.

> client and the server.  

Then I presume you disagree with the statement in 9.1 of midcom-stun-00
above? And the alterantive is...?

> Jonathan proposed CMS, which I don't
> requiring a PKI.  

Actually, I believe that systems that use STUN might require PKI in only a
subset of its useful deployments. Again, in an environment in which the
domain of a STUN server can be meaningfully pre-configured (like an
enterprise for which there is a resident STUN server), I see no requirement
for PKI in support of STUN.

Dynamic STUN server discovery mechanisms might require PKI - but then again
they might not. That's a different problem; I don't see why the PKI should
be inflicted on STUN.

> We absolutely cannot get around strongly

I enumerated and expressed my concerns with CMS at some length in my
original message.  In summary, the most material concerns are:

- TCP: There is no reason why STUN should entail support for TCP. It does
now for certificate transport (due to NAT fragmentation of large messages).
- Extra RTT: The current mechanism requires an extra exchange of messages
between the client and server for certificate download (over TCP). That's
three RTTs to get started - that should be a warning sign.
- Cumbersome SignedData construction: The SignedData message format has
support for a lot of concepts (like multiple signators of a single block of
data) that STUN does not need, but for which STUN will pay the cost in
message size and complexity. It uses a lot of bytes for redundant data like
versioning and hash algorithm identification that we really don't need for
STUN.
- Confidentiality: STUN doesn't need it. CMS supplies it. This just further
illustrates that CMS is oriented towards a different set of requirements
than STUN.
- CA support: Maintaining one or more root certificates could be burdensome
for small clients. Verifying certificates with long chains could be
complicated for devices with little memory to work with. I would hope STUN
has applicability beyond expansive application-layer protocols like SIP.
- Certificates overall (self-signed or CA-based): ASN.1 parsing for X.509
(and SignedData too) as well as asymmetric key operations are intensive. If
they are unnecessary we should avoid them.

Most of all, echoing Sanjoy, I think CMS means that STUN security will
simply not be implemented, or worse yet that STUN overall will be passed
over. You can provide for the security requirements of STUN with a much less
elaborate system. We need CMS and PKI to secure a protocol that is basically
'echo'? Something's out of whack there.

I also think you need a security mechanism for STUN that can be made
mandatory. I doubt consensus could be achieved for requiring CMS.

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Apr 2002 14:23:01 -0400

>Some notes below. I think we may be speaking to slightly different points

I think we may be, as well.  I agree that CMS is big and
hairy.  I don't agree that we can change the question that
it answers.  We need to be able to authenticate server
responses when there's no pre-existing relationship between
the server and the client.  I'd be very happy to talk about
other mechanisms for solving that problem, but we can't opt 
out of addressing it.

Melinda

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 13:44:25 -0500

I agree that the real trick to this approach is coming up with a good
recommendation for the creation of the shared secrets. I'm not sure that in
practice, the creation of client-server pairs really means that STUN servers
need to identify their clients, but I understand what motivates your concern
there. However, I do think it's unfair to suggest that the complexity of
provisioning clients with shared secrets is comparable to the complexity of
CMS. Frankly, I imagine that provisioning non-PC clients with root
certificates for various CAs alone entails quite a bit more trouble than
provisioning shared secrets. And remember that according to midcom-stun-00,
you'll be provisioning each client with the domain of a STUN server anyway -
surely adding a shared secret at that time wouldn't result in any additional
complexity.

There might also be ways to cut down on 'personal' relationships between the
server and clients. Since I sent my initial note on this, I've been kicking
around a way to import the Digest concept of realms into STUN - all STUN
clients in a given realm might share the same secret with a STUN server. For
enterprise-style deployments (where a STUN service provider provides STUN to
several enterprises that are considered independent realms) this could be
meaningful. Interestingly, the threat against STUN described in the security
considerations of midcom-stun-00 has a limitation - the attack has to come
from outside the NAT when the NAT is full cone, and so perhaps users within
your own enterprise and realm, who use the same secret as you and are behind
the same NAT, might not have the opportunity to stage the attack. Needs more
thought, but it's one path we might explore.

On the client/server implementation issues, while I don't materially
disagree with your analysis below, I'm sure we both acknowledge that there
are undesirable costs, at a hardware level and a protocol level, that are
incurred for CMS support. I've been the first one to champion the use of CMS
when it is appropriate; for this application, though, it's a bit of an
albatross. CMS just isn't necessary.

Incidentally, recommending that smaller clients 'live dangerously' and not
verify CMS signatures is tantamount to saying 'don't implement security'.
This is exactly where I'm afraid CMS puts us.

Jon Peterson
NeuStar, Inc.

> From: Christian Huitema [mailto:[email-masked]]
> Sent: Tuesday, April 23, 2002 10:48 AM
> To: Peterson, Jon; Melinda Shore; [email-masked]
> > not a totally unlikely scenario), then of course a shared 
> secret could
> be
> > spoof a discovery in order to send a fake STUN domain to 
> the client -
> a
> > also communicate the shared secret doesn't seem especially 
> problematic
> to
> > domain and secret in a response header, and use SIP 
> protocol security
> to
> > protect them.
> > 
> > is likely to pale in comparison with the implementation and 
> operation
> of

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 13:50:18 -0500

And I must reiterate that midcom-stun-00 already assumes enough of a
pre-existing relationship that a client is provisioned with the domain of a
server - and if that's the case, that's all the relationship we need for the
client to also be provisioned with a shared secret. Why is the client
provisioned with some specific STUN server domain (the STUN service at
'atlanta.com'), rather than some other domain (the STUN service at
'biloxi.com')? Because the person provisioning the client has some
relationship with that particular domain. In whatever way that relationship
was forged, a secret could also have been communicated. There's no slight of
hand here, and I don't think this introduces any relationships amongst the
participants in STUN that did not already exist.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, April 23, 2002 11:23 AM
> To: Peterson, Jon
> Cc: [email-masked]'

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Apr 2002 16:01:10 -0400

At 01:50 PM 4/23/02 -0500, Peterson, Jon wrote:
>client to also be provisioned with a shared secret. 

I'm not sure I agree with your basic premise (pre-existing relationships),
and leaving aside, for the moment, scaling issues, key freshness is a serious 
issue with manually provisioned shared secrets and one that can't be
addressed in the scenario you describe.  

I think that we can probably agree that we can cut the overhead on the
packet down to adding an HMAC or digest, but the keying problem remains
and I'd really like to focus on that.  

Melinda

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Apr 2002 13:07:24 -0700

> pre-existing relationship that a client is provisioned with the domain
of
> a
> server - and if that's the case, that's all the relationship we need
for
> the

Not true. I can provision the client by copying the same string in each
of them, e.g. "stun.example.com." The string can be copied from a user
manual. Do you suggest to copy the shared secret from that same manual?

-- Christian Huitema

---

From: Melinda Shore <[email-masked]>
Date: Tue, 23 Apr 2002 17:20:39 -0400

Let me ask this: if we have to move to TCP anyway, why
not use TLS?  It's more chatty than the CMS proposal, but
it's got lower code overhead, less on-the-wire data
expansion, and it's something that people can implement
immediately.

Melinda

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Apr 2002 15:12:22 -0700

> expansion, and it's something that people can implement

You don't use TCP to request the mapping -- you can't, since you must
use the same UDP socket you will use for the application. You only use
TCP to fetch the oversized certificate list.

-- Christian Huitema

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 17:15:46 -0500

As for whether or not there's a pre-existing relationship between STUN
clients and servers - well, I'm just citing midcom-stun-00, and I'm
certainly not trying to take a hostile reading. Is there another way the
draft should be understood?

I think managing key freshness is not that scary when compared with using
CMS, considering that:

- You might also have to change your STUN domain periodically (for a while
there, the average lifespan of a web service provider seems to be about two
months) by reconfiguring your client. In some environments, it sounds like
people might even want to configure STUN on a per-service basis. In short, I
think you will already have to reconfigure STUN clients sometimes.
- My various passwords for Internet services change with some regularity
without radically inconveniencing me. Whether or not updating a secret is
inconvenient is an interface question. STUN servers could probably even push
fresh secrets to clients at intervals in a new STUN attribute, if we really
felt that we needed some STUN-specific way of keeping keys fresh.
- Additionally, certificates also have durations, get revoked, and so on. I
assume STUN clients will have support for certificate revocation mechanisms?
Using PKI doesn't make these problems go away - it just moves around the
pieces a bit.

I know this must be getting tiresome, but I feel compelled to place the
difficulty of confronting these problems in the perspective of implementing
CMS (and at the heart of it, PKI). If even Christian, one of the authors of
STUN, is recommending that clients forgo the STUN security mechanism, then I
hope you can see why I lean toward an alternative to CMS.

I do understand that I seem to be in a minority on this point, though.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, April 23, 2002 1:01 PM
> To: Peterson, Jon
> Cc: [email-masked]'

---

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 23 Apr 2002 17:18:35 -0500

As I suggested in a separate mail, there's no reason to think that a shared
secret system necessitates that each STUN client has a unique password; some
sort of realm-based system influenced by HTTP Digest could be used, in which
instance you would copy the same string into each client in an enterprise,
for example. I suspect that in some environments, a configuration manual for
an enterprise IT group that names a stun service provider (as you do below)
could just as easily name a secret. This once again comes down to the
question of why you provision one STUN service provider as opposed to
another. The fact that there is a particular STUN service provider that you
provision speaks, I believe, to some sort of relationship. Probably you (or
the entity you get services from) has a business relationship with the STUN
service provider. Or are we assuming that there is, after all, such a thing
as a free lunch? If money changes hands, so can secrets.

Jon Peterson
NeuStar, Inc.

> Sent: Tuesday, April 23, 2002 1:07 PM
> To: Peterson, Jon; Melinda Shore
> Cc: [email-masked]
[snip]

---

From: "Sanjoy Sen"<[email-masked]>
Date: Tue, 23 Apr 2002 17:30:17 -0500

> Sent: Tuesday, April 23, 2002 3:01 PM
  
> and I'd really like to focus on that.  

Don't our passwords change periodically and doesn't that make it pretty safe
if the passwords are properly generated? There's a trade-off between
complexity and the amount of goodies you would get in return.

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Apr 2002 12:10:30 -0500

This is closer to what I'd personally like to see, in so far as it takes the
burden of PKI off of STUN itself. But I would probably stop short of making
such a TLS password-download mechanism mandatory. There are at least two
cases I can think of that are meaningful STUN architectures which wouldn't
require any password download:

- Simple pre-configuration of secret - meaningful for enterprise STUN
servers

- Secret is passed by the application-layer protocol (for example, in a SIP
response header) for whose sake STUN is invoked, which presumably has its
own security, probably PKI-based - meaningful for STUN servers that are
operated by the provider of the application-layer service

So, I wouldn't object to allowing TLS (or something similar) as a way of
downloading a secret from a STUN server, as long as it is a MAY to
implement, it is separate from the remainder of the STUN protocol. STUN
itself has no need to become a secret-discovery protocol.

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, April 25, 2002 6:20 AM
> To: Cullen Jennings
> Cc: [email-masked]
> At 12:05 AM 4/25/02 -0700, Cullen Jennings wrote:
> >Is there any merit to something like using TLS to get a one time or short
> >lived password from the stun server for an anonymous user then use this
as
> >the shared secret for a digest based STUN? 
> 
> I think something like this may be the best approach, which is
> why I suggested using an authenticated Diffie-Helman the other
> day.  TLS may be overkill for this application, but there's
> a tradeoff here between time-to-implement and on-the-wire performance.
> Given that STUN is intended to be a short-lived, stopgap protocol
> we may choose to come down more on the side of time-to-implement.
> 
> Melinda
> 
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 25 Apr 2002 13:40:45 -0400

At 12:10 PM 4/25/02 -0500, Peterson, Jon wrote:
>burden of PKI off of STUN itself. 

I don't see PKI as a huge issue here, frankly.  We're not
requiring users to have certs, and the people who are likely
to be providing STUN services are already likely to have
certificates.

>But I would probably stop short of making

Mandatory-to-implement shouldn't imply mandatory-to-deploy.
If someone wants to run without authentication that's their
choice, but the protocol MUST provide protection against
the kind of active attack that's been identified.

>- Simple pre-configuration of secret - meaningful for enterprise STUN

I really think enterprise STUN servers are a terrible idea.  Again,
it's basically got all of the disadvantages of midcom with none of
the advantages.  To the extent that an enterprise might choose to
run a STUN server it might be helpful if it anticipates that NATted
hosts may wish to talk to it and it wants to provide reliable address
information, which brings us pretty much back to where we are.

>itself has no need to become a secret-discovery protocol.

I do not believe that this would pass IESG review.

I'm rather concerned that people are being casual about a clear
vulnerability with a simple attack against it. 

Melinda

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 25 Apr 2002 22:23:03 -0500

Some notes below. It would seem that you and I are once again ships passing
in the night here...

Jon Peterson
NeuStar, Inc.

> Sent: Thursday, April 25, 2002 10:41 AM
> To: Peterson, Jon
> Cc: [email-masked]
[snip]
> to be providing STUN services are already likely to have

The verification of a cert by the STUN client and the operations that
entails are the concern with this. Particularly the extra RTT to download
the cert, and the fact that TCP is needed for the extra RTT. And the other
things I mentioned in my previous mails. I see no reason why STUN, a
protocol that is comparable to echo, a protocol that tests NAT
configurations, needs to have some sort of certificate download and
verification apparatus. This would clearly be a lot of work.

> the kind of active attack that's been identified.

Yes, but preventing the active attack against STUN has little to do with
this matter of how you learn of shared secrets. There have been a couple of
ideas related to TLS on the list in the last day - one, to use TLS overall
for STUN authentication, and another, to use TLS to download a shared secret
from a STUN server that would subsequently be used for authentication. I was
speaking just to this latter point. I'm not suggesting running without
authentication - I was suggesting that sometimes, STUN clients may have
other ways of knowing passwords that they can use to authenticate STUN
servers without needing to use TLS to download them. Thus I think support
for the (proposed) TLS-based password download method should not be
mandatory.

> information, which brings us pretty much back to where we are.

An enterpise might also contract with a STUN server provider. This would
still allow for the pre-configuration of a secret. Whether or not the
enterprise actually operates the STUN server isn't really material to this.

> vulnerability with a simple attack against it. 

Again, declaring the TLS-based method of downloading the password as
optional does not mean that authentication of the STUN server would in turn
be optional. I was saying only that I thought there were useful STUN
architectures in which a TLS-based password download would not be necessary,
because the shared secret used for authentication could be learned in some
other secure fashion. I agree that the attack against STUN itself is
material - if I didn't, I wouldn't need to suggest any approach to STUN
security whatsoever.

---

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

>verification apparatus. This would clearly be a lot of work.

Here's the problem at hand: we need a mandatory-to-implement,
optional-to-deploy mechanism that protects *this protocol* against 
the hijacking attack when there's no pre-existing relationship between 
the STUN client and the STUN server.  If we're going to authenticate
the response from the server we need a good answer to the keying
question.  If we're not going to authenticate the response from the
server we need 1) something that provides a similar level of assurance,
and 2) a really good explanation describing *why* we think that what
we're doing is very secure.  

Melinda