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

Below is an updated liaison response to 802.11u reflecting comments
received so far.  I think this is reasonably close.  I would like to
send a reply next week so please respond with any comments by next
Tuesday 11/6.

Thanks,

Joe

========================================================================
======================

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 exactly meet the
requirements as understood by the EMU working group.  EAP-TLS is
probably closest since it is allowable for EAP-TLS
(draft-simon-emu-rfc2716bis-11.txt) implementations to support modes
that only require server side authentication.  There are several other
possible existing EAP methods that may meet or be slightly modified to
meet some of the 802.11u requirements for emergency services.  TTLS
(draft-funk-eap-ttls-v0-01.txt) and EAP-FAST (RFC4851) are TLS based
methods that can support server 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. 

> -----Original Message-----
> From: Joseph Salowey (jsalowey) 
> Sent: Monday, October 15, 2007 2:30 PM
> To: 'Bernard Aboba'; emu@ietf.org
> Cc: ecrit-chairs@tools.ietf.org
> Subject: 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