[secdir] Secdir review of draft-ietf-radext-dtls-10

Brian Weis <bew@cisco.com> Fri, 25 April 2014 16:59 UTC

Return-Path: <bew@cisco.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 2A0331A0658; Fri, 25 Apr 2014 09:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.773
X-Spam-Level:
X-Spam-Status: No, score=-14.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 Yg80kfbCTXEb; Fri, 25 Apr 2014 09:59:28 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7753C1A063E; Fri, 25 Apr 2014 09:59:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1385; q=dns/txt; s=iport; t=1398445162; x=1399654762; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=IbFUam7/3J4/twefl9cOvvhA8LVXCYgfWJWCLdip/yg=; b=SNYdIsRUYzCDZTdINMZ7Pk4ggvsyLFo8WQFEy0614E/5T20r9SZ1hV5o OuDpiatleTaYVx6uI/J3WqBgPsIupZPb9lp36rpK6nXEQ7msDjKXEiYfU mt/x+7K8+GUjQpXxtMKnUf6ZOHcs6Z901Gb//wwnlseGEDJaqxTFzfxVU Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvoIADOTWlOrRDoI/2dsb2JhbABZgwarUZl0gRMWdIJmP4E+AYhSykIXhVqIf4MrgRUEiW2PGJJcg1Ed
X-IronPort-AV: E=Sophos;i="4.97,928,1389744000"; d="scan'208";a="111108386"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 25 Apr 2014 16:59:20 +0000
Received: from stealth-10-32-244-211.cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s3PGxJJN025066; Fri, 25 Apr 2014 16:59:20 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 25 Apr 2014 09:59:19 -0700
Message-Id: <BA0624E2-BF90-4709-81F0-99FBD9015E20@cisco.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/T8ltb_8qGJH9JLJBwC-MX662dkg
Cc: draft-ietf-radext-dtls.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-radext-dtls-10
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: Fri, 25 Apr 2014 16:59:31 -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 is a re-review; I last reviewed draft-ietf-radext-dtls-06. Reproducing my summary from that review: This document describes requirements and implementation details regarding using DTLS as a transport layer for RADIUS packets. It is a companion to RFC 6614 ("TLS Encryption for RADIUS"), and this I-D references many of the sections in that RFC rather than re-defining them. While the security considerations of encapsulating RADIUS in TLS and DTLS are very similar there are a number of operational issues where a UDP protocol is more advantageous than a TCP, and vice versa. Both documents are worth specifying; providing more secure alternatives to the simple RADIUS MD5 integrity checks is critical.

The current draft addresses my earlier comments, and is much improved due to other changes as well. I believe is ready to publish.

I noticed one nit in the "DTLS Data" definition (Section 5.1): s/variable which may information about/variable which may contain information about/.

Brian