Last Modified: 2005-02-07
|Done||Requirements ID submitted to IESG for publication (informational)|
|Done||Submit Internet Draft(s) Analyzing Existing Protocols (informational)|
|Done||Submit Internet Draft Describing New Protocol (if required) (standards track)|
|Oct 03||Submit Drafts to IESG for publication|
|Sep 04||Work Group Last Call MRCPv2 specification|
|Oct 04||Submit MRCPv2 specification to IESG|
- Intro and agenda bashing
- Push to last call for MRCPv2 (draft-ietf-speechsc-mrcpv2-06.txt)
- Discussion of security issues on requirements (draft-ietf-speechsc-reqts-06.txt)
MRCPv2 (Sarvi Shanmugham)
- At version 06; includes
- Edits from last meeting
- IANA considerations section
- Security considerations section
- Clarifications and comments discussed on alias through 2/21/05
- Baggia Paolo: Comments, Part 1
- Jeff Kusnitz: Grammar weights issue
- Klaus Reifenrath: NLSML issues (partial)
- Resolved issues NOT included in rev 6:
- Baggia Paolo comments, part 2:
- Editorial remarks
- Negotiate a future alternative for NLSML, to allow the client to optionally specify the alternative as a mime-type.
- Cite the Semantic Interpretation spec, but do NOT add any additional text.
- SDP changes:
- Follow MMUSIC, per Magnus
- Dropped SCTP for lack of SDP mechanism to address it; propose to address it independent of the Speechsc WG
- IANA registrations: resource-types, method/event names, SDP proto values, SDP attributes, etc.
- Dave and Sarvi to review with IANA tomorrow (3/9)
- Open issues:
- Do we want DEFINE-LEXICON support in the recognizer? Proposed by Baggia Paolo; Sarvi has no opinion. Will close offline via the list.
- Security considerations (see below)
- Should expect draft ready for last call within 2-3 weeks.
SECURITY CONSIDERATIONS (Dave Oran)
- Have been holding up requirements draft for over a year.
- Principal concern (as voice, e.g., in CSTA Report): Using any biometric or any sort of speech recognition for speaker identification is a bad idea.
- Privacy: main concern is potential for large scale theft of voiceprints and concomitant privacy loss
- Security of protocols: usual questions about confidentiality, integrity and authentication/authorization
- Threats/vulnerabilities of speech as a biometric
- (Real) threats to SI/SV protocols:
- External threats (i.e. by unauthorized parties)
- Attacks can be foiled by well-understood means
- Speechsc employs
TLS encryption of the control channel
SRTP encryption of the media channel
Authentication/authorization of all elements
==> NOT an issue.
- Internal attacks: stealing the voiceprint DB or compromising the the server system, including its keying material
- Prudent to store the data encrypted to foil theft.
- But Speechsc is a protocol standard, so not clear what we need to do anything about this ... But many people think we must. So ...
- Do whatever is done with Radius!
- Replay and impersonation attacks
- Premise: Possession of a stolen voiceprint does NOT by itself enable impersonation, due to use of challenge-response protocols.
- Stephan (?) disputed that premise, in light of the ability to construct suitable responses given enough voice data. He suggested adding knowledge base on top of challenge-response -- e.g. "What's the name of your favorite pet?"
- Voiceprints of varying quality can be obtained by anything that can record your voice. So voiceprint used for SI/SV needs to be protected.
- Question: Is it really useful to requires servers holding voiceprints to be more secure than those holding speech recordings, especially if those recordings have meta-data allowing the source to be identified (e.g. calling phone number, logged in user id)?
- To be discussed on the list.
- Other issues:
- Implicit agreement that your identity can be ascertained by the participants?
- What about a secure session with explicit anonymity? Is SI out of line with common expectations of privacy?
- If indirect methods of id need to be thwarted, there are things like voice distorting devices that render the SI/SV impotent.
- Stephan (?) expressed skepticism as to the need for Speechsc to address these issues. Unfortunately, per Dave, the IESG is equally skeptical about biometrics and has thus far required these issues be addressed.
- Next steps:
- Further discussion of the above issues on the list.
- Work with Transport & Security ADs to resolve these issues.
- If needed, establish an ongoing "security advisor" function to help get closure on both the requirements and the MRCPv2 spec.