> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 02, 2007 1:03 PM > To: Joseph Salowey (jsalowey); [email protected] > Cc: [EMAIL PROTECTED] > Subject: RE: Draft liaison response for IEEE 802.11u EAP > method for emergency calls > > >[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. > > I think we need to distinguish between "validating the > server" and "validating the authenticator". If the EAP peer > has trust anchors, it can validate the server. The question > is whether that should be sufficient to allow the peer to > connect to the authenticator or not. > > It may matter whether the peer has a pre-existing profile. > For example, if > there is a profile corresponding to the "EXAMPLE" network, > and the peer successfully validates the "example.com" server, > then the question is whether the peer should apply the > "EXAMPLE" profile based on validation of the "example.com" > server certificate. If the "EXAMPLE" profile includes a > requirement for validation of a certificate from > "example.com", then that should be sufficient. > > However, if there is no pre-existing profile then it is not > clear to me what security services can be required. Should > the peer be satisfied if the server certificate chains to any > trust anchor, regardless of the SSID? If the SSID in > question represents a pre-existing profile requiring chaining > to a particular trust anchor, I'd say "no". However, if the > SSID is unknown and there is an unknown SSID that advertises > emergency services, then it is probably better to try that > (and maybe even go ahead if the server cert fails validation) > than to fail -- leaving the user without the ability to make > an emergency call in a life and death situation. > [Joe] It seems there is a lot of complexity here. It seems that being able to validate the server's root would be sufficient in most cases. At least there is some trust chain back a server, validating the SSID at this point does not seem to add too much.
> > > > > > > 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: <[email protected]> > > > >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 [email protected] https://www1.ietf.org/mailman/listinfo/emu
