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

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Sun, 01 February 2015 18:49 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEDE1A901E; Sun, 1 Feb 2015 10:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Level:
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGrzh-Kn64fA; Sun, 1 Feb 2015 10:49:35 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D734D1A9005; Sun, 1 Feb 2015 10:49:34 -0800 (PST)
X-AuditID: c1b4fb3a-f79116d000000fec-93-54ce753c029e
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.1A.04076.C357EC45; Sun, 1 Feb 2015 19:49:32 +0100 (CET)
Received: from [131.160.126.10] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.86) with Microsoft SMTP Server id 14.3.210.2; Sun, 1 Feb 2015 19:49:31 +0100
Message-ID: <54CE753A.1090904@ericsson.com>
Date: Sun, 1 Feb 2015 20:49:30 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>, IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, <draft-ietf-tram-turn-third-party-authz.all@tools.ietf.org>
References: <54CE68CC.2000409@gmail.com>
In-Reply-To: <54CE68CC.2000409@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUyM+Jvja5N6bkQg/cXJSw+rV3NZDHjz0Rm iw8LH7JYrLo/g92BxWPnrLvsHkuW/GTy+HL5M1sAcxSXTUpqTmZZapG+XQJXxrL1uQXrpCo+ Xr3H2sB4U6SLkZNDQsBEYvufP+wQtpjEhXvr2boYuTiEBI4wSrSfbmOHcFYzSrzZcYgRpIpX QFviyskXLF2MHBwsAioS804rgoTZBCwktty6zwJiiwpEScw+/4AVolxQ4uTMJywgc0QENjJK XO18yAySEBZwl5j4dgtYkZCAhsSHN/uYQGxOAU2JrV9ug+1iFjCQOLJoDiuELS/RvHU2M0S9 tsTyZy0sExgFZiHZMQtJyywkLQsYmVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBAbtwS2/ rXYwHnzueIhRgINRiYfXgP1ciBBrYllxZe4hRmkOFiVxXjvjQyFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGJelfXh25lyBrIV0JJ9qkuH6mXKrnWS1l/w2ruvju8NhfPH5lh31s/KY5xm4 LrmsMtknQ7LMvf9OvdOv7PJrL77u5X0rMP+Ea2bu9OutGTXrk43T3JazahtqMceqKLPaljyt 2xcbvCytM9jdPvWXcfsE5hCd9pxVjh1uLW6zXnc9XOj0kX+FEktxRiJQR1FxIgAbcvnFOwIA AA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/3FWf0QTH_vEH59WmAqz-42J-ptk>
Subject: Re: [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 18:49:37 -0000

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