Subject: [Ecrit] [Fwd: [Emu] Draft liaison response for IEEE 802.11u EAP method for emergency calls]

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 22 Sep 2007 15:23:03 +0200

FYI

-------- Original Message --------
Subject: 	[Emu] Draft liaison response for IEEE 802.11u EAP method for 
emergency calls
Date: 	Sun, 16 Sep 2007 22:26:36 -0700
From: 	Joseph Salowey (jsalowey) <[email-masked]>
To: 	<[email-masked]>
CC: 	Bernard Aboba <[email-masked]>, [email-masked]

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 furtFrom [email-masked] Sat Sep 22 09:24:55 2007
Date: Sat, 22 Sep 2007 15:23:03 +0200
From: Hannes Tschofenig <[email-masked]>
To: ECRIT <[email-masked]>
Subject: [Ecrit] [Fwd: [Emu] Draft liaison response for IEEE 802.11u EAP
 method for emergency calls]

FYI

-------- Original Message --------
Subject: 	[Emu] Draft liaison response for IEEE 802.11u EAP method for 
emergency calls
Date: 	Sun, 16 Sep 2007 22:26:36 -0700
From: 	Joseph Salowey (jsalowey) <[email-masked]>
To: 	<[email-masked]>
CC: 	Bernard Aboba <[email-masked]>, [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 22 Sep 2007 15:23:11 +0200

FYI

-------- Original Message --------
Subject: 	[Emu] RE: Draft liaison response for IEEE 802.11u EAP method 
for emergency calls
Date: 	Mon, 17 Sep 2007 10:20:25 -0700
From: 	Bernard Aboba <[email-masked]>
To: 	[email-masked], [email-masked]
CC: 	[email-masked], [email-masked]

It is not clear to me whether the requirements do in fact prohibit 
server-side authentication.  As you note, without server-side authentication 
man-in-the-middle attacks are possible;  however, even with server-side 
authentication, additional requirements may need to be imposed in order to 
provide the desired level of security.

Requirement #1 is "No Pre-configured trust relationship".  This could refer 
to pre-configuration of the server with respect to the expected client 
credential (PSK or certificate), or it could refer to pre-configuration of 
the client with respect to the server, (such trust anchors).  The text seems 
focused on the former more than the latter.  Assuming that clients can be 
pre-configured with trust anchors, then TLS-based EAP methods could meet the 
requirement.

Requirement #2 is "Small" number of messages.  While this requirement 
clearly excludes long exchanges, it is not clear to me that TLS-based 
methods are excluded, particularly if the method is to be implemented on the 
AP itself, which potentially would result in lower round-trip times and 
eliminate the possibility of AAA-based frame loss.

It may be possible that requirements #1 and #2 are compatible with proposals 
involving unauthenticated client access combined with server authentication. 
  However, due to lack of a pre-configured network access profile, this 
scenario presents additional threats that are worthy of further discussion.

The presentation refers to the desire to for confidentiality (presumably at 
L2, rather than using SRTP).  Where confidentiality is desirable, it will 
also presumably be important for the client to determine that it has 
connected to a legitimate network.

Where a pre-configured network access profile exists, the binding between a 
validated server certificate and an advertised SSID is pre-configured.  
However, where there is no pre-configured network access profile, the 
binding may be difficult to establish without imposition of additional 
requirements.

For example, the server certificate/SSID binding cannot be determined solely 
via verification of the server certificate.  An attacker could obtain a 
valid server certificate for "example.com"; does this entitle them to 
advertise an SSID of "Emergency Network" or even "Example"?  Since SSIDs are 
not globally unique, there is no verifiable mapping between a Server-Id and 
an allowed set of SSIDs. In general, a CA has no way of determining whether 
a server has the rights to a particular SSID or not, so that a CA cannot in 
practice vouch for an RFC 4334 SSID extension within a server certificate.

Therefore verification of a binding between the server identity and the 
advertised network would only seem to be possible by requiring the 
advertised network name to match the Server-Id advertised in the server 
certificate.  This in turn would require restricting the allowable SSIDs, or 
adding another field to the IEEE 802.11 Beacon/Probe Response.

>From: "Joseph Salowey (jsalowey)" <[email-masked]>
>To: <[email-masked]>
>CC: <[email-masked]>, "Bernard Aboba" 
><[email-masked]>
>Subject: Draft liaison response for IEEE 802.11u EAP method for emergency 
>calls