Subject: [BEHAVE] TURN Issue: Changing the password during the lifetime of an allocation

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 18:11:11 -0500

On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote:
>
> 19. Section 6.2.2 paragraph 2:  "First, the request MUST be
> authenticated using the same shared secret as the one associated with
> the allocation."
>
> What happen if the user password is changed during an allocation?
>

I vaguely recall that we (the authors) discussed this question while  
we were working on TURN-05. Unfortunately, I cannot recall what we  
decided ... ;-)

Do people want the ability to change the password during the lifetime  
of an allocation? (Or, for example, is it sufficient to simply force  
the client to create a new allocation?

Assuming the answer is yes, then will the following scheme suffice?
* To change the password, the server is configured with two  
passwords: the old and the new. While so configured, it will accept  
either.
* The new password is then configured on the client, who immediately  
starts using the new password.
* Eventually the old password is removed from the server.

If this scheme is sufficient, then a sentence or two to mention it is  
all we need to do.

Comments?

- Philip

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Jan 2008 16:40:41 -0800

> > authenticated using the same shared secret as the one 
> > associated with the allocation."
> >

The same thing should occur for TURN that occurs when your password is changed
with other protocols (HTTP, IMAP, POP, SMTP AUTH):  leave it
undefined.  

-d

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 21 Jan 2008 09:22:33 +0200

Le Saturday 19 January 2008 02:40:41 ext Dan Wing, vous avez écrit :
> The same thing should occur for TURN that occurs when your password is
> changed with other protocols (HTTP, IMAP, POP, SMTP AUTH):  leave it
> undefined.

Agreed. I expect authentication will be offloaded to some kind of database 
subsystem mostly independent from the TURN server, especially as TURN has 
been designed to share credentials with SIP.

I miss the fact that I cannot use plaintext password over encrypted TLS by the 
way :( This prevent use of TURN with password database using different types 
of hashes for storage, especially those that cannot be "stolen" from the 
server.

-- 
Rémi Denis-Courmont