Last Call Review of draft-ietf-tram-turn-third-party-authz-07
review-ietf-tram-turn-third-party-authz-07-secdir-lc-sheffer-2015-02-05-00

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 defines a mechanism where a STUN client can present an 


OAUTH token and get authorized to use a particular STUN server.




Summary

IMHO, the document is not yet ready to be published.

Details



• What is the motivation for this authorization? Is it intended to 


conserve server resources?






• What is HMAC-SHA-256-128? Is the output 128 or 256 bits long? Please 


include a reference.






• Maybe I'm confused, but it seems to me that the discussion immediately 


following Fig. 2 mixes the hash algorithm that signs the token itself 


with the algorithm that integrity-protects STUN messages. If they must 


be the same for some reason, please state it clearly.






• 4.1: there are obvious benefits to using an asymmetric key here, and 


in fact this can be done efficiently using elliptic curves (ECDSA). So I 


think the "MUST establish a symmetric key" is misguided.






• 4.1.1: the derivation of both keys seems to be the same, so are they 


identical?!






• 4.1.2: this interaction (a simple REST query to get a long-term key) 


is by default insecure, so I'm surprised to see it here with no comments 


about the need to encrypt it an authenticate the client.




• 4.1.3: please provide a reference for AES_256_CBC_HMAC_SHA_512.



• 6.1, last sentence: so an attacker who can disrupt communication to 


the AS can force the client to switch to 1st party authentication, which 


is easily susceptible to dictionary attacks?






• 6.2: the timestamp value is strange, specifically the fractional part. 


Why are fractions needed, do we think this improves security?






• 6.2 example: when using AES-256-CBC something must be said about 


padding and about the IV.






• 6.2, last sentence: the length of the nonce surely depends on the 


selected algorithm, and cannot be a constant 12.






• 8: Is the MESAGE INTEGRITY attribute itself mandatory? The client 


should reject messages if this attribute is not included.






• 9: if the server is allowed to cache access tokens, there must be a 


way for the client to refer to a token by name. Otherwise there may be 


confusion when tokens are expired and replaced by new ones, especially 


in the presence of dropped messages.






• 10: is the server required to cache old transaction IDs to avoid 


replay attacks? If this is the case, you need to mandate it explicitly.






• App. A: the mac_key as included in the token should be binary IMO, and 


not as shown here, encoded in base64.






• I suggest to rename "long term password" to "long term key" (and 


again, it should be binary).




• Similarly, the nonce should be binary.

Thanks,
	Yaron