[Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls

"Joseph Salowey \(jsalowey\)" <jsalowey@cisco.com> Mon, 17 September 2007 05:26 UTC

Return-path: <emu-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX97z-0008Dy-Li; Mon, 17 Sep 2007 01:26:35 -0400
Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IX97y-00089F-B6 for emu-confirm+ok@megatron.ietf.org; Mon, 17 Sep 2007 01:26:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IX97x-00088d-V1 for emu@ietf.org; Mon, 17 Sep 2007 01:26:33 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IX97w-0007tO-ML for emu@ietf.org; Mon, 17 Sep 2007 01:26:33 -0400
X-IronPort-AV: E=Sophos;i="4.20,262,1186383600"; d="scan'208";a="176319161"
Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 16 Sep 2007 22:26:32 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l8H5QWRR017107; Sun, 16 Sep 2007 22:26:32 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l8H5QVuD018091; Mon, 17 Sep 2007 05:26:31 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Sep 2007 22:26:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 16 Sep 2007 22:26:36 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE5047D9C10@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Draft liaison response for IEEE 802.11u EAP method for emergency calls
Thread-Index: Acf461FVs0c21EfNQCqeQdMsSEkklQ==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: emu@ietf.org
X-OriginalArrivalTime: 17 Sep 2007 05:26:31.0578 (UTC) FILETIME=[4E2ACFA0:01C7F8EB]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3421; t=1190006792; x=1190870792; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20<jsalowey@cisco.com> |Subject:=20Draft=20liaison=20response=20for=20IEEE=20802.11u=20EAP=20met hod=20for=20emergency=20calls |Sender:=20; bh=kK/uAG74kvURfGLlCfLFED79shPapD7sIAtIh2VnYPI=; b=d5mIZchjpnzIdnAjHoycWTKqco9E7MVkm5HYbiSXD3X0EWP6r5hi7EfcHn2v3au1TiTZkOTl D5PpHB/el1QvL6/hzONpKSYHfu9uyK0+sMPjiF9y5pk8J3NmhcBN+8na;
Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: Bernard Aboba <bernard_aboba@hotmail.com>, ecrit-chairs@tools.ietf.org
Subject: [Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/emu>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
Errors-To: emu-bounces@ietf.org

The EMU working group has a liaison request from IEEE 802.11u on EAP
methods for emergency calls.  The liaison request can be found on the
liaison statement page, https://datatracker.ietf.org/liaison/ (May
2007).  We had a presentations and discussion of this topic at the
Chicago EMU meeting.  Below is a draft response based on the discussion
in the meeting.  It would be good to have comments on or approval of the
text by Monday, October 1, so a revised response can be created to be
sent as a response to the IEEE.  

==============================================================

802.11u Liaison response for EAP Methods for Emergency Communications 

We have had discussion of EAP method for Emergency services at the last
IETF meeting in Chicago.  The following is a summary of working group
discussion on this topic.  

Currently there are no standards track EAP methods that meet the
requirements as understood by the EMU working group.  There are several
possible candidates of existing EAP methods that may meet or be slightly
modified to meet some of the 802.11u requirements for emergency
services, especially if minimal latency is not the strongest
requirement.  TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST
(RFC4851) are TLS based methods that can support server only
authentication.  It was also pointed out that EAP-TLS
(draft-simon-emu-rfc2716bis-11.txt) could be modified to create a new
EAP method that only requires server side authentication.  In order to
truly support emergency services these methods would need to forego
server certificate validation which negates much of the security they
provide by allowing man-in-the-middle attacks.   These TLS based methods
also require a significant number of round trips that may not be
acceptable for emergency communication.  

There were also several questions raised in the working group during the
discussion that might help in further determining the best approach.
These are summarized below:

1) It is not clear how to make the tradeoff between security and
low-latency.  If there is not existing trust relationship there are
limits as to what security properties can be provided.  What security
properties are desirable and what is the tolerance for extra-round trips
for the communication?

2) PSK was described as having worse DOS resistance properties that EAP.
It seems that in many cases EAP would have worse DOS resistance that
PSK, which cases is EAP better?

3) It seems that most public access networks already provide an open
access network, why couldn't this network be used for emergency
communication? 

4) What regulatory requirements are driving the need for encryption?
This creates some conflicts because encryption without authentication
does not satisfy most useful security requirements. 

As the 802.11u group is certainly aware, there are other groups within
the IETF that are looking at unauthenticated emergency services.  In
particular, the ECRIT group within the IETF has ongoing work in this
area:

http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-acces
s-00  

We encourage IEEE working group members to continue the discussion with
the IETF in the EMU and the ECRIT working groups.


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu