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

["Bernard Aboba" <[e-mail]>]

>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.

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