Subject: RE: [midcom] STUN last call

From: "Christian Huitema" <[email-masked]>
Date: Wed, 24 Jul 2002 17:51:28 -0700

> > I you go on updating the draft, then you should divorce the 
> two roles of
> > the TID, identifying the transaction for matching questions and
> > responses, and identifying the key used for securing the 
> transaction. If
> > the key is valid for 2 minutes, it will probably be used for several
> > transactions -- RTP and RTCP channels for audio and video 
> comes to mind.
> 
> So, you would propose a server-provided username, which would 
> be valid 
> for 2 minutes, which would be included in the binding request? The 
> server would then supply the username and the OTP to a client in the 
> Shared Secret Response message. I like this better.

Yes. I guess that is exactly what Pete asked for...
I would rather you call it "key-id" that "username". The server does not
know who the user it.

> We could also allow the server to specify the lifetime of the 
> username 
> in the shared secret response, allowing for longer lived 
> values than 2 
> minutes. Not sure if its worth the added complexity...

Don't go there!

-- Christian Huitema

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jul 2002 01:57:57 -0400

inline.

> I would rather you call it "key-id" that "username". The server does not

Not in this case, no.

However, Cullen Jennings had asked, during the midcom meeting, for the 
addition of a "username" attribute, optionally present in bind requests, 
to handle the eventual usage of non-TLS based shared secret mechanisms 
(i.e., a securid key or something). Seems like we can just use that 
field for this purpose.

>>minutes. Not sure if its worth the added complexity...

OK.

-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: "Pete Cordell" <[email-masked]>
Date: Thu, 25 Jul 2002 14:20:54 +0100

----- Original Message -----
From: "Christian Huitema" <[email-masked]>

Don't go there!

-- Christian Huitema

If we have a username or keyid that can be used multiple times, but we don't
want dynamic lifetimes, can we make the minimum lifetime of the keyid
longer, say 24 hours.  In my  mind creating a TLS connection per STUN
request (as a first approximation) seems a lot of work for the server.
There's various DH keys to be generated, public key operations, various key
material expansion, cryto on the messages, numerous round trips etc.  I
figure a TLS connection could consume maybe 4 or more times more processing
than a STUN binding request.  As a 16 byte key-id and key seems stronger
than many user-id/passwords protecting data on the net, a longer period
would seem beneficial to some servers without an major down side.

(Actually, I think a server specified lifetime doesn't sound that bad.  For
the server it can effectively be fixed text that it outputs.  The client
could either use it or ignore it.  - Easiest way would be to use volatile
store for the lifetime and key info.  If it re-booted within the lifetime,
it would just get a new key.)

Pete.

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