Subject: RE: [midcom] STUN last call

From: "Christian Huitema" <[email-masked]>
Date: Wed, 24 Jul 2002 14:52:01 -0700

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

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.

-- Christian Huitema

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

---

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

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

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

-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: "Bob Penfield" <[email-masked]>
Date: Wed, 24 Jul 2002 19:18:22 -0400

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

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

Would the TID be the username? If so, would you then have to add a separate
transaction id for matching requests and responses using the same TID and
shared secret? Also, would you get better replay protection by including
both the username and transaction id in the HMAC of the MESSAGE-INTEGRITY?

cheers,
(-:bob

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 24 Jul 2002 19:47:06 -0400

In section 8.1, 3rd paragraph, the last sentence says

   "The Binding Error Response is sent to
   the source IP address and port the Binding Request came from, and
   sent from the source IP address and port the Binding Request was sent
   to."

This sentence is a bit confusing. Should the second "source IP address" be
"destination" address. Or should the word "source" be dropped in both
places.

In section 10.3, 4th paragraph (1st on page 22), it says

   "This request contains a RESPONSE-ADDRESS, which is set to that mapped
   address learned from the previous Binding Response."

Should "set to that" be "set to the"?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Jul 2002 02:00:16 -0400

inline.

Bob Penfield wrote:
>>>>this, the server must hand out the target TID, as Pete has
>>>
> suggested,
> 
>>>I you go on updating the draft, then you should divorce the two
>>
> roles of
> 
>>>responses, and identifying the key used for securing the
>>
> transaction. If
> 
>>>transactions -- RTP and RTCP channels for audio and video comes to
>>
> mind.
> 
> Would the TID be the username? 

No. This was exactly what Christian was saying - decouple them.

> If so, would you then have to add a
> separate

No doubt. Everything is going to be HMACd.

-Jonathan R.