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

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 2 Oct 2007 09:20:00 -0700

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, September 17, 2007 10:20 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Cc: [email-masked]; [email-masked]
> 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)" <[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
> >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
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 02 Oct 2007 13:03:19 -0700

>typically have enough information to validate the server.

I think we need to distinguish between "validating the server" and 
"validating the authenticator".  If the EAP peer has trust anchors, it can 
validate the server.  The question is whether that should be sufficient to 
allow the peer to connect to the authenticator or not.

It may matter whether the peer has a pre-existing profile.   For example, if 
there is a profile corresponding to the "EXAMPLE" network, and the peer 
successfully validates the "example.com" server, then the question is 
whether the peer should apply the "EXAMPLE" profile based on validation of 
the "example.com" server certificate.  If the "EXAMPLE" profile includes a 
requirement for validation of a certificate from "example.com", then that 
should be sufficient.

However, if there is no pre-existing profile then it is not clear to me what 
security services can be required.  Should the peer be satisfied if the 
server certificate chains to any trust anchor, regardless of the SSID?  If 
the SSID in question represents a pre-existing profile requiring chaining to 
a particular trust anchor, I'd say "no".  However, if the SSID is unknown 
and there is an unknown SSID that advertises emergency services, then it is 
probably better to try that (and maybe even go ahead if the server cert 
fails validation) than to fail -- leaving the user without the ability to 
make an emergency call in a life and death situation.

---

From: Charles Clancy <[email-masked]>
Date: Sat, 06 Oct 2007 12:45:39 -0400

The requirements for this emergency services EAP method look a lot like 
a method that would be really useful for hotspots.  Most hotspots 
authenticate via a web portal, and perform admission control based on a 
MAC address.  In many deployments it's fairly easy to find the MAC 
address of someone who has already authenticated, and then run "ifconfig 
wlan0 hwaddr <authenticated-mac-addr>" to usurp their session without 
paying for it.

Often switching to a mutually-authenticated EAP method is not viable, 
because there is no enrollment capabilities, i.e. you can't sign up new 
users without giving them a web GUI to type in their credit card 
information.  If hotspot deployers had a server-authenticated EAP method 
that tied a client's MAC address to a particular set of keys, they could 
then decide whether that user could access the Internet based on whether 
or not they had signed in to a web portal or not.

This approach would go a long way toward improving security in many 
wireless networks.  I think it would be extremely useful in hotels, 
universities, coffee shops, etc.  It might be useful to think about some 
requirements for these scenarios too, and kill two birds with one stone.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

---

From: Alan DeKok <[email-masked]>
Date: Mon, 08 Oct 2007 11:26:00 +0200

> that tied a client's MAC address to a particular set of keys, they could

  ... lose a lot of users.  People log in from different machines, and
understand "name + password == access".

> or not they had signed in to a web portal or not.

  Companies are deploying these solutions today.  They're obtain some
acceptance, but in the enterprise area, rather than in Hotspots.

> requirements for these scenarios too, and kill two birds with one stone.

  Seamless roaming is very, very, difficult to implement correctly.
There are just too many bit players who lack the capability to do
anything other than to bill users.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 15 Oct 2007 11:43:09 -0700

> Sent: Tuesday, October 02, 2007 1:03 PM
> Cc: [email-masked]
> I think we need to distinguish between "validating the 
> server" and "validating the authenticator".  If the EAP peer 
> has trust anchors, it can validate the server.  The question 
> is whether that should be sufficient to allow the peer to 
> connect to the authenticator or not.
> 
> there is a profile corresponding to the "EXAMPLE" network, 
> and the peer successfully validates the "example.com" server, 
> then the question is whether the peer should apply the 
> "EXAMPLE" profile based on validation of the "example.com" 
> server certificate.  If the "EXAMPLE" profile includes a 
> requirement for validation of a certificate from 
> "example.com", then that should be sufficient.
> 
> However, if there is no pre-existing profile then it is not 
> clear to me what security services can be required.  Should 
> the peer be satisfied if the server certificate chains to any 
> trust anchor, regardless of the SSID?  If the SSID in 
> question represents a pre-existing profile requiring chaining 
> to a particular trust anchor, I'd say "no".  However, if the 
> SSID is unknown and there is an unknown SSID that advertises 
> emergency services, then it is probably better to try that 
> (and maybe even go ahead if the server cert fails validation) 
> than to fail -- leaving the user without the ability to make 
> an emergency call in a life and death situation.
> 
[Joe] It seems there is a lot of complexity here.  It seems that being
able to validate the server's root would be sufficient in most cases.
At least there is some trust chain back a server, validating the SSID at
this point does not seem to add too much. 

> > > 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.
> > >
> 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.
> > >
> > > "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.
> > >
> 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.
> > >
> >specific SSIDs and names in the certificates to create the 
> >authorization linkage.
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >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 
> > > >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
> > > >There were also several questions raised in the working group 
> > > >during the discussion that might help in further determining the
> > > best approach.
> > > >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?
> > > >
> > > >the IETF that are looking at unauthenticated emergency 
> services.  
> > > >In particular, the ECRIT group within the IETF has 
> ongoing work in 
> > > >this
> > > >area:
> > > >

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 15 Oct 2007 12:51:51 -0700

>this point does not seem to add too much.

Assuming that the selected SSID advertising Emergency Sevices has no 
pre-existing profile, I would agree that validating the server certificate 
to some set of trust anchors (that may be specific to emergency services) is 
sufficient.

If we are talking about a pre-existing profile, then the authentication 
policy for that profile should still be enforced.   For example, an attacker 
shouldn't be able to trick a victim into abandoning an existing profile just 
by advertising "Emergency Services" capability along with the SSID.  After 
all, the existing profile may require use of a different EAP method, set of 
trust anchors, etc.