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

[Juergen Schoenwaelder <[e-mail]>]

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>