Skip to main content

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

Request Review of draft-ietf-behave-turn
Requested revision 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 E. Hoffman
Assignment Reviewer Paul E. Hoffman
State Completed
Review review-ietf-behave-turn-secdir-lc-hoffman-2009-03-13
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

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