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

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 01 February 2015 17:56 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6A1A8A7D; Sun, 1 Feb 2015 09:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cf8qjzEBHdJh; Sun, 1 Feb 2015 09:56:31 -0800 (PST)
Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863291A1A22; Sun, 1 Feb 2015 09:56:31 -0800 (PST)
Received: by mail-we0-f178.google.com with SMTP id k48so35277556wev.9; Sun, 01 Feb 2015 09:56:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=dx0iGSSkJ2EPHowTqD56IXgxQAonATMd5X5IrouwSdA=; b=CmmmdwjqQ+GTiTeT3xmMPfsi3DIhNdQV8SLOgb1bDYpr/rPzSjb1e+wNXklV9pxhnr iyCyj2kmqplNyYhCQAIVX1y7f4Ub3X6uKTMj/HpD7ruspnt4n6OgZ3Mofh8WZglzO0jt bQ75l8hf/Mxtnz9Vai8BgaBLNyVaLxkIYpeJjtB7OjUcThqvCfDH4UMc9VN+LlGuzRMb +Zgiq9GQ9mPngbM/8vBZRKIvaTeHqc1u8/wPTzmMVxzGSvrSUBKCvk/XPTifPsd+LxL5 QAm8dSJadWXVCCp01Zaw3uOoCSHswaW89NseMPGbjtchfkBQp9zydfCAMUp+cUcDC6FS 3raQ==
X-Received: by with SMTP id ua2mr34015527wjc.40.1422813390302; Sun, 01 Feb 2015 09:56:30 -0800 (PST)
Received: from [] (93-173-247-187.bb.netvision.net.il. []) by mx.google.com with ESMTPSA id s10sm1418051wjs.38.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Feb 2015 09:56:29 -0800 (PST)
Message-ID: <54CE68CC.2000409@gmail.com>
Date: Sun, 01 Feb 2015 19:56:28 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-tram-turn-third-party-authz.all@tools.ietf.org
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/-kkjAf6bCj9DsHf0h5ec-l2hPQg>
Subject: [secdir] SecDir review of draft-ietf-tram-turn-third-party-authz-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Feb 2015 17:56:33 -0000

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.