[secdir] Secdir review of draft-ietf-ecrit-trustworthy-location-09

Brian Weis <bew@cisco.com> Tue, 25 March 2014 00:27 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 377141A0012; Mon, 24 Mar 2014 17:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aHZLR5q2IbWB; Mon, 24 Mar 2014 17:27:54 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFF1A000F; Mon, 24 Mar 2014 17:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2849; q=dns/txt; s=iport; t=1395707274; x=1396916874; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=AbFXxX2D0R/Xb0g2FIWq5c02NmQMgaSBB1aWbZYYPlA=; b=Ejs9zvSdVIWGASmaXSkpms9mX5R7F3EM8oAupgtfYiYmkRGbSqayFXcO 9QQ+u5Ge2NdkGa4vUx77N4G2ItbkmZnDDWn8FL68JJHeF6/o3r5HfvScc 9LbUknFJBt/j9N4RxL4lZbNoLIYUObB4sCVxL74O14GLe/jn5kRJdD9fu A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFANvMMFOrRDoI/2dsb2JhbABQCYMGqwGZB4EjFnSCZj8tfRQBLYddzy0Xjh9bgyuBFASJUo54hkyLZYNNHQ
X-IronPort-AV: E=Sophos;i="4.97,723,1389744000"; d="scan'208";a="108933493"
Received: from mtv-core-3.cisco.com ([]) by mtv-iport-2.cisco.com with ESMTP; 25 Mar 2014 00:27:53 +0000
Received: from [] ([]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2P0RrmD006732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Mar 2014 00:27:53 GMT
From: Brian Weis <bew@cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Mar 2014 17:27:53 -0700
Message-Id: <20EA5EFD-036D-4924-A206-849FE0B5B0BE@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/FgWQN5TN-bYZsrafKthOGhhGvYI
Cc: draft-ietf-ecrit-trustworthy-location.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-ecrit-trustworthy-location-09
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: Tue, 25 Mar 2014 00:27:56 -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 document identifies a number of threats and attacks when location data associated with an IP-based emergency services emergency service call. Three types of adversaries are identified, however only threats from malicious end host adversaries are addressed in this document. That is, adversaries which are themselves malicious, with or without the the awareness of the owner. Two types of threats from malicious hosts are discussed: location spoofing, where an adversary provides false location information in an emergency call; and identity spoofing, where a false network access identity or caller identity is claimed.

The document is useful and generally ready to publish. But I have the following suggestions that would improve reader comprehension.

Section 3 describes three "Solutions", which are perhaps better termed "Techniques to Mitigate Threats". I say this because each "Solution" lists caveats in the use of each technique, and there seems to be extant threats in each case. This is not a criticism of the proposed solutions, but rather a recognition that the document clearly states in each case that there are factors not in control of the LIS and/or Location Recipient that can reduce the trustworthiness of the location and/or identity information. So they are more properly mitigations, not solutions.

With the above comment in mind, the Abstract seems to overclaim a bit when it says "This document describes how to convey location in a manner that is inherently secure and reliable." It might be better to say something like "This document describes techniques that improve the reliability and security of location information conveyed in a IP-based emergency services emergency service call."

Section 5 "Security Considerations" contains a lot of good additional information on the consequences to attacks on emergency services, but for a document limiting itself to threats from hosts attacking the system I'm not sure why it discusses denial of service attacks to the infrastructure and attacks on the mapping architecture. This section could be clearer if this discussion was either removed or its relevance made clearer.

The definition for "Target" in Section 1.1 is a particularly important definition for this document but the definition is not actually present. It would benefit from a brief explanation of the term rather than just a pointer to RFC 3693!