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