[secdir] SecDir review of draft-ietf-tram-turn-third-party-authz-07

[Yaron Sheffer <[e-mail]>]

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