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

[Gonzalo Camarillo <[e-mail]>]

Thanks for your review, Yaron.

Authors, please provide Yaron with responses to the comments below.
Also, please involve the WG if you need to make a significant change in
order to address any of the comments.

Cheers,

Gonzalo

On 01/02/2015 7:56 PM, Yaron Sheffer wrote:
> 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