[Ecrit] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls

["Joseph Salowey (jsalowey)" <[e-mail]>]

Hi Hannes,

Comments inline below. 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[e-mail]] 
> Sent: Saturday, September 22, 2007 6:23 AM
> To: Bernard Aboba
> Cc: Joseph Salowey (jsalowey); [e-mail]; 
> [e-mail]; ECRIT
> Subject: Re: Draft liaison response for IEEE 802.11u EAP 
> method for emergency calls
> 
> Hi Bernard,
> 
> thanks for your input. Please find a few more thoughts below:
> 
> Bernard Aboba wrote:
> > It is not clear to me whether the requirements do in fact prohibit 
> > server-side authentication.  As you note, without server-side 
> > authentication man-in-the-middle attacks are possible;  
> however, even 
> > with server-side authentication, additional requirements 
> may need to 
> > be imposed in order to provide the desired level of security.
> >
> I also believe that the requirements does not rule out 
> server-side authentication.
> 
> > Requirement #1 is "No Pre-configured trust relationship".  
> This could 
> > refer to pre-configuration of the server with respect to 
> the expected 
> > client credential (PSK or certificate), or it could refer to 
> > pre-configuration of the client with respect to the server, (such 
> > trust anchors).  The text seems focused on the former more than the 
> > latter.  Assuming that clients can be pre-configured with trust 
> > anchors, then TLS-based EAP methods could meet the requirement.
> >
> I agree that this aspect of no pre-configured trust 
> relationship is quite likely to refer to pre-established 
> shared secrets.
> 
> > 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.
> >
> I doubt that the performance argument counts a lot here given 
> that the exchange is, as you indicated, local.
> 
> > 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.
> Whereby "legitimate network" is already a quite difficult requirement.
> 
[Joe] This is a central point, if one does not know what is a legitimate
network then why bother to authenticate it?  

> >
> > 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.
> >
> > 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.
> >
> I don't think it make a lot of sense to bind the certificate 
> to the advertised SSID.
> 
[Joe] This depends upon what you are trying to do.  If you want to have
some assurance at the time of connection need to be able to check that
the entity that you are authenticating is authorized to provide the
service.  Tying SSIDs to the certificate is one way to do this. There
are others that may be more attractive as well. 

> 
> WHAT CAN YOU ACCOMPLISH WITH SERVER-SIDE AUTHENTICATION?
> 
> The important question here, I believe, is what you would do with 
> server-side authentication in such a context given that it 
> has entirely 
> different semantic than the server-side authentication that 
> is typically 
> exercised in EAP exchanges between the peer and the EAP server in the 
> user's home network.
> 
> I don't think that addressing man-in-the-middle attacks is the main 
> objective. Instead, I could imagine that when something goes 
> wrong then 
> the end user might be able to indicate that he or she was interacting 
> with a specific network.I see this more as a "debugging" tool.
> 
[Joe] But do you need to go through all this complex cryptographic
calculations and message exchanges just for "debugging"? 

> When some verification steps fails, for example because the 
> certificate 
> of the server is expired, then in an emergency situation you 
> will just 
> continue rather than dropping the conversation. Additionally, 
> everyone 
> should be able to setup networks and hence the adversary can 
> easily do 
> the same. What would the network of an adversary 
> differentiate from one 
> that is from someone else?
> 
> WHAT ASSUMPTIONS DO WE MAKE WITH RESPECT TO THE SERVER'S 
> CERTIFICATE AND 
> THE TRUST ANCHORS?
> 
> Do we assume that persons that setup networks, such as my 
> home network, 
> a coffee shop, the IETF network, have to obtain a certificate 
> for their 
> network from
> a) from any company that sells certs typically found in web servers
> b) from a dedicated emergency services provider
> 
> (Note1)
> 
> May I re-use existing trust anchors, such as those available 
> with my web 
> browsers, or do end devices need to add new root certs into their 
> certificate store?
> 
> In case (b) can I assume that the PSAP also uses the same 
> trust anchor 
> so that I could potentially use DTLS-SRTP for end-to-end 
> media security 
> to ensure that I am actually speaking to a real PSAP rather 
> than to an 
> adversary?
> 
> 
> Ciao
> Hannes
> 
> Note 1: Would it be allowed to just skip server-side 
> authentication and 
> to end-up with a unauthenticated Diffie-Helman exchange? One 
> might argue 
> that this does not provide a lot of advantages and we could also skip 
> the EAP exchange entirely but that's not completely true that 
> architectures, such as Wimax, assume that keying material is exported 
> during network attachment and that these keys are used for other 
> protocols. Hence, if one would change then the impact for the 
> other work 
> done before would be too large.
> 
[Joe] However it seems that we really ought to make sure we are gaining
something from this exchange.  If not we are just introducing delays
into the system at a critical point.  Wouldn't you want to reduce the
delay at this point?

> >
> >
> >
> >
> >
> >> 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-unauthentic
> ated-acces
> >> s-00
> >>
> >> We encourage IEEE working group members to continue the 
> discussion with
> >> the IETF in the EMU and the ECRIT working groups.
> >
> 

_______________________________________________
Ecrit mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit