Subject: RE: [midcom] STUN last call

From: "Christian Huitema" <[email-masked]>
Date: Tue, 23 Jul 2002 09:49:28 -0700

Pete's idea makes sense, but there are a few issues. It really is a
trade-off between security and ease of operation.

> My main concern is that the default security mechanisms 
> require the server
> to be stateful.  This is undesirable and I think it can be 
> avoided with only
> minor changes.  This would involve the server supplying the TARGET-TID
> instead of the client.  The following sequence would result:
> 
> 1.  Client sends shared secret request over TLS.
> 
> 2.  Server returns TARGET-TID and corresponding TARGET-OTP to client.
>      The server can generate these as:
> 
>     TARGET-TID = random;
>     TARGET-OTP = HMAC_?( server_secret, TARGET-TID );
> 
> Being algorithmically related, a server does not need state.  
> Because both
> are supplied by the server, an attacker can't request the TARGET-OTP
> corresponding to a particular TARGET-TID.

This is one possible implementation. In fact, the current spec links the
"target-otp" to the client supplied transaction-id, TARGET-TID, which
means that you can implement the server exactly the same way:

	target-otp = one-way-hash(server_secret, TARGET-TID) 

This means that the server does not have to be stateful. The difference
between the current draft and Pete's proposal is really the lifetime of
the "target-otp": in the draft, we make it one transaction; in Pete's
proposal, there would be some long lasting "server supplied user-name",
and the secret would remain valid that long. Pete's proposal also have
the advantage of using server supplied TID, while the draft's proposal
might open the way for some clever attacks in which the client chooses
the "right" TID values.

The problem with a long-lasting secret is the need to recycle them
eventually, e.g. when the "server secret" changes. I presume that this
could be detected by an optimistic procedure: try to use the old account
+ secret, and if that fails, go get a new secret. We would need to
specify that too.

-- Christian Huitema

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

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 23 Jul 2002 11:04:31 -0700

It is important for the security that the OTP is not valid for a long time.

I agree with Pete that we want to be able to build a stateless server but as
Christian correctly points out below, it is possible to make a stateless
server without any changes to the current draft.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Christian Huitema
> Sent: Tuesday, July 23, 2002 9:49 AM
> To: Pete Cordell; [email-masked]; Melinda Shore
> Subject: RE: [midcom] STUN last call
>
>

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 23 Jul 2002 21:47:45 +0100

Christian,

(Glad it makes some sense.  I'm only just starting to feel I understand this
security stuff!)

One question that might have a bearing on the way to go is, what would
happen if you were using STUN to refresh the bindings in a NAT that didn't
have any active media for some reason?  Would you have to supply new TIDs
each time and potentially exhaust the cache of TARGET-TID / TARGET-OTPs
pairs you have collected, or would you use some other mechanism?  (I guess a
server having to MAC a response for which the client doesn't care about the
contents of would be quite expensive for the server, so an alternative
scheme might be desirable.)

Pete.

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: "Pete Cordell" <[email-masked]>; <[email-masked]>; "Melinda
Shore" <[email-masked]>
Sent: 23 July 2002 17:49
Subject: RE: [midcom] STUN last call

-- Christian Huitema

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 17:26:47 -0400

inline.

> might open the way for some clever attacks in which the client chooses

Actually, one need not be all that clever.

An attacker will see a STUN request flow by. It knows the transaction ID 
of this request, since its there in the clear. So, it connects to the 
server, sends a shared secret request with that target TID, and gets 
back the shared secret. It will be the same one used to build the HMAC. 
So, it can now freely modify the request and reconstruct a valid HMAC 
for it.

To avoid this attack, the OTP has to have the same properties as the 
session key that is used as part of the TLS connection; namely, it must 
be unguessable and be scoped to that particular connection. To achieve 
this, the server must hand out the target TID, as Pete has suggested, 
and furthermore, it must never hand out the same target TID for any two 
requests sent over different TLS connections.

Unless anyone objects or can think of a reason that this logic is wrong, 
I will update the draft with these requirements.

> + secret, and if that fails, go get a new secret. We would need to

The only requirement is that the server be able to obtain the shared 
secret from the TID within the timeframe over which the request will be 
sent. This should be on the order of a minute or two. The objective is 
not to allow a client to request TIDs and hold on to them for extensive 
periods of time. If you are worried about call setup delays for SIP, the 
TID acquisition can be done in parallel with the user input that results 
in the call. In the case of a sip hardphone, the minute the user picks 
up the phone, the phone can establish the TLS connection in preparation 
for obtaining TIDs. This process would normally complete before the user 
even presses the first button.

As such, I will add text stating that the client cannot expect the TID 
and its associated OTP to be valid for more than 2 minutes.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 17:29:12 -0400

Pete Cordell wrote:
> pairs you have collected, or would you use some other mechanism? 

As I have proposed in a separate email, to ensure a small lifetime for 
the passwords, you can't build up a cache of the TIDs and use them 
throughout the call. I have proposed 2 minutes as a lifetime. Thus, you 
would need to acquire new TIDs in this case.

  (I
> guess a

Why does the client not care?

-Jonathan R.

---

From: "Pete Cordell" <[email-masked]>
Date: Thu, 25 Jul 2002 14:26:22 +0100

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

> Why does the client not care?

You're right - It would only not care that the answer was unauthenticated if
the answer it got was the same as the previous authenticated answer.  If it
got a different answer, then it would care very much (NAT might have
re-booted).

Pete.

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