From emu-bounces@ietf.org Tue Oct 02 12:20:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IckTg-00089l-IH; Tue, 02 Oct 2007 12:20:08 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IckTe-00085y-Pu for emu-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 12:20:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IckTe-00085p-DO for emu@ietf.org; Tue, 02 Oct 2007 12:20:06 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IckTc-0000cI-Uk for emu@ietf.org; Tue, 02 Oct 2007 12:20:06 -0400 X-IronPort-AV: E=Sophos;i="4.21,220,1188802800"; d="scan'208";a="21136287" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 02 Oct 2007 09:20:04 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l92GK4xL029799; Tue, 2 Oct 2007 09:20:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l92GJvmS026288; Tue, 2 Oct 2007 16:20:02 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:19:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 09:20:00 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: Acf5TwtBXk2NctmqRfSXyzsFVC9ydwLvK0vw From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 02 Oct 2007 16:19:53.0236 (UTC) FILETIME=[105F5D40:01C80510] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8660; t=1191342004; x=1192206004; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Draft=20liaison=20response=20for=20IEEE=20802.11u=20E AP=20method=20for=20emergency=20calls |Sender:=20; bh=pGVdGKF7pDs8l4JqL7RvZEw9KX9YhPyj0n8qRGv7hqk=; b=SrqbkiHQX5C6LYyYF5p6RzL0J6hkgb+xbhjbKdjvZEnCPJwrJPxO+Qf0Ltgumc/yqiVY6O9D nPqQiYkrc+5MmSg6BhvogFxW9/LuE6sDSeZxj4bLojyllYdtE7YyXtkV; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Monday, September 17, 2007 10:20 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Cc: ecrit-chairs@tools.ietf.org; Bernard_Aboba@hotmail.com > Subject: RE: Draft liaison response for IEEE 802.11u EAP=20 > method for emergency calls >=20 > It is not clear to me whether the requirements do in fact=20 > prohibit server-side authentication. As you note, without=20 > server-side authentication man-in-the-middle attacks are=20 > possible; however, even with server-side authentication,=20 > additional requirements may need to be imposed in order to=20 > provide the desired level of security. >=20 > Requirement #1 is "No Pre-configured trust relationship". =20 > This could refer to pre-configuration of the server with=20 > respect to the expected client credential (PSK or=20 > certificate), or it could refer to pre-configuration of the=20 > client with respect to the server, (such trust anchors). The=20 > text seems focused on the former more than the latter. =20 > Assuming that clients can be pre-configured with trust=20 > 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.=20 >=20 > Requirement #2 is "Small" number of messages. While this=20 > requirement clearly excludes long exchanges, it is not clear=20 > to me that TLS-based methods are excluded, particularly if=20 > the method is to be implemented on the AP itself, which=20 > potentially would result in lower round-trip times and=20 > eliminate the possibility of AAA-based frame loss. >=20 [Joe] the requirement is a bit unclear, however I agree that it is worth including text about this.=20 > It may be possible that requirements #1 and #2 are compatible=20 > with proposals involving unauthenticated client access=20 > combined with server authentication.=20 > However, due to lack of a pre-configured network access=20 > profile, this scenario presents additional threats that are=20 > worthy of further discussion. >=20 > The presentation refers to the desire to for confidentiality=20 > (presumably at L2, rather than using SRTP). Where=20 > confidentiality is desirable, it will also presumably be=20 > important for the client to determine that it has connected=20 > to a legitimate network. >=20 > Where a pre-configured network access profile exists, the=20 > binding between a validated server certificate and an=20 > advertised SSID is pre-configured. =20 > However, where there is no pre-configured network access=20 > profile, the binding may be difficult to establish without=20 > imposition of additional requirements. >=20 > For example, the server certificate/SSID binding cannot be=20 > determined solely via verification of the server certificate.=20 > An attacker could obtain a valid server certificate for=20 > "example.com"; does this entitle them to advertise an SSID of=20 > "Emergency Network" or even "Example"? Since SSIDs are not=20 > globally unique, there is no verifiable mapping between a=20 > Server-Id and an allowed set of SSIDs. In general, a CA has=20 > no way of determining whether a server has the rights to a=20 > particular SSID or not, so that a CA cannot in practice vouch=20 > for an RFC 4334 SSID extension within a server certificate. >=20 [Joe] If this is the case then I don't think there is a valid trust relationship for the peer to validate the server.=20 > Therefore verification of a binding between the server=20 > identity and the advertised network would only seem to be=20 > possible by requiring the advertised network name to match=20 > the Server-Id advertised in the server certificate. This in=20 > turn would require restricting the allowable SSIDs, or adding=20 > another field to the IEEE 802.11 Beacon/Probe Response. >=20 [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. =20 >=20 >=20 >=20 >=20 >=20 >=20 > >From: "Joseph Salowey (jsalowey)" > >To: > >CC: , "Bernard Aboba"=20 > > > >Subject: Draft liaison response for IEEE 802.11u EAP method for=20 > >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=20 > >methods for emergency calls. The liaison request can be=20 > found on the=20 > >liaison statement page, https://datatracker.ietf.org/liaison/ (May=20 > >2007). We had a presentations and discussion of this topic at the=20 > >Chicago EMU meeting. Below is a draft response based on the=20 > discussion=20 > >in the meeting. It would be good to have comments on or approval of=20 > >the text by Monday, October 1, so a revised response can be=20 > created to=20 > >be sent as a response to the IEEE. > > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >802.11u Liaison response for EAP Methods for Emergency Communications > > > >We have had discussion of EAP method for Emergency services=20 > at the last=20 > >IETF meeting in Chicago. The following is a summary of=20 > working group=20 > >discussion on this topic. > > > >Currently there are no standards track EAP methods that meet the=20 > >requirements as understood by the EMU working group. There=20 > are several=20 > >possible candidates of existing EAP methods that may meet or be=20 > >slightly modified to meet some of the 802.11u requirements for=20 > >emergency services, especially if minimal latency is not the=20 > strongest=20 > >requirement. TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST > >(RFC4851) are TLS based methods that can support server only=20 > >authentication. It was also pointed out that EAP-TLS > >(draft-simon-emu-rfc2716bis-11.txt) could be modified to=20 > create a new=20 > >EAP method that only requires server side authentication. =20 > In order to=20 > >truly support emergency services these methods would need to forego=20 > >server certificate validation which negates much of the security they > >provide by allowing man-in-the-middle attacks. These TLS=20 > based methods > >also require a significant number of round trips that may not be=20 > >acceptable for emergency communication. > > > >There were also several questions raised in the working group during=20 > >the discussion that might help in further determining the=20 > best approach. > >These are summarized below: > > > >1) It is not clear how to make the tradeoff between security and=20 > >low-latency. If there is not existing trust relationship there are=20 > >limits as to what security properties can be provided. What=20 > security=20 > >properties are desirable and what is the tolerance for extra-round=20 > >trips for the communication? > > > >2) PSK was described as having worse DOS resistance=20 > properties that EAP. > >It seems that in many cases EAP would have worse DOS resistance that=20 > >PSK, which cases is EAP better? > > > >3) It seems that most public access networks already provide an open=20 > >access network, why couldn't this network be used for emergency=20 > >communication? > > > >4) What regulatory requirements are driving the need for encryption? > >This creates some conflicts because encryption without=20 > authentication=20 > >does not satisfy most useful security requirements. > > > >As the 802.11u group is certainly aware, there are other=20 > groups within=20 > >the IETF that are looking at unauthenticated emergency services. In=20 > >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=20 > discussion with=20 > >the IETF in the EMU and the ECRIT working groups. >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 02 12:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icl1K-0003TJ-W6; Tue, 02 Oct 2007 12:54:55 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Icl1H-0003Dk-BG for emu-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 12:54:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icl1G-0003AH-U8; Tue, 02 Oct 2007 12:54:51 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icl1F-0001Z9-Gp; Tue, 02 Oct 2007 12:54:50 -0400 X-IronPort-AV: E=Sophos;i="4.21,220,1188802800"; d="scan'208";a="229077480" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Oct 2007 09:54:48 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l92GsmCF006739; Tue, 2 Oct 2007 09:54:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l92Gsm1g005293; Tue, 2 Oct 2007 16:54:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Oct 2007 09:54:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Oct 2007 09:54:55 -0700 Message-ID: In-Reply-To: <46F5172E.3000005@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: Acf9G7H0qKbBRemkTDCHK3ZOgsqdzwH96N6A From: "Joseph Salowey (jsalowey)" To: "Hannes Tschofenig" , "Bernard Aboba" X-OriginalArrivalTime: 02 Oct 2007 16:54:48.0564 (UTC) FILETIME=[F1490B40:01C80514] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=12241; t=1191344088; x=1192208088; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Draft=20liaison=20response=20for=20IEEE=20802.11u=20E AP=20method=20for=20emergency=20calls |Sender:=20; bh=/x7bxBFgABN64FNCJeZpClBL+kn1Ds4mHV837DpyeSc=; b=Zd3LuebeInXGxtJa2X6czxyk01MQksJOGP8NysBPL9rbYFkSZe1VAypNZo9LAtnp8B/ZdnLD RyyA++Q5kbelu2WEVYkbtdlKGqIKlAB4dPJsWknoBJJ9BeVpW7aYVB9D; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Cc: ecrit-chairs@tools.ietf.org, emu@ietf.org, ECRIT Subject: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Hannes, Comments inline below.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Saturday, September 22, 2007 6:23 AM > To: Bernard Aboba > Cc: Joseph Salowey (jsalowey); emu@ietf.org;=20 > ecrit-chairs@tools.ietf.org; ECRIT > Subject: Re: Draft liaison response for IEEE 802.11u EAP=20 > method for emergency calls >=20 > Hi Bernard, >=20 > thanks for your input. Please find a few more thoughts below: >=20 > Bernard Aboba wrote: > > It is not clear to me whether the requirements do in fact prohibit=20 > > server-side authentication. As you note, without server-side=20 > > authentication man-in-the-middle attacks are possible; =20 > however, even=20 > > with server-side authentication, additional requirements=20 > may need to=20 > > be imposed in order to provide the desired level of security. > > > I also believe that the requirements does not rule out=20 > server-side authentication. >=20 > > Requirement #1 is "No Pre-configured trust relationship". =20 > This could=20 > > refer to pre-configuration of the server with respect to=20 > the expected=20 > > client credential (PSK or certificate), or it could refer to=20 > > pre-configuration of the client with respect to the server, (such=20 > > trust anchors). The text seems focused on the former more than the=20 > > latter. Assuming that clients can be pre-configured with trust=20 > > anchors, then TLS-based EAP methods could meet the requirement. > > > I agree that this aspect of no pre-configured trust=20 > relationship is quite likely to refer to pre-established=20 > shared secrets. >=20 > > Requirement #2 is "Small" number of messages. While this=20 > requirement=20 > > clearly excludes long exchanges, it is not clear to me that=20 > TLS-based=20 > > methods are excluded, particularly if the method is to be=20 > implemented=20 > > on the AP itself, which potentially would result in lower=20 > round-trip=20 > > times and eliminate the possibility of AAA-based frame loss. > > > I doubt that the performance argument counts a lot here given=20 > that the exchange is, as you indicated, local. >=20 > > It may be possible that requirements #1 and #2 are compatible with=20 > > proposals involving unauthenticated client access combined=20 > with server > > authentication. However, due to lack of a pre-configured network=20 > > access profile, this scenario presents additional threats that are=20 > > worthy of further discussion. > > > > The presentation refers to the desire to for confidentiality=20 > > (presumably at L2, rather than using SRTP). Where=20 > confidentiality is=20 > > desirable, it will also presumably be important for the client to=20 > > determine that it has connected to a legitimate network. > Whereby "legitimate network" is already a quite difficult requirement. >=20 [Joe] This is a central point, if one does not know what is a legitimate network then why bother to authenticate it? =20 > > > > Where a pre-configured network access profile exists, the binding=20 > > between a validated server certificate and an advertised SSID is=20 > > pre-configured. However, where there is no pre-configured network=20 > > access profile, the binding may be difficult to establish without=20 > > imposition of additional requirements. > > > > For example, the server certificate/SSID binding cannot be=20 > determined=20 > > solely via verification of the server certificate. An=20 > attacker could=20 > > obtain a valid server certificate for "example.com"; does=20 > this entitle=20 > > them to advertise an SSID of "Emergency Network" or even "Example"? > > Since SSIDs are not globally unique, there is no verifiable mapping=20 > > between a Server-Id and an allowed set of SSIDs. In=20 > general, a CA has=20 > > no way of determining whether a server has the rights to a=20 > particular=20 > > SSID or not, so that a CA cannot in practice vouch for an RFC 4334=20 > > SSID extension within a server certificate. > > > > Therefore verification of a binding between the server identity and=20 > > the advertised network would only seem to be possible by=20 > requiring the=20 > > advertised network name to match the Server-Id advertised in the=20 > > server certificate. This in turn would require restricting the=20 > > allowable SSIDs, or adding another field to the IEEE 802.11=20 > > Beacon/Probe Response. > > > I don't think it make a lot of sense to bind the certificate=20 > to the advertised SSID. >=20 [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.=20 >=20 > WHAT CAN YOU ACCOMPLISH WITH SERVER-SIDE AUTHENTICATION? >=20 > The important question here, I believe, is what you would do with=20 > server-side authentication in such a context given that it=20 > has entirely=20 > different semantic than the server-side authentication that=20 > is typically=20 > exercised in EAP exchanges between the peer and the EAP server in the=20 > user's home network. >=20 > I don't think that addressing man-in-the-middle attacks is the main=20 > objective. Instead, I could imagine that when something goes=20 > wrong then=20 > the end user might be able to indicate that he or she was interacting=20 > with a specific network.I see this more as a "debugging" tool. >=20 [Joe] But do you need to go through all this complex cryptographic calculations and message exchanges just for "debugging"?=20 > When some verification steps fails, for example because the=20 > certificate=20 > of the server is expired, then in an emergency situation you=20 > will just=20 > continue rather than dropping the conversation. Additionally,=20 > everyone=20 > should be able to setup networks and hence the adversary can=20 > easily do=20 > the same. What would the network of an adversary=20 > differentiate from one=20 > that is from someone else? >=20 > WHAT ASSUMPTIONS DO WE MAKE WITH RESPECT TO THE SERVER'S=20 > CERTIFICATE AND=20 > THE TRUST ANCHORS? >=20 > Do we assume that persons that setup networks, such as my=20 > home network,=20 > a coffee shop, the IETF network, have to obtain a certificate=20 > for their=20 > network from > a) from any company that sells certs typically found in web servers > b) from a dedicated emergency services provider >=20 > (Note1) >=20 > May I re-use existing trust anchors, such as those available=20 > with my web=20 > browsers, or do end devices need to add new root certs into their=20 > certificate store? >=20 > In case (b) can I assume that the PSAP also uses the same=20 > trust anchor=20 > so that I could potentially use DTLS-SRTP for end-to-end=20 > media security=20 > to ensure that I am actually speaking to a real PSAP rather=20 > than to an=20 > adversary? >=20 >=20 > Ciao > Hannes >=20 > Note 1: Would it be allowed to just skip server-side=20 > authentication and=20 > to end-up with a unauthenticated Diffie-Helman exchange? One=20 > might argue=20 > that this does not provide a lot of advantages and we could also skip=20 > the EAP exchange entirely but that's not completely true that=20 > architectures, such as Wimax, assume that keying material is exported=20 > during network attachment and that these keys are used for other=20 > protocols. Hence, if one would change then the impact for the=20 > other work=20 > done before would be too large. >=20 [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)" > >> To: > >> CC: , "Bernard Aboba"=20 > >> > >> Subject: Draft liaison response for IEEE 802.11u EAP method for=20 > >> emergency calls > >> Date: Sun, 16 Sep 2007 22:26:36 -0700 > >> > >> The EMU working group has a liaison request from IEEE=20 > 802.11u on EAP > >> methods for emergency calls. The liaison request can be=20 > 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=20 > the discussion > >> in the meeting. It would be good to have comments on or=20 > approval of the > >> text by Monday, October 1, so a revised response can be=20 > created to be > >> sent as a response to the IEEE. > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> > >> 802.11u Liaison response for EAP Methods for Emergency=20 > Communications > >> > >> We have had discussion of EAP method for Emergency=20 > services at the last > >> IETF meeting in Chicago. The following is a summary of=20 > 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. =20 > There are several > >> possible candidates of existing EAP methods that may meet=20 > 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=20 > create a new > >> EAP method that only requires server side authentication. =20 > In order to > >> truly support emergency services these methods would need to forego > >> server certificate validation which negates much of the=20 > security they > >> provide by allowing man-in-the-middle attacks. These TLS=20 > 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=20 > group during the > >> discussion that might help in further determining the best=20 > 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. =20 > What security > >> properties are desirable and what is the tolerance for=20 > extra-round trips > >> for the communication? > >> > >> 2) PSK was described as having worse DOS resistance=20 > properties that EAP. > >> It seems that in many cases EAP would have worse DOS=20 > resistance that > >> PSK, which cases is EAP better? > >> > >> 3) It seems that most public access networks already=20 > provide an open > >> access network, why couldn't this network be used for emergency > >> communication? > >> > >> 4) What regulatory requirements are driving the need for=20 > encryption? > >> This creates some conflicts because encryption without=20 > authentication > >> does not satisfy most useful security requirements. > >> > >> As the 802.11u group is certainly aware, there are other=20 > groups within > >> the IETF that are looking at unauthenticated emergency=20 > services. In > >> particular, the ECRIT group within the IETF has ongoing=20 > work in this > >> area: > >> > >>=20 > http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthentic > ated-acces > >> s-00 > >> > >> We encourage IEEE working group members to continue the=20 > discussion with > >> the IETF in the EMU and the ECRIT working groups. > > >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 02 16:03:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icnxn-0000T9-R4; Tue, 02 Oct 2007 16:03:27 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Icnxl-0000Nb-PT for emu-confirm+ok@megatron.ietf.org; Tue, 02 Oct 2007 16:03:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Icnxl-0000NM-Dm for emu@ietf.org; Tue, 02 Oct 2007 16:03:25 -0400 Received: from bay117-f39.bay117.hotmail.com ([207.46.8.119] helo=hotmail.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Icnxk-0007iM-D7 for emu@ietf.org; Tue, 02 Oct 2007 16:03:25 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 2 Oct 2007 13:03:23 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 02 Oct 2007 20:03:19 GMT X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Date: Tue, 02 Oct 2007 13:03:19 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 02 Oct 2007 20:03:23.0939 (UTC) FILETIME=[49C63F30:01C8052F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >[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. > > > > 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)" > > >To: > > >CC: , "Bernard Aboba" > > > > > >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 From emu-bounces@ietf.org Wed Oct 03 14:03:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8Yj-0007hv-5M; Wed, 03 Oct 2007 14:02:57 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Id8Yi-0007hi-54 for emu-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 14:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Id8Yh-0007ha-Re for emu@ietf.org; Wed, 03 Oct 2007 14:02:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Id8Yg-00063x-LP for emu@ietf.org; Wed, 03 Oct 2007 14:02:55 -0400 X-IronPort-AV: E=Sophos;i="4.21,226,1188802800"; d="scan'208";a="229857373" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 11:02:54 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l93I2sRK012840 for ; Wed, 3 Oct 2007 11:02:54 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l93I2rYx016484 for ; Wed, 3 Oct 2007 18:02:54 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 11:02:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Oct 2007 11:02:48 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Moving forward with the EMU password method Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+Svg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 03 Oct 2007 18:02:40.0474 (UTC) FILETIME=[96BEF3A0:01C805E7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1146; t=1191434574; x=1192298574; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Moving=20forward=20with=20the=20EMU=20password=20method |Sender:=20; bh=aC4QoSlZwuabO/qYZx9738IS7YzkvuwlCAdPcdp8v+Q=; b=AjxDRjhJqbKKl1boKmcgXdIYv0TpGmMSTMwuRHCCmNNpP4teh5iMvifU2eSMEut1cAzuWSmn bJYWZz3ef7867X5KtwNokYmatv+tWjo4xFCgMz3S18hZse1p2+q9+sJF1XI9iAoFjOJ7U6XVni XVUQV/XW55BorPYhoYfEO313Y=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Emu] Moving forward with the EMU password method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org At the IETF in Chicago we had a hum as to the direction we should take with the password based method. I would like to clarify the choices and determine working group consensus on the list. The two directions are given below please express you preference by 10/25. Option 1 - Password based method - this option restricts the work item to what is currently in the charter. The resulting method would have a new method ID and selecting this method would mean selecting a password based exchange that meets the requirements we already set forth. The method may use an existing method as its base. =20 Option 2 - Tunneling method - this option requires clarifying the charter to work on a tunneling method which would then be used to meet the password method requirements. This would include making sure we have a valid set of requirements to work with. The working group may select an existing method as its base and have backwards compatibility as a goal, however whether the method uses the same method ID and any modifications to the method will be determined by working group and IETF consensus. =20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 03 15:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAKJ-0007sR-AO; Wed, 03 Oct 2007 15:56:11 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdAKI-0007s9-Cn for emu-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 15:56:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAKI-0007rx-1o for emu@ietf.org; Wed, 03 Oct 2007 15:56:10 -0400 Received: from exprod7og56.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdAKH-00052q-IV for emu@ietf.org; Wed, 03 Oct 2007 15:56:09 -0400 Received: from source ([66.129.224.36]) by exprod7ob56.obsmtp.com ([64.18.6.12]) with SMTP; Wed, 03 Oct 2007 12:55:47 PDT Received: from proton.jnpr.net ([10.10.2.37]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 12:56:01 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Moving forward with the EMU password method Date: Wed, 3 Oct 2007 15:54:55 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Moving forward with the EMU password method Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+SvgAAXDpQ References: From: "Stephen Hanna" To: "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 03 Oct 2007 19:56:01.0959 (UTC) FILETIME=[6CBF3370:01C805F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I favor option 2. There are tunneling EAP methods already in widespread use that can meet the requirements with a few extensions (e.g. EAP-TTLSv0 with the extensions documented in draft-hanna-eap-ttls-agility-00.txt). Customers are understandably reluctant to deploy new EAP methods so it's much more likely that they will use the results of our work if we use an existing EAP method instead of defining a new method. Thanks, Steve -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method At the IETF in Chicago we had a hum as to the direction we should take with the password based method. I would like to clarify the choices and determine working group consensus on the list. The two directions are given below please express you preference by 10/25. Option 1 - Password based method - this option restricts the work item to what is currently in the charter. The resulting method would have a new method ID and selecting this method would mean selecting a password based exchange that meets the requirements we already set forth. The method may use an existing method as its base. =20 Option 2 - Tunneling method - this option requires clarifying the charter to work on a tunneling method which would then be used to meet the password method requirements. This would include making sure we have a valid set of requirements to work with. The working group may select an existing method as its base and have backwards compatibility as a goal, however whether the method uses the same method ID and any modifications to the method will be determined by working group and IETF consensus. =20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 03 16:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAoq-0003on-BU; Wed, 03 Oct 2007 16:27:44 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdAoo-0003Vv-Q5 for emu-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 16:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAon-0003Ql-Ad for emu@ietf.org; Wed, 03 Oct 2007 16:27:42 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdAoh-0001U2-5a for emu@ietf.org; Wed, 03 Oct 2007 16:27:41 -0400 X-IronPort-AV: E=Sophos;i="4.21,226,1188792000"; d="scan'208";a="72901727" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Oct 2007 16:27:04 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l93KR7Us004534; Wed, 3 Oct 2007 16:27:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l93KQX2o021150; Wed, 3 Oct 2007 20:27:03 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 16:27:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Moving forward with the EMU password method Date: Wed, 3 Oct 2007 16:26:54 -0400 Message-ID: <0F64770A6FD22C43AAA498C1E774ECC7047133A6@xmb-rtp-208.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Moving forward with the EMU password method Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+SvgAAXDpQAASJZNA= References: From: "Gene Chang (genchang)" To: "Stephen Hanna" , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 03 Oct 2007 20:27:00.0249 (UTC) FILETIME=[C05FC090:01C805FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2995; t=1191443227; x=1192307227; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=genchang@cisco.com; z=From:=20=22Gene=20Chang=20(genchang)=22=20 |Subject:=20RE=3A=20[Emu]=20Moving=20forward=20with=20the=20EMU=20passwor d=20method |Sender:=20 |To:=20=22Stephen=20Hanna=22=20, =0A=20=20=20=20=20=20 =20=20=22Joseph=20Salowey=20(jsalowey)=22=20, =20; bh=lbSHVcqxY53iFoPDfxfSg81+lFKnUjCJslKABLax6uA=; b=Nb6babcYwihxqdhfWBkgx5LCt2FwG0cjkZKZbcpqDutrZcnsDgvytccKgZiLGas7uvYGl7gO OdAUwKqbMQT0sw0o5Hv38RZlqfPsYkq8GoJvlnljhahAHhoq+7y2qEE8; Authentication-Results: rtp-dkim-2; header.From=genchang@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I also favor option 2. There are already several tunneling EAP methods in widespread use. There is already concern that there are too many alternatives. We should avoid introducing a new EAP method. It would be better to (a) use an existing EAP method, (b) merge some of the existing methods, or (c) if necessary, perfect an existing method to meet our needs. Gene ------------------------------------------------------------------------ ---- Eugene Chang (genchang) Office: 603-559-2978 Mobile: 781-799-0233 =20 =20 =20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, October 03, 2007 3:55 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Moving forward with the EMU password method >=20 > I favor option 2. >=20 > There are tunneling EAP methods already in widespread use that can meet > the requirements with a few extensions (e.g. EAP-TTLSv0 with the > extensions > documented in draft-hanna-eap-ttls-agility-00.txt). Customers are > understandably > reluctant to deploy new EAP methods so it's much more likely that they > will > use the results of our work if we use an existing EAP method instead of > defining a new method. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, October 03, 2007 11:03 AM > To: emu@ietf.org > Subject: [Emu] Moving forward with the EMU password method >=20 > At the IETF in Chicago we had a hum as to the direction we should take > with the password based method. I would like to clarify the choices and > determine working group consensus on the list. The two directions are > given below please express you preference by 10/25. >=20 > Option 1 - Password based method - this option restricts the work item > to what is currently in the charter. The resulting method would have a > new method ID and selecting this method would mean selecting a password > based exchange that meets the requirements we already set forth. The > method may use an existing method as its base. >=20 > Option 2 - Tunneling method - this option requires clarifying the > charter to work on a tunneling method which would then be used to meet > the password method requirements. This would include making sure we > have a valid set of requirements to work with. The working group may > select an existing method as its base and have backwards compatibility > as a goal, however whether the method uses the same method ID and any > modifications to the method will be determined by working group and IETF > consensus. >=20 > Thanks, >=20 > Joe >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 03 18:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCfn-0005XS-VE; Wed, 03 Oct 2007 18:26:31 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdCfm-0005XN-F2 for emu-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 18:26:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdCfm-0005XF-2F for emu@ietf.org; Wed, 03 Oct 2007 18:26:30 -0400 Received: from mail731.megamailservers.com ([69.49.98.41]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdCfl-0000u3-K3 for emu@ietf.org; Wed, 03 Oct 2007 18:26:29 -0400 X-POP-User: will.grid-net.com Received: from RayPC (h-67-102-111-130.snfccasy.covad.net [67.102.111.130]) by mail731.megamailservers.com (8.13.6.20060614/8.13.1) with ESMTP id l93MQKge021514; Wed, 3 Oct 2007 18:26:25 -0400 From: "Ray Bell" To: "'Stephen Hanna'" , "'Joseph Salowey \(jsalowey\)'" , References: In-Reply-To: Subject: RE: [Emu] Moving forward with the EMU password method Date: Wed, 3 Oct 2007 15:26:16 -0700 Message-ID: <001c01c8060c$6ad5cd70$40816850$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+SvgAAXDpQAAjSPGA= Content-Language: en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I favor option 2 as well Ray -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, October 03, 2007 12:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2. There are tunneling EAP methods already in widespread use that can meet the requirements with a few extensions (e.g. EAP-TTLSv0 with the extensions documented in draft-hanna-eap-ttls-agility-00.txt). Customers are understandably reluctant to deploy new EAP methods so it's much more likely that they will use the results of our work if we use an existing EAP method instead of defining a new method. Thanks, Steve -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method At the IETF in Chicago we had a hum as to the direction we should take with the password based method. I would like to clarify the choices and determine working group consensus on the list. The two directions are given below please express you preference by 10/25. Option 1 - Password based method - this option restricts the work item to what is currently in the charter. The resulting method would have a new method ID and selecting this method would mean selecting a password based exchange that meets the requirements we already set forth. The method may use an existing method as its base. Option 2 - Tunneling method - this option requires clarifying the charter to work on a tunneling method which would then be used to meet the password method requirements. This would include making sure we have a valid set of requirements to work with. The working group may select an existing method as its base and have backwards compatibility as a goal, however whether the method uses the same method ID and any modifications to the method will be determined by working group and IETF consensus. Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 03 19:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdDSS-00037L-2N; Wed, 03 Oct 2007 19:16:48 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdDSR-00037F-JO for emu-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 19:16:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdDSR-000377-8T for emu@ietf.org; Wed, 03 Oct 2007 19:16:47 -0400 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdDSQ-00028J-OH for emu@ietf.org; Wed, 03 Oct 2007 19:16:47 -0400 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.1.177.2; Wed, 3 Oct 2007 16:16:45 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.70.14) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.1.177.1; Wed, 3 Oct 2007 16:16:45 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com (157.54.62.24) by TK5-EXMLT-W602.wingroup.windeploy.ntdev.microsoft.com (157.54.70.14) with Microsoft SMTP Server id 8.1.122.1; Wed, 3 Oct 2007 16:16:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Moving forward with the EMU password method Date: Wed, 3 Oct 2007 16:15:58 -0700 Message-ID: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800679B3F5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <001c01c8060c$6ad5cd70$40816850$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Moving forward with the EMU password method Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+SvgAAXDpQAAjSPGAAAD6X0A== References: <001c01c8060c$6ad5cd70$40816850$@com> From: Ryan Hurst To: Ray Bell , Stephen Hanna , "Joseph Salowey (jsalowey)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I also favor #2, I like Steve have found customers reluctant to deploy new methods if we can satisfy the goals with a method that's broadly deployed (with some tweaks) I think we will have more success than if we define a new one. -----Original Message----- From: Ray Bell [mailto:ray@grid-net.com]=20 Sent: Wednesday, October 03, 2007 3:26 PM To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2 as well Ray -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, October 03, 2007 12:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2. There are tunneling EAP methods already in widespread use that can meet the requirements with a few extensions (e.g. EAP-TTLSv0 with the extensions documented in draft-hanna-eap-ttls-agility-00.txt). Customers are understandably reluctant to deploy new EAP methods so it's much more likely that they will use the results of our work if we use an existing EAP method instead of defining a new method. Thanks, Steve -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method At the IETF in Chicago we had a hum as to the direction we should take with the password based method. I would like to clarify the choices and determine working group consensus on the list. The two directions are given below please express you preference by 10/25. Option 1 - Password based method - this option restricts the work item to what is currently in the charter. The resulting method would have a new method ID and selecting this method would mean selecting a password based exchange that meets the requirements we already set forth. The method may use an existing method as its base. =20 Option 2 - Tunneling method - this option requires clarifying the charter to work on a tunneling method which would then be used to meet the password method requirements. This would include making sure we have a valid set of requirements to work with. The working group may select an existing method as its base and have backwards compatibility as a goal, however whether the method uses the same method ID and any modifications to the method will be determined by working group and IETF consensus. =20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Oct 03 22:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdGsc-00014Z-L7; Wed, 03 Oct 2007 22:56:02 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdGsb-00014R-Dm for emu-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 22:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdGsb-00014J-3c for emu@ietf.org; Wed, 03 Oct 2007 22:56:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdGsU-0003wt-UY for emu@ietf.org; Wed, 03 Oct 2007 22:56:01 -0400 X-IronPort-AV: E=Sophos;i="4.21,226,1188792000"; d="scan'208";a="133816526" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Oct 2007 22:55:48 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l942tlas028009; Wed, 3 Oct 2007 22:55:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l942tZ2S022490; Thu, 4 Oct 2007 02:55:35 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 22:55:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Moving forward with the EMU password method Date: Wed, 3 Oct 2007 22:56:24 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B705653030@xmb-rtp-212.amer.cisco.com> In-Reply-To: <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800679B3F5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Moving forward with the EMU password method Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+SvgAAXDpQAAjSPGAAAD6X0AAJFuyw References: <001c01c8060c$6ad5cd70$40816850$@com> <5F3AAFB2FEC5ED4AA6DE79A3E0B47D800679B3F5@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> From: "Hao Zhou (hzhou)" To: "Ryan Hurst" , "Ray Bell" , "Stephen Hanna" , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 04 Oct 2007 02:55:34.0967 (UTC) FILETIME=[09076470:01C80632] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3883; t=1191466547; x=1192330547; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20(hzhou)=22=20 |Subject:=20RE=3A=20[Emu]=20Moving=20forward=20with=20the=20EMU=20passwor d=20method |Sender:=20 |To:=20=22Ryan=20Hurst=22=20, =20=22Ray=20Bell=2 2=20, =0A=20=20=20=20=20=20=20=20=22Stephen=20Hanna=22=20 , =0A=20=20=20=20=20=20=20=20=22Joseph=20Salowey=20(jsa lowey)=22=20,=20; bh=jAzIMgfjpOeClopkiX7WJzKfk8Mzcgpb9ojqglk5MZk=; b=gs7R2PsbVaiqPjxSMvW6pYbmwQrwNYgFGwtLKxFUq44hP+vOAudHoUwnBGQrUVoI/pspgfDN GRHhRscu8vV8yvWktmGpuMIUoqznscm3o0VLwxVRg/Vxldt7DiAcKq6X; Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Me too. I like to see a standard based tunneling method, that supports crypto-binding, crypto-agility, internationalization, as well as a standard framework for extension within the tunnel.=20 > -----Original Message----- > From: Ryan Hurst [mailto:Ryan.Hurst@microsoft.com]=20 > Sent: Wednesday, October 03, 2007 7:16 PM > To: Ray Bell; Stephen Hanna; Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Moving forward with the EMU password method >=20 > I also favor #2, I like Steve have found customers reluctant=20 > to deploy new methods if we can satisfy the goals with a=20 > method that's broadly deployed (with some tweaks) I think we=20 > will have more success than if we define a new one. >=20 > -----Original Message----- > From: Ray Bell [mailto:ray@grid-net.com] > Sent: Wednesday, October 03, 2007 3:26 PM > To: 'Stephen Hanna'; 'Joseph Salowey (jsalowey)'; emu@ietf.org > Subject: RE: [Emu] Moving forward with the EMU password method >=20 > I favor option 2 as well >=20 > Ray >=20 >=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Wednesday, October 03, 2007 12:55 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Moving forward with the EMU password method >=20 > I favor option 2. >=20 > There are tunneling EAP methods already in widespread use=20 > that can meet the requirements with a few extensions (e.g.=20 > EAP-TTLSv0 with the extensions documented in=20 > draft-hanna-eap-ttls-agility-00.txt). Customers are=20 > understandably reluctant to deploy new EAP methods so it's=20 > much more likely that they will use the results of our work=20 > if we use an existing EAP method instead of defining a new method. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Wednesday, October 03, 2007 11:03 AM > To: emu@ietf.org > Subject: [Emu] Moving forward with the EMU password method >=20 > At the IETF in Chicago we had a hum as to the direction we=20 > should take with the password based method. I would like to=20 > clarify the choices and determine working group consensus on=20 > the list. The two directions are given below please express=20 > you preference by 10/25. >=20 > Option 1 - Password based method - this option restricts the=20 > work item to what is currently in the charter. The resulting=20 > method would have a new method ID and selecting this method=20 > would mean selecting a password based exchange that meets the=20 > requirements we already set forth. The method may use an=20 > existing method as its base. =20 >=20 > Option 2 - Tunneling method - this option requires clarifying=20 > the charter to work on a tunneling method which would then be=20 > used to meet the password method requirements. This would=20 > include making sure we have a valid set of requirements to=20 > work with. The working group may select an existing method as=20 > its base and have backwards compatibility as a goal, however=20 > whether the method uses the same method ID and any=20 > modifications to the method will be determined by working=20 > group and IETF consensus. =20 >=20 > Thanks, >=20 > Joe >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 04 00:22:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIEF-00072C-7t; Thu, 04 Oct 2007 00:22:27 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdIEE-000726-G5 for emu-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 00:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIEE-00071A-5m for emu@ietf.org; Thu, 04 Oct 2007 00:22:26 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdIEC-0006al-T0 for emu@ietf.org; Thu, 04 Oct 2007 00:22:26 -0400 X-IronPort-AV: E=Sophos;i="4.21,227,1188802800"; d="scan'208";a="230186437" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 21:22:24 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l944MOnB032383; Wed, 3 Oct 2007 21:22:24 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l944MOYt005795; Thu, 4 Oct 2007 04:22:24 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 21:22:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks Date: Wed, 3 Oct 2007 21:22:31 -0700 Message-ID: In-Reply-To: <5FB585F183235B42A9E70095055136FB1E52D8@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK and Client-Side DoS Attacks Thread-Index: Acf7Y2Gkq5KYJC1FS7aKMYexd7FkWgK2nBTQ From: "Joseph Salowey (jsalowey)" To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" , X-OriginalArrivalTime: 04 Oct 2007 04:22:24.0106 (UTC) FILETIME=[29EAECA0:01C8063E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4141; t=1191471744; x=1192335744; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP-GPSK=20and=20Client-Side=20DoS=20Attacks |Sender:=20; bh=C9R03sncm0bw/QDSSeZRRyj68CU8Y9E4QZhV1Pss7n8=; b=GNW/QUY5/I8U2KMjHDB87vINv3oUIxCNvXsU4TPL0dfrehqKqdi1R3rfvgRTgbBvyLXcST7F UrQ/ekpJzoazY/DwCCtinXGkJvqOsu+Os0zFlwzjl/aMY66q/kz3F5tM; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I think the problem is real, although not catastrophic. I would prefer not to remove the identity from the key derivation so either option 2 or 3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a change to the existing draft. Since we do not have many implementations yet I would slightly favor 2. =20 =20 > -----Original Message----- > From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)=20 > [mailto:hannes.tschofenig@nsn.com]=20 > Sent: Thursday, September 20, 2007 1:51 AM > To: emu@ietf.org > Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks >=20 > Hi all,=20 >=20 > What is the issue? The first message from the server to the=20 > peer is not authenticated. This may allow some kind of denial=20 > of service attack against the peer. The peer should be ready=20 > to accept new sessions from the same server, so the peer must=20 > store one server nonce and one peer nonce for each message 1=20 > it receives. An attacker can then flood the network with=20 > fake message 1s to overflow the peer's buffer. This issue is=20 > similar to an issue found in the 802.11i 4-way handshake. >=20 > When receiving message 1, the peer checks to see if it has=20 > open conversations with the server listed in the message. If=20 > it does, then it will reuse the peer nonce it already sent. =20 > In addition, it will not store the server nonce, since the=20 > server nonce comes back in message 3. > Message 3 then contains almost all the information necessary=20 > to validate the MAC. It is only missing the ID_Server. =20 > There seem to be three ways to solve this which are discussed=20 > in the next paragraph. =20 >=20 > 1) The first is to drop ID_Server from the input string,=20 > allowing the peer to check the MAC without the ID. This might=20 > require another NIST review. =20 >=20 > 2) The second is to add ID_Server to message 3. >=20 > 3) Thirdly, the peer could iterate through its list of=20 > associated servers trying to find one which matches. =20 > This allows the peer to store state per server instead of=20 > storing state per message. Since the peer has a fixed (for=20 > the duration of a DoS > attack) and limited number of associated servers, this fixes=20 > the attack. >=20 > Initially, I was a bit curious about the need to allocate=20 > state on the client side with an injected Message 1 by the=20 > adversary. The text in Section 4.2 of [1] was, however,=20 > convincing that the end host needs to keep state information=20 > of multiple sessions even if it only accepts a single one=20 > since otherwise you would be able to put the client into a=20 > blocking state. [1] focuses on a case where only a single=20 > nonce is used in message 3 whereas in EAP-GPSK both nonces=20 > are present in message 3. > When the client receives message (3) then it needs to derive=20 > keying material based on the following info: RAND_Peer,=20 > ID_Peer, RAND_Server, ID_Server, RAND_Peer, RAND_Server is in=20 > message 3 provided by the server and ID_Peer is known to the=20 > peer. The EAP peer may have multiple identities too. Hence,=20 > in EAP-GPSK at least the ID_Server attribute is missing in=20 > message 3. Now, the question is how many EAP server=20 > identities a client has. I suspect only a single one, with=20 > the realm name for the entire domain (with respect to a=20 > particular credential) and how many identities the client uses.=20 >=20 > In any case, I agree with the assessment and the need to=20 > document something in the draft. >=20 > Do you agree that the problem is real? > If yes, what type of solution approach would the group prefer? >=20 > Ciao > Hannes >=20 > Reference: >=20 > [1] Changhua He, John C. Mitchell. Analysis of the 802.11i=20 > 4-Way Handshake. In Proceedings of the Third ACM=20 > International Workshop on Wireless Security (WiSe'04), pages=20 > 43-50. Philadelphia, PA, Oct. 2004 > =20 >=20 > =20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 04 00:24:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIGW-0004x7-OA; Thu, 04 Oct 2007 00:24:48 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdIGV-0004lx-Ge for emu-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 00:24:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdIGV-0004jK-43 for emu@ietf.org; Thu, 04 Oct 2007 00:24:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdIGU-0003Fc-FV for emu@ietf.org; Thu, 04 Oct 2007 00:24:47 -0400 X-IronPort-AV: E=Sophos;i="4.21,227,1188802800"; d="scan'208";a="230187323" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Oct 2007 21:24:46 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l944OjAJ026013; Wed, 3 Oct 2007 21:24:45 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l944OjYt007203; Thu, 4 Oct 2007 04:24:45 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Oct 2007 21:24:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK & Key Derivation Function Date: Wed, 3 Oct 2007 21:24:53 -0700 Message-ID: In-Reply-To: <46F25548.6040407@cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK & Key Derivation Function Thread-Index: Acf7d0VpRXUnrKnqSyOce1n6XJ10CQKxzXog From: "Joseph Salowey (jsalowey)" To: "Charles Clancy" , "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" X-OriginalArrivalTime: 04 Oct 2007 04:24:45.0038 (UTC) FILETIME=[7DEB70E0:01C8063E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3817; t=1191471885; x=1192335885; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP-GPSK=20&=20Key=20Derivation=20Function |Sender:=20; bh=tkAYBH8mbpmioVQbazHNUef9t5aN09CnE8qjqZ6AaAg=; b=Xbp7G06yV3e22DZ8cWwMfYDrYP5PJ9ftpthca9EEcIse6oTf60kQsX3Z5WwJBWZRO2+nqev4 yar9ya2EAksTCEA4+NSVzST3KyaKrs2x9BYYgGhLyTd/36ZMIVHm1DuZ; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I think this is a good approach. =20 > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu]=20 > Sent: Thursday, September 20, 2007 4:11 AM > To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) > Cc: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK & Key Derivation Function >=20 > All, >=20 > My suggestion is adding the following to the GPSK document: >=20 > - For AES ciphersuite say keys MUST be 128 bits in length or=20 > longer, and longer keys be truncated to 128 bits for use > - For HMAC ciphersuite say keys MUST be 256 bits in length or=20 > longer, and longer keys be truncated to 256 bits for use > - RECOMMEND that 256 bit keys be provisioned in all cases to=20 > provide enough entropy for all current and many possible=20 > future ciphersuites > - Add a new section describing requirements on future=20 > ciphersuites that addresses necessary security requirements=20 > and describes their need to specify PSK sizes and how they=20 > deal with different-length keys >=20 > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy >=20 > Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote: > > Hi all, > >=20 > > What is the issue? The derivation of MK uses "0x00" as a=20 > key for the=20 > > KDF. > > Here is the key derivation step: =20 > >=20 > > MK =3D GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString) > > ^^^^^ > > Here is the problem.=20 > >=20 > > Here is what Charles recognized during the discussion: > >=20 > > " > > I just looked though the definition of CMAC, the MAC used in one of=20 > > our two ciphersuites, and the zero key looks like it might=20 > cause some=20 > > problems. Unlike the HMAC ciphersuites, it doesn't simply=20 > concatenate=20 > > the key with the data input. The first step is to compute: > >=20 > > k0=3DE_k(0x00) > > k1=3Dk0*x mod p(x) > > k2=3Dk1*x mod p(x) > >=20 > > These values would always be fixed. During the CBC operation, they=20 > > are XOR'd with the final message block. k1 is XOR'd if the final=20 > > message block's length matches the encryption block length. k2 is=20 > > used otherwise on a message padded with 1000...0000b. > >=20 > > I think what using an all-zero key does is reduce the=20 > security of CMAC=20 > > to the security of CBC-MAC with an all-zeros IV. While the=20 > > ramifications of this are debatable for our applications,=20 > it's still=20 > > probably not a great idea. > >=20 > > Currently we can't use the PSK as the input to the first=20 > KDF because=20 > > its length may not match the selected ciphersuite's block=20 > length. We=20 > > wanted to try to do was have a ciphersuite that could be=20 > implemented=20 > > using only AES. > > " > >=20 > > Do you agree that the problem is real?=20 > >=20 > > If yes, then we believe that there are the following solution steps: > >=20 > > 1) We would need some way to normalize the length of the=20 > PSK for the=20 > > selected ciphersuite. We could define an additional cryptographic=20 > > primitive in every ciphersuite that does this derivation, such as > > SHA256-128 for the AES ciphersuite and SHA256 for the HMAC=20 > ciphersuite. > >=20 > > 2) We could switch to a different KDF, for example to the=20 > one used for=20 > > IKEv2. > >=20 > > Can you come up with other solution approaches? > >=20 > > Which solution approach should we pick? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu >=20 >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 04 03:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdL0d-0000XU-L2; Thu, 04 Oct 2007 03:20:35 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdL0a-0000Vi-9L for emu-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 03:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdL0V-0000ST-Hg for emu@ietf.org; Thu, 04 Oct 2007 03:20:27 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdL0P-000324-8U for emu@ietf.org; Thu, 04 Oct 2007 03:20:27 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 59971A704E; Thu, 4 Oct 2007 00:19:52 -0700 (PDT) Message-ID: <470493FD.1010705@deployingradius.com> Date: Thu, 04 Oct 2007 09:19:25 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Emu] Moving forward with the EMU password method References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Stephen Hanna wrote: > I favor option 2. As do I. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 04 11:28:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdScx-0000x5-KC; Thu, 04 Oct 2007 11:28:39 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IdScw-0000tC-Be for emu-confirm+ok@megatron.ietf.org; Thu, 04 Oct 2007 11:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdScw-0000rL-0x for emu@ietf.org; Thu, 04 Oct 2007 11:28:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdScp-00055G-PR for emu@ietf.org; Thu, 04 Oct 2007 11:28:38 -0400 X-IronPort-AV: E=Sophos;i="4.21,230,1188802800"; d="scan'208";a="179099626" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 04 Oct 2007 08:28:26 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l94FSQq8009930; Thu, 4 Oct 2007 08:28:26 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l94FSP0Y003041; Thu, 4 Oct 2007 15:28:26 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Oct 2007 08:28:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Moving forward with the EMU password method Date: Thu, 4 Oct 2007 08:28:25 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804FC6C38@xmb-sjc-222.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Moving forward with the EMU password method Thread-Index: AcgF55vDrPZIRl67RyCn3t+tYH+SvgAAXDpQACxzVmA= From: "Nancy Winget (ncamwing)" To: "Stephen Hanna" , "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 04 Oct 2007 15:28:26.0012 (UTC) FILETIME=[3511DDC0:01C8069B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2730; t=1191511706; x=1192375706; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ncamwing@cisco.com; z=From:=20=22Nancy=20Winget=20(ncamwing)=22=20 |Subject:=20RE=3A=20[Emu]=20Moving=20forward=20with=20the=20EMU=20passwor d=20method |Sender:=20; bh=REIG7yHZ0RzSpjk7LN28QHz5L01YhsNK6asvyPTQ+mA=; b=AMT1VP5v//jt3osypjGCSf0AAnHxhbIOXxDWOVOxUTiea0mANzgwiGhxX1msBI/SGOCNbkjE i3f8JONOmBrL6mwLFgD0l6GGv66ojhNJ62YFKSZzXHTJtDfuMDUNu7R0; Authentication-Results: sj-dkim-2; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I also favor option 2. There are several tunneled EAP methods that can serve as a baseline such as TTLS, EAP-FAST and PEAP. Though similar, there are differences between them that may be significant and could preclude them from consideration based on the requirements. So, it is important that we first agree on the set of requirements before deciding on how to proceed on standardization of such a method. Nancy. -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, October 03, 2007 12:55 PM To: Joseph Salowey (jsalowey); emu@ietf.org Subject: RE: [Emu] Moving forward with the EMU password method I favor option 2. There are tunneling EAP methods already in widespread use that can meet the requirements with a few extensions (e.g. EAP-TTLSv0 with the extensions documented in draft-hanna-eap-ttls-agility-00.txt). Customers are understandably reluctant to deploy new EAP methods so it's much more likely that they will use the results of our work if we use an existing EAP method instead of defining a new method. Thanks, Steve -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wednesday, October 03, 2007 11:03 AM To: emu@ietf.org Subject: [Emu] Moving forward with the EMU password method At the IETF in Chicago we had a hum as to the direction we should take with the password based method. I would like to clarify the choices and determine working group consensus on the list. The two directions are given below please express you preference by 10/25. Option 1 - Password based method - this option restricts the work item to what is currently in the charter. The resulting method would have a new method ID and selecting this method would mean selecting a password based exchange that meets the requirements we already set forth. The method may use an existing method as its base. =20 Option 2 - Tunneling method - this option requires clarifying the charter to work on a tunneling method which would then be used to meet the password method requirements. This would include making sure we have a valid set of requirements to work with. The working group may select an existing method as its base and have backwards compatibility as a goal, however whether the method uses the same method ID and any modifications to the method will be determined by working group and IETF consensus. =20 Thanks, Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sat Oct 06 12:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeCml-0004Dw-9k; Sat, 06 Oct 2007 12:45:51 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IeCmj-00040e-Gw for emu-confirm+ok@megatron.ietf.org; Sat, 06 Oct 2007 12:45:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IeCmj-0003yM-5y for emu@ietf.org; Sat, 06 Oct 2007 12:45:49 -0400 Received: from lb-nat-3.cs.umd.edu ([128.8.126.130] helo=bacon.cs.umd.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IeCmi-0001MS-20 for emu@ietf.org; Sat, 06 Oct 2007 12:45:49 -0400 Received: from [127.0.0.1] (pool-71-179-1-248.bltmmd.fios.verizon.net [71.179.1.248]) (authenticated bits=0) by bacon.cs.umd.edu (8.13.1/8.12.5) with ESMTP id l96Gn0Bj024051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 6 Oct 2007 12:49:01 -0400 Message-ID: <4707BBB3.2020408@cs.umd.edu> Date: Sat, 06 Oct 2007 12:45:39 -0400 From: Charles Clancy User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: emu@ietf.org Subject: Re: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.44, required 5, autolearn=not spam, ALL_TRUSTED -1.44) X-CSD-MailScanner-From: clancy@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org The requirements for this emergency services EAP method look a lot like a method that would be really useful for hotspots. Most hotspots authenticate via a web portal, and perform admission control based on a MAC address. In many deployments it's fairly easy to find the MAC address of someone who has already authenticated, and then run "ifconfig wlan0 hwaddr " to usurp their session without paying for it. Often switching to a mutually-authenticated EAP method is not viable, because there is no enrollment capabilities, i.e. you can't sign up new users without giving them a web GUI to type in their credit card information. If hotspot deployers had a server-authenticated EAP method that tied a client's MAC address to a particular set of keys, they could then decide whether that user could access the Internet based on whether or not they had signed in to a web portal or not. This approach would go a long way toward improving security in many wireless networks. I think it would be extremely useful in hotels, universities, coffee shops, etc. It might be useful to think about some requirements for these scenarios too, and kill two birds with one stone. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical & computer engineering, university of maryland _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 08 05:27:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieot0-0008Qt-4G; Mon, 08 Oct 2007 05:26:50 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Ieosy-0008Qf-Es for emu-confirm+ok@megatron.ietf.org; Mon, 08 Oct 2007 05:26:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ieosy-0008Q7-4b for emu@ietf.org; Mon, 08 Oct 2007 05:26:48 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ieosr-0008MO-Rk for emu@ietf.org; Mon, 08 Oct 2007 05:26:43 -0400 Received: from [10.0.1.38] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 3DBAEA704E for ; Mon, 8 Oct 2007 02:26:28 -0700 (PDT) Message-ID: <4709F7A8.7020607@deployingradius.com> Date: Mon, 08 Oct 2007 11:26:00 +0200 From: Alan DeKok User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: emu@ietf.org Subject: Re: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls References: <4707BBB3.2020408@cs.umd.edu> In-Reply-To: <4707BBB3.2020408@cs.umd.edu> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Charles Clancy wrote: > Often switching to a mutually-authenticated EAP method is not viable, > because there is no enrollment capabilities, i.e. you can't sign up new > users without giving them a web GUI to type in their credit card > information. If hotspot deployers had a server-authenticated EAP method > that tied a client's MAC address to a particular set of keys, they could ... lose a lot of users. People log in from different machines, and understand "name + password == access". > then decide whether that user could access the Internet based on whether > or not they had signed in to a web portal or not. Companies are deploying these solutions today. They're obtain some acceptance, but in the enterprise area, rather than in Hotspots. > This approach would go a long way toward improving security in many > wireless networks. I think it would be extremely useful in hotels, > universities, coffee shops, etc. It might be useful to think about some > requirements for these scenarios too, and kill two birds with one stone. Seamless roaming is very, very, difficult to implement correctly. There are just too many bit players who lack the capability to do anything other than to bill users. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 15 14:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUuV-0003g5-CB; Mon, 15 Oct 2007 14:43:27 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IhUuT-0003aA-Mf for emu-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:43:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUuS-0003Qe-4U for emu@ietf.org; Mon, 15 Oct 2007 14:43:24 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhUuR-0001pX-JU for emu@ietf.org; Mon, 15 Oct 2007 14:43:24 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188802800"; d="scan'208";a="535563693" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 15 Oct 2007 11:43:24 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9FIhMU3021534; Mon, 15 Oct 2007 11:43:22 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9FIhMx7003381; Mon, 15 Oct 2007 18:43:22 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:42:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2007 11:42:38 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: AcgPWyjOcGU9spGeRouVLE5blEjHog== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Oct 2007 18:42:27.0193 (UTC) FILETIME=[224C5E90:01C80F5B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3376; t=1192473802; x=1193337802; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Revised=20liaison=20response=20for=20IEEE=20802.11u=20EAP=20m ethod=20for=20emergency=20calls |Sender:=20; bh=1SEOp+XpJqbUnOWmIsVq2c7VBQft6TgDxNv9qQMaOEw=; b=aIZP0FiqXF+SeVbvnMh7rgV9Y7+yga+YlwoZB2QBa32NcuENIB0lIjeZI9XkdylTA5DuCpH0 YjZhj08qnl2nsO9CpKWiRyYTFyvs0r0aArjYGnZKP0+DbJMdjSUGkHVd0vM2WPf4XtjVCP7zP7 7/qVxVT3LjxQBsiJCj3h08Qwc=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: Bernard Aboba , ecrit-chairs@tools.ietf.org Subject: [Emu] Revised liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I modified the liaison response below based on the comments received. Please respond indicating if this looks OK or indicate what needs to be modified or added. Thanks, Joe =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 802.11u Liaison response for EAP Methods for Emergency Communications=20 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. =20 Currently there are no standards track EAP methods that exactly 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. 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. 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. =20 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.=20 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?=20 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 =20 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 From emu-bounces@ietf.org Mon Oct 15 14:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUuN-0003Dr-QV; Mon, 15 Oct 2007 14:43:19 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IhUuL-0003Ai-Pe for emu-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 14:43:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhUuK-00039S-DW for emu@ietf.org; Mon, 15 Oct 2007 14:43:16 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhUuJ-0001pE-0o for emu@ietf.org; Mon, 15 Oct 2007 14:43:16 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188802800"; d="scan'208";a="535563584" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Oct 2007 11:42:59 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9FIgwWF024393; Mon, 15 Oct 2007 11:42:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9FIgwsZ029694; Mon, 15 Oct 2007 18:42:58 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 11:42:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2007 11:43:09 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: AcgFL1FVN6mpUJIuQVeWROG0IZrNuAKI6rUA From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 15 Oct 2007 18:42:58.0360 (UTC) FILETIME=[34E01380:01C80F5B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10257; t=1192473778; x=1193337778; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Draft=20liaison=20response=20for=20IEEE=20802.11u=20E AP=20method=20for=20emergency=20calls |Sender:=20; bh=GK8ZTXbearqibSCwEkvsdexQAjDrprObHhzpy56LyDM=; b=ZI5qUPBEFd0mKnpF20wDKqEhZAMrBiys3WX0LdhS82I0evVt32U9lHjRQSBR18r+mD734LM+ BJax/TzRrlSdfgLDLlzAblC0Pqlb4mr+W6bEYkKscDk/UQJcskQReCdz; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: Tuesday, October 02, 2007 1:03 PM > To: Joseph Salowey (jsalowey); emu@ietf.org > Cc: ecrit-chairs@tools.ietf.org > Subject: RE: Draft liaison response for IEEE 802.11u EAP=20 > method for emergency calls >=20 > >[Joe] I agree, that if "No pre-configured trust=20 > relationship" refers to=20 > >configuration of client on the server then we are in a=20 > better position. > >However it seems that in you discussion below that the peer does not=20 > >typically have enough information to validate the server. >=20 > I think we need to distinguish between "validating the=20 > server" and "validating the authenticator". If the EAP peer=20 > has trust anchors, it can validate the server. The question=20 > is whether that should be sufficient to allow the peer to=20 > connect to the authenticator or not. >=20 > It may matter whether the peer has a pre-existing profile. =20 > For example, if=20 > there is a profile corresponding to the "EXAMPLE" network,=20 > and the peer successfully validates the "example.com" server,=20 > then the question is whether the peer should apply the=20 > "EXAMPLE" profile based on validation of the "example.com"=20 > server certificate. If the "EXAMPLE" profile includes a=20 > requirement for validation of a certificate from=20 > "example.com", then that should be sufficient. >=20 > However, if there is no pre-existing profile then it is not=20 > clear to me what security services can be required. Should=20 > the peer be satisfied if the server certificate chains to any=20 > trust anchor, regardless of the SSID? If the SSID in=20 > question represents a pre-existing profile requiring chaining=20 > to a particular trust anchor, I'd say "no". However, if the=20 > SSID is unknown and there is an unknown SSID that advertises=20 > emergency services, then it is probably better to try that=20 > (and maybe even go ahead if the server cert fails validation)=20 > than to fail -- leaving the user without the ability to make=20 > an emergency call in a life and death situation. >=20 [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.=20 >=20 > > > > > > Requirement #2 is "Small" number of messages. While this=20 > > > requirement clearly excludes long exchanges, it is not=20 > clear to me=20 > > > that TLS-based methods are excluded, particularly if the=20 > method is=20 > > > to be implemented on the AP itself, which potentially=20 > would result=20 > > > in lower round-trip times and eliminate the possibility=20 > of AAA-based=20 > > > frame loss. > > > > >[Joe] the requirement is a bit unclear, however I agree that it is=20 > >worth including text about this. > > > > > It may be possible that requirements #1 and #2 are=20 > compatible with=20 > > > proposals involving unauthenticated client access combined with=20 > > > server authentication. > > > However, due to lack of a pre-configured network=20 > access profile,=20 > > > this scenario presents additional threats that are worthy=20 > of further=20 > > > discussion. > > > > > > The presentation refers to the desire to for confidentiality=20 > > > (presumably at L2, rather than using SRTP). Where=20 > confidentiality=20 > > > is desirable, it will also presumably be important for=20 > the client to=20 > > > determine that it has connected to a legitimate network. > > > > > > Where a pre-configured network access profile exists, the binding=20 > > > between a validated server certificate and an advertised SSID is=20 > > > pre-configured. > > > However, where there is no pre-configured network access profile,=20 > > > the binding may be difficult to establish without imposition of=20 > > > additional requirements. > > > > > > For example, the server certificate/SSID binding cannot be=20 > > > determined solely via verification of the server certificate. > > > An attacker could obtain a valid server certificate for=20 > > > "example.com"; does this entitle them to advertise an SSID of=20 > > > "Emergency Network" or even "Example"? Since SSIDs are=20 > not globally=20 > > > unique, there is no verifiable mapping between a Server-Id and an=20 > > > allowed set of SSIDs. In general, a CA has no way of determining=20 > > > whether a server has the rights to a particular SSID or=20 > not, so that=20 > > > a CA cannot in practice vouch for an RFC 4334 SSID=20 > extension within=20 > > > a server certificate. > > > > >[Joe] If this is the case then I don't think there is a valid trust=20 > >relationship for the peer to validate the server. > > > > > > > Therefore verification of a binding between the server=20 > identity and=20 > > > the advertised network would only seem to be possible by=20 > requiring=20 > > > the advertised network name to match the Server-Id=20 > advertised in the=20 > > > server certificate. This in turn would require restricting the=20 > > > allowable SSIDs, or adding another field to the IEEE 802.11=20 > > > 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=20 > >indication in the beacon/probe of which SSIDs are emergency services. > > > >2. Have a CA that issues different types of certificates and have=20 > >specific SSIDs and names in the certificates to create the=20 > >authorization linkage. > > > > > > > > > > > > > > > > > > > > > > > >From: "Joseph Salowey (jsalowey)" > > > >To: > > > >CC: , "Bernard Aboba" > > > > > > > >Subject: Draft liaison response for IEEE 802.11u EAP method for=20 > > > >emergency calls > > > >Date: Sun, 16 Sep 2007 22:26:36 -0700 > > > > > > > >The EMU working group has a liaison request from IEEE 802.11u on=20 > > > >EAP methods for emergency calls. The liaison request can be > > > found on the > > > >liaison statement page,=20 > https://datatracker.ietf.org/liaison/ (May=20 > > > >2007). We had a presentations and discussion of this=20 > topic at the=20 > > > >Chicago EMU meeting. Below is a draft response based on the > > > discussion > > > >in the meeting. It would be good to have comments on or=20 > approval=20 > > > >of the text by Monday, October 1, so a revised response can be > > > created to > > > >be sent as a response to the IEEE. > > > > > > > = >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > >802.11u Liaison response for EAP Methods for Emergency=20 > > > >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=20 > > > >requirements as understood by the EMU working group. There > > > are several > > > >possible candidates of existing EAP methods that may meet or be=20 > > > >slightly modified to meet some of the 802.11u requirements for=20 > > > >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=20 > > > >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=20 > need to forego=20 > > > >server certificate validation which negates much of the=20 > 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=20 > > > >acceptable for emergency communication. > > > > > > > >There were also several questions raised in the working group=20 > > > >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=20 > > > >low-latency. If there is not existing trust=20 > relationship there are=20 > > > >limits as to what security properties can be provided. What > > > security > > > >properties are desirable and what is the tolerance for=20 > extra-round=20 > > > >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=20 > > > >that PSK, which cases is EAP better? > > > > > > > >3) It seems that most public access networks already provide an=20 > > > >open access network, why couldn't this network be used for=20 > > > >emergency communication? > > > > > > > >4) What regulatory requirements are driving the need for=20 > 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=20 > services. =20 > > > >In particular, the ECRIT group within the IETF has=20 > ongoing work in=20 > > > >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. > > > >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 15 15:52:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVz8-0002MS-In; Mon, 15 Oct 2007 15:52:18 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IhVz7-0002Kr-5X for emu-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 15:52:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhVz5-0002Fo-DT for emu@ietf.org; Mon, 15 Oct 2007 15:52:15 -0400 Received: from bay117-f39.bay117.hotmail.com ([207.46.8.119] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhVz0-0001Oi-51 for emu@ietf.org; Mon, 15 Oct 2007 15:52:15 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Oct 2007 12:51:54 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 15 Oct 2007 19:51:51 GMT X-Originating-IP: [71.222.79.18] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Date: Mon, 15 Oct 2007 12:51:51 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Oct 2007 19:51:54.0800 (UTC) FILETIME=[D662BB00:01C80F64] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Draft liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >[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. Assuming that the selected SSID advertising Emergency Sevices has no pre-existing profile, I would agree that validating the server certificate to some set of trust anchors (that may be specific to emergency services) is sufficient. If we are talking about a pre-existing profile, then the authentication policy for that profile should still be enforced. For example, an attacker shouldn't be able to trick a victim into abandoning an existing profile just by advertising "Emergency Services" capability along with the SSID. After all, the existing profile may require use of a different EAP method, set of trust anchors, etc. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 15 16:06:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWCD-0001tN-J5; Mon, 15 Oct 2007 16:05:49 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IhWCC-0001sr-1k for emu-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 16:05:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhWCB-0001sj-7l for emu@ietf.org; Mon, 15 Oct 2007 16:05:47 -0400 Received: from bay0-omc1-s20.bay0.hotmail.com ([65.54.246.92]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IhWCA-0007Fq-Nu for emu@ietf.org; Mon, 15 Oct 2007 16:05:47 -0400 Received: from hotmail.com ([207.46.8.111]) by bay0-omc1-s20.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Oct 2007 13:05:46 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Oct 2007 13:05:46 -0700 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 15 Oct 2007 20:05:41 GMT X-Originating-IP: [71.222.79.18] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: jsalowey@cisco.com, emu@ietf.org Bcc: Date: Mon, 15 Oct 2007 13:05:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 15 Oct 2007 20:05:46.0218 (UTC) FILETIME=[C5F30CA0:01C80F66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Revised liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >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. >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. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Oct 15 17:31:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhXWM-0002eM-IL; Mon, 15 Oct 2007 17:30:42 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IhXWK-0002dR-EK for emu-confirm+ok@megatron.ietf.org; Mon, 15 Oct 2007 17:30:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IhXWJ-0002dB-FX for emu@ietf.org; Mon, 15 Oct 2007 17:30:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IhXWI-0005ax-69 for emu@ietf.org; Mon, 15 Oct 2007 17:30:39 -0400 X-IronPort-AV: E=Sophos;i="4.21,278,1188802800"; d="scan'208";a="23710725" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 15 Oct 2007 14:30:37 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l9FLUb07025554; Mon, 15 Oct 2007 14:30:37 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l9FLUSxJ021752; Mon, 15 Oct 2007 21:30:37 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Oct 2007 14:30:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Oct 2007 14:30:15 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: AcgPZscPji/sJWf/ToynicK9zpyQywACIl3g From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 15 Oct 2007 21:30:04.0743 (UTC) FILETIME=[8D10B570:01C80F72] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3887; t=1192483837; x=1193347837; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Revised=20liaison=20response=20for=20IEEE=20802.11u=2 0EAP=20method=20for=20emergency=20calls |Sender:=20; bh=lLt3YH1ar2vmYRrpwY2msbJ5PdhoUqTKOQkXbVHVlKQ=; b=nnVW7EC8Drk/7oWDgD7BS/Il4a28USgbxDuA9qKjQ1I5IukogBCGuAyr1miP+3G+VrJL51Mr J8mY8EUE5eEXuvLx0+B43EwiVaw5R21OsaKvga+zWNHov8ZVcYRIRFmegQX5pd5H2f6ASirWSx SQqN6YN1JXJpaAB4lzR7MWlXw=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Revised liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > 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=20 > method for emergency calls >=20 > >TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST (RFC4851) are TLS=20 > >based methods that can support server only authentication. =20 > It was also=20 > >pointed out that EAP-TLS (draft-simon-emu-rfc2716bis-11.txt) > >could be modified to create a new EAP method that only=20 > requires server=20 > >side authentication. >=20 > In general, in TLS-based EAP methods the TLS client=20 > authentication policy is determined by the server. That is,=20 > the server decides whether to request a client certificate;=20 > RFC 2716 recommends but does not require inclusion of a=20 > certificate request in the Server hello message; in the=20 > examples in RFC 2716 the certificate-request field is not=20 > shown as mandatory. By not including a certificate request,=20 > an EAP-TLS server can support anonymous clients. It is my=20 > understanding that existing EAP-TLS peer implementations=20 > support server-side only authentication. >=20 [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=20 > >many man-in-the-middle attacks against the authentication,=20 > however if=20 > >the peer cannot validate the server then this > >would leave the protocol open to man-in-the-middle attacks. =20 > These TLS > >based methods require a significant number of round trips,=20 > however this=20 > >may not be an issue especially if the emergency authentication is=20 > >terminated locally instead of in a home server. > > > >There were also several questions raised in the working group during=20 > >the discussion that might help in further determining the=20 > best approach. > >These are summarized below: > > > >1) It is not clear what security properties are desirable. Is it=20 > >important for the emergency services network to be=20 > authenticated? Is=20 > >it possible for the peer to have a trust root for emergency services=20 > >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=20 > authentication=20 > >does not satisfy most useful security requirements. > > > >3) Will the authentication for emergency services be=20 > terminated locally=20 > >or in a remote network? What is the tolerance for delay=20 > before network=20 > >connectivity is established? > > > >4) PSK was described as having worse DOS resistance=20 > properties that EAP. > >It seems that in many cases EAP would have worse DOS resistance that=20 > >PSK, which cases is EAP better? > > > >5) It seems that most public access networks already provide an open=20 > >access network, why couldn't this network be used for emergency=20 > >communication? > > > >As the 802.11u group is certainly aware, there are other=20 > groups within=20 > >the IETF that are looking at unauthenticated emergency services. In=20 > >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=20 > discussion with=20 > >the IETF in the EMU and the ECRIT working groups. >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Oct 21 10:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjbtX-00053g-Ul; Sun, 21 Oct 2007 10:35:11 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IjbtV-0004vI-91 for emu-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 10:35:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IjbtT-0004iD-8J for emu@ietf.org; Sun, 21 Oct 2007 10:35:07 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IjbtI-0001Bb-O2 for emu@ietf.org; Sun, 21 Oct 2007 10:35:03 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2609568uge for ; Sun, 21 Oct 2007 07:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=I9ko0+Ov3Gq1JpFHyuk/MaIHE7b3OfIRcvou8+NnpaY=; b=TNiGQhBf6jIrUdChATn3HDxSwgbnhqHCpsjTskFNxPPTLu1+sEe8nau6CrFvFlm5PJWu3qkjgHP7zGof8frfnoS4uDoyX1DXXWRt/rse1NxkQ8bZ4YdtwdZqrPyx+obBgrJb6aV/GCKWCkptYcl0EX7G51M1H+KTlP4Hpx2mGr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=rQ8gOxrGJSIC3lfS7EFvWla0/lCUIE/3pLNnMqnDfONMQo3QlB6FSc6HOjMRfUnTBj+db7inz4f8s1BxZDpFmOOnZ16SY8TVV6/Msp7qS506C61OOJkOa6ZDc1Vbz77XlGtfbj2hfzsPMmthNuJbphLmvLBpiqDXLo3HlvHSUVg= Received: by 10.67.30.3 with SMTP id h3mr5186459ugj.1192977241985; Sun, 21 Oct 2007 07:34:01 -0700 (PDT) Received: by 10.66.249.6 with HTTP; Sun, 21 Oct 2007 07:34:01 -0700 (PDT) Message-ID: <91d0c8280710210734i27624346la1c76b5be769c1ff@mail.gmail.com> Date: Sun, 21 Oct 2007 10:34:01 -0400 From: "Paul Rowe" To: emu@ietf.org Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks MIME-Version: 1.0 X-Google-Sender-Auth: 6d4c6ef9241b0095 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2144461484==" Errors-To: emu-bounces@ietf.org --===============2144461484== Content-Type: multipart/alternative; boundary="----=_Part_8027_25916097.1192977241975" ------=_Part_8027_25916097.1192977241975 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Regarding the client-side DoS attack in EAP-GPSK: The proposed solution is to add ID_Server to message 3, allowing the client to maintain state per server instead of state per message 1 received: http://www1.ietf.org/mail-archive/web/emu/current/msg00670.html We agree that this solution seems to solve the issue in the cleanest way. Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe >Date: Wed, 3 Oct 2007 21:22:31 -0700 >From: "Joseph Salowey (jsalowey)" >Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks >To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" > , >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > >I think the problem is real, although not catastrophic. I would prefer >not to remove the identity from the key derivation so either option 2 or >3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a >change to the existing draft. Since we do not have many implementations >yet I would slightly favor 2. > > > >> -----Original Message----- >> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) >> [mailto:hannes.tschofenig@nsn.com] >> Sent: Thursday, September 20, 2007 1:51 AM >> To: emu@ietf.org >> Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks >> >> Hi all, >> >> What is the issue? The first message from the server to the >> peer is not authenticated. This may allow some kind of denial >> of service attack against the peer. The peer should be ready >> to accept new sessions from the same server, so the peer must >> store one server nonce and one peer nonce for each message 1 >> it receives. An attacker can then flood the network with >> fake message 1s to overflow the peer's buffer. This issue is >> similar to an issue found in the 802.11i 4-way handshake. >> >> When receiving message 1, the peer checks to see if it has >> open conversations with the server listed in the message. If >> it does, then it will reuse the peer nonce it already sent. >> In addition, it will not store the server nonce, since the >> server nonce comes back in message 3. >> Message 3 then contains almost all the information necessary >> to validate the MAC. It is only missing the ID_Server. >> There seem to be three ways to solve this which are discussed >> in the next paragraph. >> >> 1) The first is to drop ID_Server from the input string, >> allowing the peer to check the MAC without the ID. This might >> require another NIST review. >> >> 2) The second is to add ID_Server to message 3. >> >> 3) Thirdly, the peer could iterate through its list of >> associated servers trying to find one which matches. >> This allows the peer to store state per server instead of >> storing state per message. Since the peer has a fixed (for >> the duration of a DoS >> attack) and limited number of associated servers, this fixes >> the attack. >> >> Initially, I was a bit curious about the need to allocate >> state on the client side with an injected Message 1 by the >> adversary. The text in Section 4.2 of [1] was, however, >> convincing that the end host needs to keep state information >> of multiple sessions even if it only accepts a single one >> since otherwise you would be able to put the client into a >> blocking state. [1] focuses on a case where only a single >> nonce is used in message 3 whereas in EAP-GPSK both nonces >> are present in message 3. >> When the client receives message (3) then it needs to derive >> keying material based on the following info: RAND_Peer, >> ID_Peer, RAND_Server, ID_Server, RAND_Peer, RAND_Server is in >> message 3 provided by the server and ID_Peer is known to the >> peer. The EAP peer may have multiple identities too. Hence, >> in EAP-GPSK at least the ID_Server attribute is missing in >> message 3. Now, the question is how many EAP server >> identities a client has. I suspect only a single one, with >> the realm name for the entire domain (with respect to a >> particular credential) and how many identities the client uses. >> >> In any case, I agree with the assessment and the need to >> document something in the draft. >> >> Do you agree that the problem is real? >> If yes, what type of solution approach would the group prefer? >> >> Ciao >> Hannes >> >> Reference: >> >> [1] Changhua He, John C. Mitchell. Analysis of the 802.11i >> 4-Way Handshake. In Proceedings of the Third ACM >> International Workshop on Wireless Security (WiSe'04), pages >> 43-50. Philadelphia, PA, Oct. 2004 >> >> >> >> >> >> ______________________________>>_________________ >> Emu mailing list >> Emu@ietf.org >> https://www1.ietf.org/mailman/listinfo/emu >> ------=_Part_8027_25916097.1192977241975 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Regarding the client-side DoS attack in EAP-GPSK: 

The proposed solution is to add ID_Server to message 3, allowing the client to maintain state per server instead of state per message 1 received:

http://www1.ietf.org/mail-archive/web/emu/current/msg00670.html

We agree that this solution seems to solve the issue in the cleanest way.

Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe

>Date: Wed, 3 Oct 2007 21:22:31 -0700
>From: "Joseph Salowey (jsalowey)" < jsalowey@cisco.com>
>Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks
>To: "Tschofenig,        Hannes (NSN - DE/Germany - MiniMD)"
>       < hannes.tschofenig@nsn.com>,    <emu@ietf.org>
>Message-ID:
>      < AC1CFD94F59A264488DC2BEC3E890DE5049B93BB@xmb-sjc-225.amer.cisco.com>
>Content-Type: text/plain;       charset="us-ascii"
>
>I think the problem is real, although not catastrophic.  I would prefer
>not to remove the identity from the key derivation so either option 2 or
>3 is good. I think 2 is maybe a little bit cleaner and 3 is less of a
>change to the existing draft.  Since we do not have many implementations
>yet I would slightly favor 2.
>
>
>
>> -----Original Message-----
>> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
>> [mailto: hannes.tschofenig@nsn.com]
>> Sent: Thursday, September 20, 2007 1:51 AM
>> To: emu@ietf.org
>> Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks
>>
>> Hi all,
>>
>> What is the issue? The first message from the server to the
>> peer is not authenticated. This may allow some kind of denial
>> of service attack against the peer. The peer should be ready
>> to accept new sessions from the same server, so the peer must
>> store one server nonce and one peer nonce for each message 1
>> it receives.  An attacker can then flood the network with
>> fake message 1s to overflow the peer's buffer.  This issue is
>> similar to an issue found in the 802.11i 4-way handshake.
>>
>> When receiving message 1, the peer checks to see if it has
>> open conversations with the server listed in the message.  If
>> it does, then it will reuse the peer nonce it already sent.
>> In addition, it will not store the server nonce, since the
>> server nonce comes back in message 3.
>> Message 3 then contains almost all the information necessary
>> to validate the MAC.  It is only missing the ID_Server.
>> There seem to be three ways to solve this which are discussed
>> in the next paragraph.
>>
>> 1) The first is to drop ID_Server from the input string,
>> allowing the peer to check the MAC without the ID. This might
>> require another NIST review.
>>
>> 2) The second is to add ID_Server to message 3.
>>
>> 3) Thirdly, the peer could iterate through its list of
>> associated servers trying to find one which matches.
>> This allows the peer to store state per server instead of
>> storing state per message.  Since the peer has a fixed (for
>> the duration of a DoS
>> attack) and limited number of associated servers, this fixes
>> the attack.
>>
>> Initially, I was a bit curious about the need to allocate
>> state on the client side with an injected Message 1 by the
>> adversary. The text in Section 4.2 of [1] was, however,
>> convincing that the end host needs to keep state information
>> of multiple sessions even if it only accepts a single one
>> since otherwise you would be able to put the client into a
>> blocking state. [1] focuses on a case where only a single
>> nonce is used in message 3 whereas in EAP-GPSK both nonces
>> are present in message 3.
>> When the client receives message (3) then it needs to derive
>> keying material based on the following info: RAND_Peer,
>> ID_Peer, RAND_Server, ID_Server, RAND_Peer, RAND_Server is in
>> message 3 provided by the server and ID_Peer is known to the
>> peer. The EAP peer may have multiple identities too. Hence,
>> in EAP-GPSK at least the ID_Server attribute is missing in
>> message 3. Now, the question is how many EAP server
>> identities a client has. I suspect only a single one, with
>> the realm name for the entire domain (with respect to a
>> particular credential) and how many identities the client uses.
>>
>> In any case, I agree with the assessment and the need to
>> document something in the draft.
>>
>> Do you agree that the problem is real?
>> If yes, what type of solution approach would the group prefer?
>>
>> Ciao
>> Hannes
>>
>> Reference:
>>
>> [1] Changhua He, John C. Mitchell. Analysis of the 802.11i
>> 4-Way Handshake. In Proceedings of the Third ACM
>> International Workshop on Wireless Security (WiSe'04), pages
>> 43-50. Philadelphia, PA, Oct. 2004
>>
>>
>>
>>
>>
>> ______________________________
>>_________________
>> Emu mailing list
>> Emu@ietf.org
>> https://www1.ietf.org/mailman/listinfo/emu
>>
------=_Part_8027_25916097.1192977241975-- --===============2144461484== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============2144461484==-- From emu-bounces@ietf.org Sun Oct 21 10:36:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijbur-00069k-Go; Sun, 21 Oct 2007 10:36:33 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Ijbup-00068O-5l for emu-confirm+ok@megatron.ietf.org; Sun, 21 Oct 2007 10:36:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ijbuo-00068D-AO for emu@ietf.org; Sun, 21 Oct 2007 10:36:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ijbum-0001QO-PV for emu@ietf.org; Sun, 21 Oct 2007 10:36:30 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2609760uge for ; Sun, 21 Oct 2007 07:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; bh=Ujk+pI4wlKz2GO33J581uIozAJMNY7mq+KaOmO/v1TU=; b=ThjahhgieiLKaebUj9QEaHL8L3UGkkaPGuba8ZEJ3UmaaWG9STwlCCOpwx13NXtDONNX0ecMEAQ+5+Y/dydo9ZNzSDYTEr6epedvPd1m2nFvJStifpcYCsFP2sKpNnxSay4GXrFjwhAU3LbLyOsDFBvEQANCxshhsgF04FHas2s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=AD4BbM+Y935lH507C1BcNPGjraQllYx7byu+2SO8fG+6n36QQycqZ5Rc2jbsfY9Bm89G99Ascb/fPWRSO3RgV/6W2todD/nT2Esd3LBwe2pXvKQaU0I0jUv+MyViMhkgAIlmErAqxpybejLuLtMrlalgQouX+LFWVu3hYtMJXl8= Received: by 10.66.225.9 with SMTP id x9mr5176948ugg.1192977376143; Sun, 21 Oct 2007 07:36:16 -0700 (PDT) Received: by 10.66.249.6 with HTTP; Sun, 21 Oct 2007 07:36:16 -0700 (PDT) Message-ID: <91d0c8280710210736k466a8f40p5efcde88e1e423c4@mail.gmail.com> Date: Sun, 21 Oct 2007 10:36:16 -0400 From: "Paul Rowe" To: emu@ietf.org Subject: Re: [Emu] EAP-GPSK & Key Derivation Function MIME-Version: 1.0 X-Google-Sender-Auth: 24073e017aa3da8a X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0949980500==" Errors-To: emu-bounces@ietf.org --===============0949980500== Content-Type: multipart/alternative; boundary="----=_Part_8041_2062073.1192977376132" ------=_Part_8041_2062073.1192977376132 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Regarding the Key Derivation Function in EAP-GPSK: The proposed solution is to use the long term key PSK as the key for the KDF instead of the constant 0x00. Along with this the draft will include guidelines governing key length for different ciphersuites (including truncating long keys to the appropriate length) as stated in the following: http://www1.ietf.org/mail-archive/web/emu/current/msg00671.html This option looks like a good idea. It seems to appropriately address the concern of using the constant "key" 0x00 while also addressing issues in compatibility of key lengths. Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe > -----Original Message----- > From: Charles Clancy [mailto:clancy@cs.umd.edu] > Sent: Thursday, September 20, 2007 4:11 AM > To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) > Cc: emu@ietf.org > Subject: Re: [Emu] EAP-GPSK & Key Derivation Function > > All, > > My suggestion is adding the following to the GPSK document: > > - For AES ciphersuite say keys MUST be 128 bits in length or > longer, and longer keys be truncated to 128 bits for use > - For HMAC ciphersuite say keys MUST be 256 bits in length or > longer, and longer keys be truncated to 256 bits for use > - RECOMMEND that 256 bit keys be provisioned in all cases to > provide enough entropy for all current and many possible > future ciphersuites > - Add a new section describing requirements on future > ciphersuites that addresses necessary security requirements > and describes their need to specify PSK sizes and how they > deal with different-length keys > > -- > t. charles clancy, ph.d. | tcc@umd.edu | www.cs.umd.edu/~clancy > > Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote: > > Hi all, > > > > What is the issue? The derivation of MK uses "0x00" as a > key for the > > KDF. > > Here is the key derivation step: > > > > MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString) > > ^^^^^ > > Here is the problem. > > > > Here is what Charles recognized during the discussion: > > > > " > > I just looked though the definition of CMAC, the MAC used in one of > > our two ciphersuites, and the zero key looks like it might > cause some > > problems. Unlike the HMAC ciphersuites, it doesn't simply > concatenate > > the key with the data input. The first step is to compute: > > > > k0=E_k(0x00) > > k1=k0*x mod p(x) > > k2=k1*x mod p(x) > > > > These values would always be fixed. During the CBC operation, they > > are XOR'd with the final message block. k1 is XOR'd if the final > > message block's length matches the encryption block length. k2 is > > used otherwise on a message padded with 1000...0000b. > > > > I think what using an all-zero key does is reduce the > security of CMAC > > to the security of CBC-MAC with an all-zeros IV. While the > > ramifications of this are debatable for our applications, > it's still > > probably not a great idea. > > > > Currently we can't use the PSK as the input to the first > KDF because > > its length may not match the selected ciphersuite's block > length. We > > wanted to try to do was have a ciphersuite that could be > implemented > > using only AES. > > " > > > > Do you agree that the problem is real? > > > > If yes, then we believe that there are the following solution steps: > > > > 1) We would need some way to normalize the length of the > PSK for the > > selected ciphersuite. We could define an additional cryptographic > > primitive in every ciphersuite that does this derivation, such as > > SHA256-128 for the AES ciphersuite and SHA256 for the HMAC > ciphersuite. > > > > 2) We could switch to a different KDF, for example to the > one used for > > IKEv2. > > > > Can you come up with other solution approaches? > > > > Which solution approach should we pick? > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > ------=_Part_8041_2062073.1192977376132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Regarding the Key Derivation Function in EAP-GPSK:

The proposed solution is to use the long term key PSK as the key for the KDF instead of the constant 0x00.  Along with this the draft will include guidelines governing key length for different ciphersuites (including truncating long keys to the appropriate length) as stated in the following:

http://www1.ietf.org/mail-archive/web/emu/current/msg00671.html

This option looks like a good idea.  It seems to appropriately address the concern of using the constant "key" 0x00 while also addressing issues in compatibility of key lengths.

Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe


> -----Original Message-----
> From: Charles Clancy [mailto: clancy@cs.umd.edu]
> Sent: Thursday, September 20, 2007 4:11 AM
> To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> Cc: emu@ietf.org
> Subject: Re: [Emu] EAP-GPSK & Key Derivation Function
>
> All,
>
> My suggestion is adding the following to the GPSK document:
>
> - For AES ciphersuite say keys MUST be 128 bits in length or
> longer, and longer keys be truncated to 128 bits for use
> - For HMAC ciphersuite say keys MUST be 256 bits in length or
> longer, and longer keys be truncated to 256 bits for use
> - RECOMMEND that 256 bit keys be provisioned in all cases to
> provide enough entropy for all current and many possible
> future ciphersuites
> - Add a new section describing requirements on future
> ciphersuites that addresses necessary security requirements
> and describes their need to specify PSK sizes and how they
> deal with different-length keys
>
> --
> t. charles clancy, ph.d.  |   tcc@umd.edu  |  www.cs.umd.edu/~clancy
>
> Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote:
> > Hi all,
> >
> > What is the issue? The derivation of MK uses "0x00" as a
> key for the
> > KDF.
> > Here is the key derivation step:
> >
> > MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString)
> >               ^^^^^
> >               Here is the problem.
> >
> > Here is what Charles recognized during the discussion:
> >
> > "
> > I just looked though the definition of CMAC, the MAC used in one of
> > our two ciphersuites, and the zero key looks like it might
> cause some
> > problems.  Unlike the HMAC ciphersuites, it doesn't simply
> concatenate
> > the key with the data input.  The first step is to compute:
> >
> >   k0=E_k(0x00)
> >   k1=k0*x mod p(x)
> >   k2=k1*x mod p(x)
> >
> > These values would always be fixed.  During the CBC operation, they
> > are XOR'd with the final message block.  k1 is XOR'd if the final
> > message block's length matches the encryption block length.  k2 is
> > used otherwise on a message padded with 1000...0000b.
> >
> > I think what using an all-zero key does is reduce the
> security of CMAC
> > to the security of CBC-MAC with an all-zeros IV.  While the
> > ramifications of this are debatable for our applications,
> it's still
> > probably not a great idea.
> >
> > Currently we can't use the PSK as the input to the first
> KDF because
> > its length may not match the selected ciphersuite's block
> length.  We
> > wanted to try to do was have a ciphersuite that could be
> implemented
> > using only AES.
> > "
> >
> > Do you agree that the problem is real?
> >
> > If yes, then we believe that there are the following solution steps:
> >
> > 1) We would need some way to normalize the length of the
> PSK for the
> > selected ciphersuite. We could define an additional cryptographic
> > primitive in every ciphersuite that does this derivation, such as
> > SHA256-128 for the AES ciphersuite and SHA256 for the HMAC
> ciphersuite.
> >
> > 2) We could switch to a different KDF, for example to the
> one used for
> > IKEv2.
> >
> > Can you come up with other solution approaches?
> >
> > Which solution approach should we pick?
> >
> > Ciao
> > Hannes
> >
> >
> > ______________________________
_________________
> > Emu mailing list
> > Emu@ietf.org
> > https://www1.ietf.org/mailman/listinfo/emu
>
>
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www1.ietf.org/mailman/listinfo/emu
>
------=_Part_8041_2062073.1192977376132-- --===============0949980500== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0949980500==-- From emu-bounces@ietf.org Wed Oct 24 09:52:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkgeL-0001ru-0r; Wed, 24 Oct 2007 09:51:57 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IkgeJ-0001qh-Hg for emu-confirm+ok@megatron.ietf.org; Wed, 24 Oct 2007 09:51:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IkgeJ-0001nS-5h for emu@ietf.org; Wed, 24 Oct 2007 09:51:55 -0400 Received: from revol2.enst.fr ([2001:660:330f:2::e] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IkgeC-0006jw-TT for emu@ietf.org; Wed, 24 Oct 2007 09:51:55 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id E7F12B89BD; Wed, 24 Oct 2007 15:51:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id B7613B89A3; Wed, 24 Oct 2007 15:51:32 +0200 (CEST) Received: from VAIO-WI-FI.enst.fr (mechmech.enst.fr [137.194.164.56]) by infres.enst.fr (Postfix) with ESMTP id 758A713CBC; Wed, 24 Oct 2007 15:51:32 +0200 (MEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Oct 2007 15:51:30 +0200 To: "Joseph Salowey (jsalowey)" , From: Pascal Urien Subject: Re: [Emu] Moving forward with the EMU password method In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20071024135132.758A713CBC@infres.enst.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, I support method 2, with the following remarks Under VISTA i have found three tunnels methods already supported, PEAP, EAP-FAST, TTLS. PEAP and TTLS are drafts with multiple versions. EAP-FAST is an RFC All these methods use two phases, phase 1 and phase 2 Phase 1 coding (e.g EAP format) looks similar, i did not have sufficient time to check if they are exactly equivalent (does somebody know that ?) Phase 2 coding is different in every cases. Could it be possible to think about a method with a common phase 1 coding and multiple phase 2 coding ? Cheers Pascal At 20:02 03/10/2007, Joseph Salowey (jsalowey) wrote: >At the IETF in Chicago we had a hum as to the direction we should take >with the password based method. I would like to clarify the choices and >determine working group consensus on the list. The two directions are >given below please express you preference by 10/25. > >Option 1 - Password based method - this option restricts the work item >to what is currently in the charter. The resulting method would have a >new method ID and selecting this method would mean selecting a password >based exchange that meets the requirements we already set forth. The >method may use an existing method as its base. > >Option 2 - Tunneling method - this option requires clarifying the >charter to work on a tunneling method which would then be used to meet >the password method requirements. This would include making sure we >have a valid set of requirements to work with. The working group may >select an existing method as its base and have backwards compatibility >as a goal, however whether the method uses the same method ID and any >modifications to the method will be determined by working group and IETF >consensus. > >Thanks, > >Joe > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Oct 25 19:17:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBwm-0005OT-Vd; Thu, 25 Oct 2007 19:17:04 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1IlBwm-0005NE-2z for emu-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 19:17:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IlBwl-0005Ll-E0 for emu@ietf.org; Thu, 25 Oct 2007 19:17:03 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IlBwk-0001j4-Um for emu@ietf.org; Thu, 25 Oct 2007 19:17:03 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2007 16:17:02 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l9PNH2XL006995; Thu, 25 Oct 2007 16:17:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9PNGt7L012568; Thu, 25 Oct 2007 23:17:02 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 16:17:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Moving forward with the EMU password method Date: Thu, 25 Oct 2007 16:17:14 -0700 Message-ID: In-Reply-To: <20071024135132.758A713CBC@infres.enst.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Moving forward with the EMU password method Thread-Index: AcgWRP79YVLtZ2RiSf6YQnYM5xVGqABF9l1A From: "Joseph Salowey (jsalowey)" To: "Pascal Urien" , X-OriginalArrivalTime: 25 Oct 2007 23:17:00.0734 (UTC) FILETIME=[256CBDE0:01C8175D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2660; t=1193354222; x=1194218222; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20Moving=20forward=20with=20the=20EMU=20passwor d=20method |Sender:=20; bh=ZeC/08O8dRcP14EGhZ07gG9atrU104pKYl8A0FRhidM=; b=oq21ogOPht7b8739MyoonBTvZUh1moZHm2jPzoCNPUy0RfTFgSuLj7AqLBFTk3Y09iVPhf4H 6Wkbx4e/ifxhexnvTbr+AoA4wVYkp2eh9FNYZBIm04U6nYfmRIUHMNxp; Authentication-Results: sj-dkim-6; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org =20 > -----Original Message----- > From: Pascal Urien [mailto:Pascal.Urien@enst.fr]=20 > Sent: Wednesday, October 24, 2007 6:52 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: Re: [Emu] Moving forward with the EMU password method >=20 > Hi Joe, >=20 > I support method 2, with the following remarks >=20 > Under VISTA i have found three tunnels methods already=20 > supported, PEAP, EAP-FAST, TTLS. > PEAP and TTLS are drafts with multiple versions. EAP-FAST is an RFC >=20 > All these methods use two phases, phase 1 and phase 2 >=20 > Phase 1 coding (e.g EAP format) looks similar, i did not=20 > have sufficient time to check if they are exactly > equivalent (does somebody know that ?) >=20 > Phase 2 coding is different in every cases. >=20 > Could it be possible to think about a method with a common=20 > phase 1 coding and multiple phase 2 coding ? >=20 [Joe] While this would be possible, the working group would probably have to select a particular phase 2 coding to be mandatory to implement for interoperability. =20 > Cheers >=20 > Pascal >=20 >=20 >=20 >=20 > At 20:02 03/10/2007, Joseph Salowey (jsalowey) wrote: > >At the IETF in Chicago we had a hum as to the direction we=20 > should take=20 > >with the password based method. I would like to clarify the choices=20 > >and determine working group consensus on the list. The two=20 > directions=20 > >are given below please express you preference by 10/25. > > > >Option 1 - Password based method - this option restricts the=20 > work item=20 > >to what is currently in the charter. The resulting method=20 > would have a=20 > >new method ID and selecting this method would mean selecting=20 > a password=20 > >based exchange that meets the requirements we already set=20 > forth. The=20 > >method may use an existing method as its base. > > > >Option 2 - Tunneling method - this option requires clarifying the=20 > >charter to work on a tunneling method which would then be=20 > used to meet=20 > >the password method requirements. This would include making sure we=20 > >have a valid set of requirements to work with. The working group may=20 > >select an existing method as its base and have backwards=20 > compatibility=20 > >as a goal, however whether the method uses the same method=20 > ID and any=20 > >modifications to the method will be determined by working group and=20 > >IETF consensus. > > > >Thanks, > > > >Joe > > > > > >_______________________________________________ > >Emu mailing list > >Emu@ietf.org > >https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 30 14:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvpy-0002XQ-9p; Tue, 30 Oct 2007 14:29:14 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Imvpx-0002X0-ET for emu-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:29:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvpx-0002Ws-2S for emu@ietf.org; Tue, 30 Oct 2007 14:29:13 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imvpv-0004je-Vh for emu@ietf.org; Tue, 30 Oct 2007 14:29:12 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="183749314" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2007 11:29:03 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIT3KV013463; Tue, 30 Oct 2007 11:29:03 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIT3Jr004551; Tue, 30 Oct 2007 18:29:03 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 11:29:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 11:29:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised liaison response for IEEE 802.11u EAP method for emergency calls Thread-Index: AcgPZscPji/sJWf/ToynicK9zpyQywACIl3gAuteSQA= From: "Joseph Salowey (jsalowey)" To: "Joseph Salowey (jsalowey)" , "Bernard Aboba" , X-OriginalArrivalTime: 30 Oct 2007 18:29:01.0916 (UTC) FILETIME=[BE8319C0:01C81B22] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7924; t=1193768943; x=1194632943; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20Revised=20liaison=20response=20for=20IEEE=20802.11u=2 0EAP=20method=20for=20emergency=20calls |Sender:=20; bh=eSv3S8aYLViYg98SAKIyJFOMJl0+3JY94Shghp9w098=; b=ElUuXqtycOkofjEBPsWREuU/kFVWstGS0ISlopQb6RIsmMkzqkfoepoKH7QaITqz5RfZdo2d vFjQZxgkAvy8oMHe+ceN/9vG9bEOpO0jlWFuaVWonhTh8EempufdzcqU; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: ecrit-chairs@tools.ietf.org Subject: [Emu] RE: Revised liaison response for IEEE 802.11u EAP method for emergency calls X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 802.11u Liaison response for EAP Methods for Emergency Communications=20 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. =20 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. =20 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.=20 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?=20 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 =20 We encourage IEEE working group members to continue the discussion with the IETF in the EMU and the ECRIT working groups.=20 > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > 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=20 > method for emergency calls >=20 > =20 >=20 > > -----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=20 > method for=20 > > emergency calls > >=20 > > >TTLS (draft-funk-eap-ttls-v0-01.txt) and EAP-FAST=20 > (RFC4851) are TLS=20 > > >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. > >=20 > > In general, in TLS-based EAP methods the TLS client authentication=20 > > policy is determined by the server. That is, the server decides=20 > > whether to request a client certificate; RFC 2716=20 > recommends but does=20 > > not require inclusion of a certificate request in the Server hello=20 > > message; in the examples in RFC 2716 the=20 > certificate-request field is=20 > > not shown as mandatory. By not including a certificate request, an=20 > > EAP-TLS server can support anonymous clients. It is my=20 > understanding=20 > > that existing EAP-TLS peer implementations support server-side only=20 > > authentication. > >=20 > [Joe] OK, how about modifying the above sentence to: >=20 > "It is possible for EAP-TLS=20 > (draft-simon-emu-rfc2716bis-11.txt) implementations to=20 > support modes that only require server side authentication." >=20 > > >If the peer can validate the server then it is possible to=20 > mitigate=20 > > >many man-in-the-middle attacks against the authentication, > > however if > > >the peer cannot validate the server then this would leave the=20 > > >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=20 > > >terminated locally instead of in a home server. > > > > > >There were also several questions raised in the working=20 > group during=20 > > >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=20 > > >important for the emergency services network to be > > authenticated? Is > > >it possible for the peer to have a trust root for=20 > emergency services=20 > > >network? Is there expected to be an existing profile with=20 > 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=20 > 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=20 > resistance that=20 > > >PSK, which cases is EAP better? > > > > > >5) It seems that most public access networks already=20 > provide an open=20 > > >access network, why couldn't this network be used for emergency=20 > > >communication? > > > > > >As the 802.11u group is certainly aware, there are other > > groups within > > >the IETF that are looking at unauthenticated emergency=20 > services. In=20 > > >particular, the ECRIT group within the IETF has ongoing=20 > 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. > >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 30 14:29:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvq3-0002YN-EP; Tue, 30 Oct 2007 14:29:19 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Imvq1-0002Y7-Rk for emu-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:29:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvq1-0002Xz-GH for emu@ietf.org; Tue, 30 Oct 2007 14:29:17 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Imvq0-0004jl-JM for emu@ietf.org; Tue, 30 Oct 2007 14:29:17 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="28581458" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 30 Oct 2007 11:29:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l9UITFrT007031; Tue, 30 Oct 2007 11:29:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l9UITDTi013442; Tue, 30 Oct 2007 18:29:13 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 11:29:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks Date: Tue, 30 Oct 2007 11:29:27 -0700 Message-ID: In-Reply-To: <91d0c8280710210734i27624346la1c76b5be769c1ff@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] EAP-GPSK and Client-Side DoS Attacks Thread-Index: AcgT8DfqNe66lP5bR7ym1DnH+vBlvQHKDRWg From: "Joseph Salowey (jsalowey)" To: , "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" , "Charles Clancy" X-OriginalArrivalTime: 30 Oct 2007 18:29:12.0264 (UTC) FILETIME=[C4AE1480:01C81B22] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5991; t=1193768955; x=1194632955; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20EAP-GPSK=20and=20Client-Side=20DoS=20Attacks |Sender:=20; bh=G+MtemnQlyrI5Py4DBX2VZr9tHhCpUWC6CDsujdKyLk=; b=Fz/ytsKhpItqSL2gFvJe8QWrW6eEq+uJeljhoQ/G3BSAsU+tgzFe2WywBD1yZfwhLbwPhdnX t7P7WlmvqojRs/TtFMDYccMKre5XlZi+8zqkjW1tP9u5Z5SpQaUCgLo7; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Paul Rowe X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org GPSK authors, Please update the draft to reflect the addition of the ID_Server to message 3 and the key derivation proposal. =20 Thanks, Joe=20 > -----Original Message----- > From: Paul Rowe [mailto:rowep@math.upenn.edu]=20 > Sent: Sunday, October 21, 2007 7:34 AM > To: emu@ietf.org > Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks >=20 > Regarding the client-side DoS attack in EAP-GPSK: =20 >=20 > The proposed solution is to add ID_Server to message 3,=20 > allowing the client to maintain state per server instead of=20 > state per message 1 received: >=20 > http://www1.ietf.org/mail-archive/web/emu/current/msg00670.html=20 >=20 > We agree that this solution seems to solve the issue in the=20 > cleanest way. >=20 > Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe >=20 > >Date: Wed, 3 Oct 2007 21:22:31 -0700 > >From: "Joseph Salowey (jsalowey)" < jsalowey@cisco.com=20 > > > > >Subject: RE: [Emu] EAP-GPSK and Client-Side DoS Attacks > >To: "Tschofenig, Hannes (NSN - DE/Germany - MiniMD)" > > < hannes.tschofenig@nsn.com=20 > >, > >Message-ID: > > <=20 > AC1CFD94F59A264488DC2BEC3E890DE5049B93BB@xmb-sjc-225.amer.cisc > o.com=20 > mer.cisco.com> > > >Content-Type: text/plain; charset=3D"us-ascii" > > > >I think the problem is real, although not catastrophic. I=20 > would prefer=20 > >not to remove the identity from the key derivation so either=20 > option 2=20 > >or > >3 is good. I think 2 is maybe a little bit cleaner and 3 is=20 > less of a=20 > >change to the existing draft. Since we do not have many=20 > >implementations yet I would slightly favor 2. > > > > > > > >> -----Original Message----- > >> From: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) > >> [mailto: hannes.tschofenig@nsn.com=20 > =20 > >> ] > >> Sent: Thursday, September 20, 2007 1:51 AM > >> To: emu@ietf.org > >> Subject: [Emu] EAP-GPSK and Client-Side DoS Attacks > >> > >> Hi all, > >> > >> What is the issue? The first message from the server to=20 > the peer is=20 > >> not authenticated. This may allow some kind of denial of service=20 > >> attack against the peer. The peer should be ready to accept new=20 > >> sessions from the same server, so the peer must store one server=20 > >> nonce and one peer nonce for each message 1 it receives. =20 > An attacker=20 > >> can then flood the network with fake message 1s to overflow the=20 > >> peer's buffer. This issue is similar to an issue found in the=20 > >> 802.11i 4-way handshake. > >> > >> When receiving message 1, the peer checks to see if it has open=20 > >> conversations with the server listed in the message. If it does,=20 > >> then it will reuse the peer nonce it already sent. > >> In addition, it will not store the server nonce, since the server=20 > >> nonce comes back in message 3. > >> Message 3 then contains almost all the information necessary to=20 > >> validate the MAC. It is only missing the ID_Server. > >> There seem to be three ways to solve this which are=20 > discussed in the=20 > >> next paragraph. > >> > >> 1) The first is to drop ID_Server from the input string,=20 > allowing the=20 > >> peer to check the MAC without the ID. This might require=20 > another NIST=20 > >> review. > >> > >> 2) The second is to add ID_Server to message 3. > >> > >> 3) Thirdly, the peer could iterate through its list of associated=20 > >> servers trying to find one which matches. > >> This allows the peer to store state per server instead of storing=20 > >> state per message. Since the peer has a fixed (for the=20 > duration of a=20 > >> DoS > >> attack) and limited number of associated servers, this fixes the=20 > >> attack. > >> > >> Initially, I was a bit curious about the need to allocate state on=20 > >> the client side with an injected Message 1 by the=20 > adversary. The text=20 > >> in Section 4.2 of [1] was, however, convincing that the end host=20 > >> needs to keep state information of multiple sessions even=20 > if it only=20 > >> accepts a single one since otherwise you would be able to put the=20 > >> client into a blocking state. [1] focuses on a case where only a=20 > >> single nonce is used in message 3 whereas in EAP-GPSK both=20 > nonces are=20 > >> present in message 3. > >> When the client receives message (3) then it needs to=20 > derive keying=20 > >> material based on the following info: RAND_Peer, ID_Peer,=20 > >> RAND_Server, ID_Server, RAND_Peer, RAND_Server is in message 3=20 > >> provided by the server and ID_Peer is known to the peer.=20 > The EAP peer=20 > >> may have multiple identities too. Hence, in EAP-GPSK at least the=20 > >> ID_Server attribute is missing in message 3. Now, the=20 > question is how=20 > >> many EAP server identities a client has. I suspect only a=20 > single one,=20 > >> with the realm name for the entire domain (with respect to a=20 > >> particular credential) and how many identities the client uses. > >> > >> In any case, I agree with the assessment and the need to document=20 > >> something in the draft. > >> > >> Do you agree that the problem is real? > >> If yes, what type of solution approach would the group prefer? > >> > >> Ciao > >> Hannes > >> > >> Reference: > >> > >> [1] Changhua He, John C. Mitchell. Analysis of the 802.11i 4-Way=20 > >> Handshake. In Proceedings of the Third ACM International=20 > Workshop on=20 > >> Wireless Security (WiSe'04), pages 43-50. Philadelphia,=20 > PA, Oct. 2004 > >> > >> > >> > >> > >> > >> ______________________________ > >>_________________ > >> Emu mailing list > >> Emu@ietf.org > >> https://www1.ietf.org/mailman/listinfo/emu=20 > >> > >> >=20 >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 30 14:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imvxy-0002dH-Io; Tue, 30 Oct 2007 14:37:30 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1ImvpX-0002G0-QR for emu-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:28:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImvpX-0002Fp-Fw for emu@ietf.org; Tue, 30 Oct 2007 14:28:47 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImvpX-0004iz-64 for emu@ietf.org; Tue, 30 Oct 2007 14:28:47 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="541395424" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 30 Oct 2007 11:28:46 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l9UISkv7023287 for ; Tue, 30 Oct 2007 11:28:46 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIShKB004042 for ; Tue, 30 Oct 2007 18:28:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 11:28:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Oct 2007 11:28:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Password Method Consensus Thread-Index: AcgbIr1LLPOd5d7xQYmIi1N7pQ69Zw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 30 Oct 2007 18:28:44.0905 (UTC) FILETIME=[B45F6D90:01C81B22] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=447; t=1193768926; x=1194632926; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Password=20Method=20Consensus |Sender:=20; bh=f1D8uk3DjHfRjX9WvuROKbp7Yn1jbYvgDGMFSaDVE+Q=; b=ETGC39EZzr2bP8mXA6+njNdAPV/+3ABlhH66cvSIHCOYPYudnAuSnkoo7gJ2MTT4206F/pSn YVXGkY4sPDGS2k+AEqOyRKOsnTP2cJGjJTw1xJGyK/sjR17Ri4h+o+d+; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Tue, 30 Oct 2007 14:37:29 -0400 Subject: [Emu] Password Method Consensus X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org We have working group consensus to move forward with working on a tunneled EAP method in order to provide the basis for a password based EAP method. The next steps are to revise the working group charter to include the tunneled EAP method item and make sure we have a good set of requirements to work against. I believe we already have a good start at requirements. Any volunteers to help document and track the requirements? =20 Joe _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 30 14:48:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imw8J-0006ME-FP; Tue, 30 Oct 2007 14:48:11 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1Imw8I-0006M7-GX for emu-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 14:48:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Imw8I-0006Lt-6W for emu@ietf.org; Tue, 30 Oct 2007 14:48:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Imw8G-0007pj-IX for emu@ietf.org; Tue, 30 Oct 2007 14:48:10 -0400 X-IronPort-AV: E=Sophos;i="4.21,348,1188802800"; d="scan'208";a="183764733" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 30 Oct 2007 11:48:07 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l9UIm7CB022577 for ; Tue, 30 Oct 2007 11:48:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l9UIm6Jt029553 for ; Tue, 30 Oct 2007 18:48:07 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Oct 2007 14:48:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Emu] Password Method Consensus Date: Tue, 30 Oct 2007 14:49:13 -0400 Message-ID: <9958B444368E884DBB215F3FEF36F5B70595CFBB@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Password Method Consensus Thread-Index: AcgbIr1LLPOd5d7xQYmIi1N7pQ69ZwAAs2ow References: From: "Hao Zhou (hzhou)" To: "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 30 Oct 2007 18:48:03.0527 (UTC) FILETIME=[66F71D70:01C81B25] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15514.002 X-TM-AS-Result: No--16.658100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=841; t=1193770087; x=1194634087; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20(hzhou)=22=20 |Subject:=20RE=3A=20[Emu]=20Password=20Method=20Consensus |Sender:=20; bh=6mYJmyJQ5tHuLqpLowrIwA/esYCp7Zx68Xa0zp5qXDY=; b=C4DlKsunCGs7+t4lmMZ2m8ghjF4bNODeTgc3B8er3hgH+Kq16nrcHy9XP7F9HdRtXhcFLe+u ph4pjY0NLsUMwxoZygPcZMivxoSqOQ+yChFfLPIrcviXFgMQFacFHryD; Authentication-Results: sj-dkim-2; header.From=hzhou@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I can help.=20 > -----Original Message----- > From: Joseph Salowey (jsalowey)=20 > Sent: Tuesday, October 30, 2007 2:29 PM > To: emu@ietf.org > Subject: [Emu] Password Method Consensus >=20 > We have working group consensus to move forward with working=20 > on a tunneled EAP method in order to provide the basis for a=20 > password based EAP method. The next steps are to revise the=20 > working group charter to include the tunneled EAP method item=20 > and make sure we have a good set of requirements to work=20 > against. I believe we already have a good start at=20 > requirements. Any volunteers to help document and track the=20 > requirements? =20 >=20 > Joe >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu >=20 _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Oct 30 15:15:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwYC-0006yW-0Y; Tue, 30 Oct 2007 15:14:56 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1ImwYA-0006yR-IX for emu-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 15:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImwYA-0006sx-8j for emu@ietf.org; Tue, 30 Oct 2007 15:14:54 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImwXy-0000W7-0r for emu@ietf.org; Tue, 30 Oct 2007 15:14:49 -0400 Received: by ug-out-1314.google.com with SMTP id u2so559427uge for ; Tue, 30 Oct 2007 12:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=c4ailI/kgAjteA1raBzbeOUJVJ/m2zKwItuZbOxy544=; b=R7VaxQwpfl/mEY3DwFDc1iSuTItS5Dp83Nwo0hc0axmw3tGo0TUp9IGVZljZOce3lGqdX+y6cbp/5ENTAT2egZdodhwx+93TAA3OgOhx0PB+daQL4KAb+TJ3uGF7U4wsDVPFS6P4cHXtq/dusqXG5/hCu7+PlCsU2QKdipZzTQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=uNLjW3rWLvcsMcWk3pEhupC2lIoM7UAxE2R9KpwUQx8RFFj/JQSMQFLBjRwhmeliNmjBwaTu7zO7kgD0Fyo3Qkz7jqNutXrQ8hVkKwf3OURhLgo6xe/pBDpBf4B3CF2eBE9LoRm745OLIHBimkKcQKPHx28OUWDxUIGBYWnInbE= Received: by 10.78.168.1 with SMTP id q1mr5475820hue.1193771662194; Tue, 30 Oct 2007 12:14:22 -0700 (PDT) Received: by 10.78.20.9 with HTTP; Tue, 30 Oct 2007 12:14:22 -0700 (PDT) Message-ID: Date: Tue, 30 Oct 2007 20:14:22 +0100 From: Badra To: "Joseph Salowey (jsalowey)" Subject: Re: [Emu] Password Method Consensus In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0470880784==" Errors-To: emu-bounces@ietf.org --===============0470880784== Content-Type: multipart/alternative; boundary="----=_Part_4402_21278094.1193771662193" ------=_Part_4402_21278094.1193771662193 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Joe, Please add me to the list of volunteers. Best regards, Badra On 10/30/07, Joseph Salowey (jsalowey) wrote: > > We have working group consensus to move forward with working on a > tunneled EAP method in order to provide the basis for a password based > EAP method. The next steps are to revise the working group charter to > include the tunneled EAP method item and make sure we have a good set of > requirements to work against. I believe we already have a good start at > requirements. Any volunteers to help document and track the > requirements? > > Joe > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu ------=_Part_4402_21278094.1193771662193 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Joe,
 
Please add me to the list of volunteers.
 
Best regards,
Badra

 
On 10/30/07, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
We have working group consensus to move forward with working on a
tunneled EAP method in order to provide the basis for a password based
EAP method.  The next steps are to revise the working group charter to
include the tunneled EAP method item and make sure we have a good set of
requirements to work against.  I believe we already have a good start at
requirements.  Any volunteers to help document and track the
requirements?

Joe


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu 
------=_Part_4402_21278094.1193771662193-- --===============0470880784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu --===============0470880784==-- From emu-bounces@ietf.org Tue Oct 30 17:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImyqQ-0004EH-DN; Tue, 30 Oct 2007 17:41:54 -0400 Received: from emu by megatron.ietf.org with local (Exim 4.43) id 1ImyqP-0004E6-5Q for emu-confirm+ok@megatron.ietf.org; Tue, 30 Oct 2007 17:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImyqO-0004Dw-Rl for emu@ietf.org; Tue, 30 Oct 2007 17:41:52 -0400 Received: from revol2.enst.fr ([2001:660:330f:2::e] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImyqI-0007od-Jz for emu@ietf.org; Tue, 30 Oct 2007 17:41:52 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id A7696B832E; Tue, 30 Oct 2007 22:41:30 +0100 (CET) X-Virus-Scanned: amavisd-new at enst.fr Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 78124B833E; Tue, 30 Oct 2007 22:41:30 +0100 (CET) Received: from VAIO-WI-FI.enst.fr (pptp20-19.enst.fr [137.194.20.19]) by infres.enst.fr (Postfix) with ESMTP id C5D1713CBC; Tue, 30 Oct 2007 22:41:29 +0100 (MET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 30 Oct 2007 22:41:22 +0100 To: "Joseph Salowey (jsalowey)" , From: Pascal Urien Subject: Re: [Emu] Password Method Consensus In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20071030214129.C5D1713CBC@infres.enst.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Joe, I am ready to help Pascal At 19:28 30/10/2007, Joseph Salowey (jsalowey) wrote: >We have working group consensus to move forward with working on a >tunneled EAP method in order to provide the basis for a password based >EAP method. The next steps are to revise the working group charter to >include the tunneled EAP method item and make sure we have a good set of >requirements to work against. I believe we already have a good start at >requirements. Any volunteers to help document and track the >requirements? > >Joe > > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu