[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: Tuesday, October 02, 2007 1:03 PM
> To: Joseph Salowey (jsalowey); [e-mail]
> Cc: [e-mail]
> Subject: RE: Draft liaison response for IEEE 802.11u EAP 
> method for emergency calls
> 
> >[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.
> 
> 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.
> 
[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 #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