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

["Joseph Salowey (jsalowey)" <[e-mail]>]

 

> -----Original Message-----
> From: Bernard Aboba [mailto:[e-mail]] 
> Sent: Monday, September 17, 2007 10:20 AM
> To: Joseph Salowey (jsalowey); [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: Draft liaison response for IEEE 802.11u EAP 
> method for emergency calls
> 
> 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.

[Joe] I agree, that if "No pre-configured trust relationship" refers to
configuration of client on the server then we are in a better position.
However it seems that in you discussion below that the peer does not
typically have enough information to validate the server. 
> 
> 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.
> 
[Joe] the requirement is a bit unclear, however I agree that it is worth
including text about this. 

> 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.
> 
[Joe] If this is the case then I don't think there is a valid trust
relationship for the peer to validate the server. 


> 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.
> 
[Joe] It seems like there are at least two possibilities here:

1. Have a CA that only issues emergency services certificates and an
indication in the beacon/probe of which SSIDs are emergency services.

2. Have a CA that issues different types of certificates and have
specific SSIDs and names in the certificates to create the authorization
linkage.  

> 
> 
> 
> 
> 
> 
> >From: "Joseph Salowey (jsalowey)" <[e-mail]>
> >To: <[e-mail]>
> >CC: <[e-mail]>, "Bernard Aboba" 
> ><[e-mail]>
> >Subject: Draft liaison response for IEEE 802.11u EAP method for 
> >emergency calls
> >Date: Sun, 16 Sep 2007 22:26:36 -0700
> >
> >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-unauthenti
> cated-acce
> >s
> >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
[e-mail]
https://www1.ietf.org/mailman/listinfo/emu