[secdir] secdir review of draft-ietf-speechsc-mrcpv2

Catherine Meadows <catherine.meadows@nrl.navy.mil> Sat, 10 July 2010 01:23 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17C243A6946; Fri, 9 Jul 2010 18:23:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyGPNuo9Tmiw; Fri, 9 Jul 2010 18:23:35 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id 929553A66B4; Fri, 9 Jul 2010 18:23:34 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.8/8.13.6) with ESMTP id o6A1NXkD004333; Fri, 9 Jul 2010 21:23:33 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.8/8.13.6) with SMTP id o6A1NQiU001670; Fri, 9 Jul 2010 21:23:30 -0400 (EDT)
Received: (from [IPv6:::1] [10.0.0.13]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2010070921232529951 ; Fri, 09 Jul 2010 21:23:26 -0400
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 09 Jul 2010 21:21:17 -0400
Message-Id: <51173F8E-94BF-4347-B7A8-909BA5433443@nrl.navy.mil>
To: iesg@ietf.org, secdir@ietf.org, sarvi@cisco.com, dburnett@voxeo.com, oran@cisco.com, eburger@standardstrack.com
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [secdir] secdir review of draft-ietf-speechsc-mrcpv2
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sat, 10 Jul 2010 01:23:37 -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 draft describes the Media Resource Control Protocol Version 2 (MRCPv2)
which allows client hosts to control media service resources residing in servers on a network.
MRCPv2 makes use of the Session Initiation Protocol (SIP) to initiate and manage sessions
and the Session Description Protocol (SDP) to manage and exchange capabilities.  Both clients
and servers rely on TLS for security.

Most of the security requirements for this protocol are similar to requirements for any protocol
that manages control data, some of which must be sensitive.  These are outlined in the Security
Considerations section.  MRCPv2 also supports the use of voice identification to support a limited
form of limitation: the identification of which member of a group a principal belongs to after the fact that
the principal belongs to the group has been ascertained by other means.  This is known as
Speaker Verification and Identification.

I found the initial discussion of Speaker Verification and Identification in Section 11 a little confusing,
and there is one sentence in particular that could be made more clear:

 The fourth  paragraph in that section begins:

Speaker identification is the process of associating an unknown
   speaker with a member in a population.  It does not employ a claim of
   identity.

But the paragraph immediately before that starts

In speaker verification, a recorded utterance is compared to a
   previously stored voiceprint which is in turn associated with a
   claimed identity for that user. 

That sounds like it *does* employ a claim of identity.

The fourth paragraph goes on to say that speaker ID should
be used when you already have verified that the speaker is a member
of a group (e.g. by cryptographic means), and you want to verify which
member of the group s/he is.  This suggests that

 It does not employ a claim of
   identity.

really means that 

It does not provide a proof of identity by itself.

If that is the case, it should say that.

I also note that the speaker verification is restricted to identifying the identity
of someone who is already verified to be a member of a group.  This suggests that attempting to use
it without this prior verification is unsafe.  A quick scan through RFC 4313 didn't turn up any references to this
issue.  If it is unsafe, then the ID should say so, and if there is a related requirement in RFC 4313 that should
be referenced.  Also, I would recommend saying that speaker verification MUST NOT be implemented without
prior verification as a member of a group.





Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil