Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data

Randall Gellens <randy@qti.qualcomm.com> Wed, 16 September 2015 00:58 UTC

Return-Path: <randy@qti.qualcomm.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 F39561B2FFE for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 17:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.311
X-Spam-Level:
X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JiF-Q1N31hyX for <secdir@ietfa.amsl.com>; Tue, 15 Sep 2015 17:58:43 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9545F1B2FFA for <secdir@ietf.org>; Tue, 15 Sep 2015 17:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1442365123; x=1473901123; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=jTBOPuJxK3AeyUleWaGHpN5psbuCQDJGkRPinsNMmwk=; b=Qihao/3yedU19QJkCEefiVnI27GiIpBX1G0TPOuWa2NbSkwiGcVr0KNZ sdta1Sj3Fjo8jZKWPNXxmAC8TQ6187Cnrh3yxozstXwKeLMdA5lLNxK0C jOrDO5uO1RQdOIccp6C60oBXYm2Y8LGgRFr9kE2hpa8ylZW4tXdIovC67 k=;
X-IronPort-AV: E=McAfee;i="5700,7163,7925"; a="138779972"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Sep 2015 17:58:43 -0700
X-IronPort-AV: E=Sophos;i="5.17,537,1437462000"; d="scan'208";a="1055554162"
Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 15 Sep 2015 17:58:42 -0700
Received: from [99.111.97.136] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 15 Sep 2015 17:58:41 -0700
Message-ID: <p06240610d21e68de6c17@[99.111.97.136]>
In-Reply-To: <CADajj4bzDNqCzaJSjviVZm1nk8CrbUopzj0PrNNOUcK9SNG1ZA@mail.gmail.com>
References: <CADajj4bzDNqCzaJSjviVZm1nk8CrbUopzj0PrNNOUcK9SNG1ZA@mail.gmail.com>
X-Mailer: Eudora for Mac OS X
Date: Tue, 15 Sep 2015 17:58:39 -0700
To: Magnus Nyström <magnusn@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-ecrit-additional-data@tools.ietf.org
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/8ue5qkqglGOULunOkLbVNPH2KGU>
X-Mailman-Approved-At: Tue, 15 Sep 2015 18:02:12 -0700
Subject: Re: [secdir] Secdir review of draft-ietf-ecrit-additional-data
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 16 Sep 2015 00:58:45 -0000

Hi Magnus,

Thank you for your review and comments.  Please see in-line.

At 9:26 PM -0700 8/31/15, Magnus Nyström 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 memo provides fundamental data structure 
> definitions and procedural rules for providing 
> auxiliary information to public service 
> answering points (PSAPs) when emergency calls 
> are being made.
>
>
>  This reads as an important memo and has been at 
> least five years in the making. I don't find 
> the Security (and Privacy) Considerations 
> section lacking per se, but do have these 
> questions:
>
>  - Why require HTTPS for the reference case but 
> not the value case (I can understand why you 
> don't require it for the value case, but 
> couldn't it be a choice for the PSAP also in 
> the reference case? This would also seem to 
> simplify during an introductory phase when a 
> wide-spread PKI solution is not yet in place.)?

I'm very surprised that a security area person is 
asking why we don't make TLS optional!  It's a 
valid question, of course, just surprising in 
this context.  Because of the limited scope of 
the document, specifically emergency services, 
and given that the dereferencing entities will be 
PSAPs and other responders that have upgraded to 
support next-generation, we felt that it was 
reasonable to require the use of TLS and 
client-side certificates for dereferencing.

>  - When HTTPS is required, I assume the PSAP 
> needs a client certificate - i.e., that the 
> mutual auth option of TLS is being used, 
> perhaps this needs to be clarified?

Yes, good point.  I added clarifying text in response to Ben's comments.

>  - Was there any discussion around any MTI TLS cipher suites?

No, this was never discussed as far as I can recall.

>  - I assume there's not only a privacy issue but 
> also a potential spoofing issue - the PSAPs 
> don't want to be overly susceptible to spoofed 
> calls (although they rather err on the side of 
> safety, of course. Thus, should integrity of 
> infomation in the direct case be considered? 
> I.e., by n/w or service providers in the path 
> to the PSAP vouching for the information?

You're absolutely correct that PSAPs are 
concerned about spoofed (and other false) calls 
but will generally err by taking a call and 
asking the caller for information.  In general, 
PSAPs prefer information that comes from known 
and trusted providers (the major carriers).  Are 
you suggesting a mechanism by which providers 
verify the information provided by the device? 
For location information, there are discussions 
in other SDOs about sanity-checking 
device-provided information (location or Wi-Fi 
APs) against network-known information (macro 
cell to which the device is associated).

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
In a sense, when we started Virgin Atlantic, I was trying to create
an airline for myself. If you try to build the perfect airline for
yourself, it will be appreciated by others. --Richard Branson, 1996.