[AVT] Review of draft-ietf-avt-profile-savpf-11

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 12 October 2007 13:34 UTC

Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgKf3-0003Gl-S8; Fri, 12 Oct 2007 09:34:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ig6xQ-0006XD-8X for avt@ietf.org; Thu, 11 Oct 2007 18:56:44 -0400
Received: from sca-ea-mail-4.sun.com ([192.18.43.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ig6xF-0001W4-TI for avt@ietf.org; Thu, 11 Oct 2007 18:56:40 -0400
Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l9BMuLTq029845 for <avt@ietf.org>; Thu, 11 Oct 2007 22:56:21 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l9BMuK7L015142 for <avt@ietf.org>; Thu, 11 Oct 2007 16:56:20 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l9BMuKl1027331; Thu, 11 Oct 2007 17:56:20 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l9BMuI39027330; Thu, 11 Oct 2007 17:56:18 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Thu, 11 Oct 2007 17:56:18 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: secdir-secretary@MIT.EDU
Message-ID: <20071011225618.GD24532@Sun.COM>
References: <Pine.LNX.4.64.0708021745120.8357@mint.samweiler.com> <Pine.LNX.4.64.0708210159390.17654@mint.samweiler.com> <Pine.LNX.4.64.0708232010510.8278@mint.samweiler.com> <Pine.LNX.4.64.0708301201550.5061@mint.samweiler.com> <Pine.LNX.4.64.0709061211040.10092@mint.samweiler.com> <Pine.LNX.4.64.0709131247260.3729@mint.samweiler.com> <Pine.LNX.4.64.0709201704090.3780@mint.samweiler.com> <Pine.LNX.4.64.0709290153220.4521@mint.samweiler.com> <Pine.LNX.4.64.0710041500580.10395@mint.samweiler.com> <Pine.LNX.4.64.0710111657330.14378@mint.samweiler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.0710111657330.14378@mint.samweiler.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
X-Mailman-Approved-At: Fri, 12 Oct 2007 09:34:41 -0400
Cc: fluffy@cisco.com, jon.peterson@neustar.biz, carrara@kth.se, secdir@MIT.EDU, avt@ietf.org
Subject: [AVT] Review of draft-ietf-avt-profile-savpf-11
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org

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 does not say whether it is intended to be on the Standards
Track, Informational, etcetera.  I assume it is intended to be on the
Standards Track.

Although some of the text in this document is somewhat confusing, has a
number of grammatical and other editing errors, and in many places fails
to expand acronyms, it is a simple profile of SRTP.  The security
considerations section covers all the areas that I think needed to be
covered, except, perhaps, two things.

In section 3.4 example #2 contains symmetric key material which, as the
description correctly states, requires confidentiality protection by
whatever channel is used to obtain the given session description.  Other
examples, such as example #1, might require at least integrity
protection, but this is not discussed.  It may be that they do not
require integrity protection, but I can't tell as I'm not an expert in
MIKEY (which was used in the example) and, in any case, other key
management frameworks can be used and some might require at least
integrity protection.  For example, when unauthenticated DH key
exchanges are used I would expect integrity protection by some other
channel to be required in order to prevent MITM attacks.  A small amount
of text should cover this case.

Additionally, it's not clear to me whether whether there are any
attributes of an SDP besides a=key-mgmt: and a=crypto: which might need
integrity and even confidentiality protection.  Additional text about
this would be good.

Nico
-- 

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt