Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt

[Marc Petit-Huguenin <[e-mail]>]

Thanks Magnus and Juergen.  See comment inline.

Magnus Westerlund wrote:
> Juergen Schoenwaelder skrev:
>> On Wed, Oct 21, 2009 at 12:01:06PM +0200, Magnus Westerlund wrote:
>>  
>>> I do understand your confusion. RFC 5389 is STUN. TURN is an extension
>>> of STUN, and TURN mandates authentication. The default to use mechanism
>>> however, is defined in STUN, thus the reference to RFC 5389.
>> Thanks, now I understand this better. So does this wording describe
>> the situation correctly:
>>
>>    This is achieved for "turn" URIs by the Long-Term Credential
>>    Mechanism defined in [RFC5389], which is mandatory for TURN
>>    [RFCxxx]. For a "turns" URI, the usage of TLS addresses the
>>    requirement."
>>
>> Having both references would have helped me to understand the
>> situation better (showing my ignorance of TURN ;-).
> 
> Yes, I think that part is good.
> 
> I would note that TLS may not be sufficient for reaching the
> authentication goal. Only that is has the capability to reach them. But
> also for TLS you can use the Long-Term Credential mechanism to
> authenticate the user of a TURN server.

Here the modified proposed text that should address all your concerns.  Let me
know if this is OK:

"The Application Service Tag and Application Protocol Tags defined in
this document do not introduce any specific security issues beyond
the security considerations discussed in [RFC3958].  [RFC3958]
requests that an S-NAPTR application defines some form of end-to-end
authentication to ensure that the correct destination has been
reached.  This is achieved for "turn" and "turns" URIs by the Long-
Term Credential Mechanism defined in [RFC5389], which is mandatory
for TURN [I-D.ietf-behave-turn].  Additionally for a "turns" URI, the
usage of TLS has the capability to address the requirement."


-- 
Marc Petit-Huguenin
Personal email: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org