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

 

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Monday, October 15, 2007 1:06 PM
> To: Joseph Salowey (jsalowey); emu@ietf.org
> Cc: ecrit-chairs@tools.ietf.org
> Subject: RE: Revised liaison response for IEEE 802.11u EAP 
> method for emergency calls
> 
> >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 general, in TLS-based EAP methods the TLS client 
> authentication policy is determined by the server.  That is, 
> the server decides whether to request a client certificate; 
> RFC 2716 recommends but does not require inclusion of a 
> certificate request in the Server hello message; in the 
> examples in RFC 2716 the certificate-request field is not 
> shown as mandatory. By not including a certificate request, 
> an EAP-TLS server can support anonymous clients. It is my 
> understanding that existing EAP-TLS peer implementations 
> support server-side only authentication.
> 
[Joe] OK, how about modifying the above sentence to:

"It is possible for EAP-TLS (draft-simon-emu-rfc2716bis-11.txt)
implementations to support modes that only require server side
authentication."

> >If the peer can validate the server then it is possible to mitigate 
> >many man-in-the-middle attacks against the authentication, 
> however if 
> >the peer cannot validate the server then this
> >would leave the protocol open to man-in-the-middle attacks.  
>  These TLS
> >based methods require a significant number of round trips, 
> however this 
> >may not be an issue especially if the emergency authentication is 
> >terminated locally instead of in a home server.
> >
> >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 what security properties are desirable.  Is it 
> >important for the emergency services network to be 
> authenticated?  Is 
> >it possible for the peer to have a trust root for emergency services 
> >network? Is there expected to be an existing profile with a specific
> >SSID that needs to be authorized?   Is there another use for the
> >authenticated identity?
> >
> >2) What regulatory requirements are driving the need for encryption?
> >This creates some conflicts because encryption without 
> authentication 
> >does not satisfy most useful security requirements.
> >
> >3) Will the authentication for emergency services be 
> terminated locally 
> >or in a remote network?  What is the tolerance for delay 
> before network 
> >connectivity is established?
> >
> >4) 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?
> >
> >5) It seems that most public access networks already provide an open 
> >access network, why couldn't this network be used for emergency 
> >communication?
> >
> >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
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu