Subject: [secdir] Secdir review of draft-ietf-behave-turn-13

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2009 07:04:52 -0700

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.

First off, I apologize for the extreme lateness of this review; it was a calendaring failure on my part.

This document deals adequately with the security issues of the protocol. Basically, the document says that TURN servers will most likely rely on STUN's authentication mechanism, which is probably sufficient for most scenarios. For those scenarios that need more security (particularly encryption), TURN-over-TLS is defined in a fairly straight-forward fashion as an extension of STUN-over-TLS.

The security considerations section is much better than average, particularly for a protocol where it is likely that many implementers will probably punt on authentication and not even think about encryption wiht TLS.

Having said that, Figure 2 should be revised to show the expected chain of events *including* the STUN authentication. Without this, an implementer could be confused where the authentication would be. This is covered better in section 16, but should be shown in the early example as well.

I note that authentication in TURN is a SHOULD, not a MUST, but I think that is reasonable for the expected deployment scenarios for TURN. Also, only TURN requests, not indications, are authenticated; this is covered in good detail in the document. There is a very large number of security-related SHOULDs in the document that do not have "except where" clauses, but I didn't find any it wasn't clear that the clause would read "except where you don't really care about security anyway".

In section 4, it says:
   For each allocation, the server SHOULD generate a new
   random nonce when the allocation is first attempted following the
   randomness recommendations in [RFC4086] and SHOULD expire the nonce
   at least once every hour during the lifetime of the allocation.
I did not understand the one-hour expiration; more explanation here about why nonce regeneration is tied to an arbitrary time and not a session should be given (or, probably, this should be changed to actually tie the nonce regeneration to the end of the session).

--Paul Hoffman, Director
--VPN Consortium

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Mar 2009 10:16:51 -0400

Does this mean MUST implement and SHOULD use?

At 10:04 AM 3/11/2009, Paul Hoffman wrote:
>I note that authentication in TURN is a SHOULD, not a MUST, but I 
>think that is reasonable for the expected deployment scenarios for TURN.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 11 Mar 2009 08:11:23 -0700

>Does this mean MUST implement and SHOULD use?

Good question, and I think the answer is that the document does not *require* that authentication be implemented. That is, I couldn't find a place where it said one way or another. I will defer to the document authors to answer that one.

--Paul Hoffman, Director
--VPN Consortium

---

From: Philip Matthews <[email-masked]>
Date: Thu, 12 Mar 2009 19:18:36 -0400

On Wed, 11-Mar-09, at 11:11 , Paul Hoffman wrote:

> Good question, and I think the answer is that the document does not  
> *require* that authentication be implemented. That is, I couldn't  
> find a place where it said one way or another. I will defer to the  
> document authors to answer that one.

Section 4 (General Behavior) says:

    In addition, the server SHOULD demand that all requests from the
    client be authenticated, using the Long-Term Credential mechanism
    described in [RFC5389], and the client MUST be prepared to
    authenticate requests if required.

Thus clients will interoperate with a server, regardless of whether it  
requires authentication or not. There is no statement about what  
servers must implement, just what they should do. However, I think  
that most people recognize that the security of TURN is pretty poor  
without authentication, unless TLS transport is used.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 12 Mar 2009 19:51:03 -0400

Paul:

Thanks very much for your review. I am very glad to hear that TURN has  
good security. Security has been a concern of the authors and various  
members of the WG, however most of us do not have a strong security  
background.

See replies in-line.

On Wed, 11-Mar-09, at 10:04 , Paul Hoffman 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.
>
> This document deals adequately with the security issues of the  
> protocol. Basically, the document says that TURN servers will most  
> likely rely on STUN's authentication mechanism, which is probably  
> sufficient for most scenarios. For those scenarios that need more  
> security (particularly encryption), TURN-over-TLS is defined in a  
> fairly straight-forward fashion as an extension of STUN-over-TLS.

I will note that we don't expect TURN over TLS to be very popular,  
because the TLS session goes only from the client to the server, and  
does not cover the server-to-peer portion of the path. Any client at  
all concerned about security will encrypt its data, and thus the  
encryption provided by TLS becomes a second layer of encryption.  
Furthermore, the reliable in-order delivery mechanism of TCP is  
undesirable in many applications of TURN (e.g., VoIP).

TURN has been a work-in-progress for quite some time, and was actually  
started before DTLS was invented. The authors are well-aware that DTLS  
might be more appropriate for TURN, but have strongly resisted adding  
it to the base spec in the interest of finishing TURN while avoiding  
"feature creep".

>
>
> The security considerations section is much better than average,  
> particularly for a protocol where it is likely that many  
> implementers will probably punt on authentication and not even think  
> about encryption wiht TLS.
>
> Having said that, Figure 2 should be revised to show the expected  
> chain of events *including* the STUN authentication. Without this,  
> an implementer could be confused where the authentication would be.  
> This is covered better in section 16, but should be shown in the  
> early example as well.

I am confused by this request, as Figure 2 _already_ shows the STUN  
authentication (e.g., the 401 Unauthorized response). The only thing  
not included are the details of the credential exchange, but figure 2  
is in the Overview section where attribute details have been omitted  
from all the figures in order to focus on the high-level message  
exchange.

> think that is reasonable for the expected deployment scenarios for  
> TURN. Also, only TURN requests, not indications, are authenticated;  
> this is covered in good detail in the document. There is a very  
> large number of security-related SHOULDs in the document that do not  
> have "except where" clauses, but I didn't find any it wasn't clear  
> that the clause would read "except where you don't really care about  
> security anyway".
>
> In section 4, it says:
> I did not understand the one-hour expiration; more explanation here  
> about why nonce regeneration is tied to an arbitrary time and not a  
> session should be given (or, probably, this should be changed to  
> actually tie the nonce regeneration to the end of the session).

Note that what the above paragraph says is:
* For each TURN session, generate a new nonce at the start of the  
session,
* During the lifetime of each session, generate a new nonce at least  
once every hour.
The one-hour expiration was a late addition, mainly because we  
couldn't find any better guidance on how rapidly nonces should be  
expired. In the absence of more concrete guidance, one hour seems  
about right to us.

- Philip