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

[Magnus Westerlund <[e-mail]>]

Hi Jurgen,

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.

Magnus

Juergen Schoenwaelder skrev:
> On Tue, Oct 20, 2009 at 07:59:38PM +0200, Marc Petit-Huguenin wrote:
>> Hi Juergen,
>>
>> Thanks for the review.  See my response below.
>>
>> Juergen Schoenwaelder wrote:
>>> I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG.  These comments were written primarily for the benefit of the
>>> security area directors.  Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>>>
>>> The document introduces the turn: and turns: URI schemes. The security
>>> considerations point to the relevant documents, one of them being RFC
>>> 3958. Section 8 of RFC 3958 states that S-NAPTR application protocols
>>> "should define some form of end-to-end authentication to ensure that
>>> the correct destination has been reached." I think it would be useful
>>> to spell how TURN meets this or whether there are reasons why TURN
>>> does not need such a sanity check. (1-2 sentences should be enough.)
>> I propose to replace the second paragraph of section 6 by the following text.
>> Let me know if it addresses your comment:
>>
>> "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 by the mandatory Long-Term Credential
>> Mechanism defined by [RFC5389] and additionally for a "turns" URI by
>> the usage of TLS."
> 
> I checked RFC 5389 and it says:
> 
>    This section defines two mechanisms for STUN that a client and server
>    can use to provide authentication and message integrity; these two
>    mechanisms are known as the short-term credential mechanism and the
>    long-term credential mechanism.  These two mechanisms are optional,
>    and each usage must specify if and when these mechanisms are used.
> 
> Since this sounds optional, I am confused now since your text talks
> about a _mandatory_ Long-Term Credential Mechanism. Questions:
> 
> - Is the Long-Term Credential Mechanism mandatory or optional? RFC 5389
>   sounds like it is optional - any other documents I am missing?
> 
> - If it is optional in RFC 5389, is it sufficient to say "This can be
>   achieved by the optional Long-Term Credential Mechanism defined by
>   [RFC5389] ..."? (The problem with this is that someone deploying
>   things can be out of luck doing the right thing if implementations
>   do not support doing the right thing.)
> 
> - Or, if it is optional in RFC 5389, should the security
>   considerations of the URI scheme require implementation of the
>   Long-Term Credential Mechanism, that is making implementation
>   mandatory for usage with turn URIs?
> 
> /js
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------