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

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Oct 2009 11:46:03 +0200

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 20 Oct 2009 10:59:38 -0700

Hi Juergen,

Thanks for the review.  See my response below.

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Oct 2009 11:51:57 +0200

> Mechanism defined by [RFC5389] and additionally for a "turns" URI by

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Oct 2009 12:01:06 +0200

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

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 21 Oct 2009 12:27:52 +0200

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

/js

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Oct 2009 13:08:28 +0200

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

Cheers

Magnus Westerlund

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 21 Oct 2009 09:51:35 -0700

Thanks Magnus and Juergen.  See comment inline.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 22 Oct 2009 00:11:10 +0200

On Wed, Oct 21, 2009 at 06:51:35PM +0200, Marc Petit-Huguenin wrote:

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

Looks perfect to me.

/js

---

From: <[email-masked]>
Date: Fri, 23 Oct 2009 13:16:46 +0200

Marc Petit-Huguenin wrote:

> I propose to replace the second paragraph of section 6 by the
> following text.  Let me know if it addresses your comment:
> 

We probably need some additional text about TLS here.

The text in RFC 3958 asks for a very specific kind of "end-to-end"
authentication: the authenticated identity of the server must be the
same as the *input* to the S-NAPTR processing.

So if the URI was "turns:example.com", and the DNS records are as
follows:

  example.com. IN NAPTR 100 10 "S" "RELAY" "" turn.example.net.
  turn.example.net. IN SRV 10 0 10001 turnserver1.example.org.
  turnserver1.example.org. IN A 192.0.2.1

Then the server needs to present a certificate with name "example.com"
(NOT "turn.example.net" or "turnserver1.example.org").

Is this the intent here?

The reason behind this text in RFC 3958 is that otherwise an attacker
could just spoof DNS reply "example.com. IN NAPTR 100 10 "S" "RELAY"
"" turn.attacker.org.", and TLS wouldn't catch this.

(Basically the same thing occurs in HTTPS, of course. If the URI is
"https://www.example.com/", then the certificate must contain name
"www.example.com", even if DNS replies with "www.example.com. IN 
CNAME foo.attacker.org.")

Best regards,
Pasi

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 30 Oct 2009 07:32:16 -0700

Hi Pasi,

Sorry for the delay in responding to this.  See my answer inline.

> CNAME foo.attacker.org.")

Here's the new proposed text.  Let me know if this is OK for you:

"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.  In this
 case the client MUST verify the identity of the server by following
 the identification procedure in section 7.2.2 of [RFC5389]."

Thanks.