> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Monday, October 15, 2007 1:06 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Cc: [EMAIL PROTECTED] > 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
