Last Call Review of draft-ietf-behave-turn-

Request Review of draft-ietf-behave-turn
Requested rev. no specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-03-10
Requested 2009-01-13
Authors Philip Matthews, Jonathan Rosenberg, Rohan Mahy
Draft last updated 2009-03-13
Completed reviews Secdir Last Call review of -?? by Paul Hoffman
Assignment Reviewer Paul Hoffman
State Completed
Review review-ietf-behave-turn-secdir-lc-hoffman-2009-03-13
Review completed: 2009-03-13


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