Skip to main content

Last Call Review of draft-ietf-tram-turn-third-party-authz-07

Request Review of draft-ietf-tram-turn-third-party-authz
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-02-04
Requested 2015-01-22
Authors Tirumaleswar Reddy.K , Prashanth Patil , Ram R , Justin Uberti
I-D last updated 2015-02-05
Completed reviews Genart Last Call review of -08 by Christer Holmberg (diff)
Genart Telechat review of -11 by Christer Holmberg (diff)
Secdir Last Call review of -07 by Yaron Sheffer (diff)
Opsdir Last Call review of -08 by Tom Taylor (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-tram-turn-third-party-authz-07-secdir-lc-sheffer-2015-02-05
Reviewed revision 07 (document currently at 16)
Result Has Issues
Completed 2015-02-05
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.


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


• 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 


• 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.