> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Monday, September 17, 2007 10:20 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: Draft liaison response for IEEE 802.11u EAP > method for emergency calls > > 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. > > 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.
[Joe] I agree, that if "No pre-configured trust relationship" refers to configuration of client on the server then we are in a better position. However it seems that in you discussion below that the peer does not typically have enough information to validate the server. > > 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. > [Joe] the requirement is a bit unclear, however I agree that it is worth including text about this. > 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. > > 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. > [Joe] If this is the case then I don't think there is a valid trust relationship for the peer to validate the server. > 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. > [Joe] It seems like there are at least two possibilities here: 1. Have a CA that only issues emergency services certificates and an indication in the beacon/probe of which SSIDs are emergency services. 2. Have a CA that issues different types of certificates and have specific SSIDs and names in the certificates to create the authorization linkage. > > > > > > > >From: "Joseph Salowey (jsalowey)" <[EMAIL PROTECTED]> > >To: <emu@ietf.org> > >CC: <[EMAIL PROTECTED]>, "Bernard Aboba" > ><[EMAIL PROTECTED]> > >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-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
