From eap-admin@frascone.com Mon Dec 1 05:00:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03653 for ; Mon, 1 Dec 2003 05:00:03 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 022BC580017; Mon, 1 Dec 2003 04:00:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 558E2580027; Mon, 1 Dec 2003 04:00:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6D10E580017 for ; Mon, 1 Dec 2003 03:59:55 -0600 (CST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.74.5]) by mail.frascone.com (Postfix) with ESMTP id 5F697580014 for ; Mon, 1 Dec 2003 03:59:53 -0600 (CST) Received: from cisco.com (144.254.74.60) by ams-iport-1.cisco.com with ESMTP; 01 Dec 2003 10:57:06 +0100 Received: from xbe-ams-312.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id hB19xcXG016503; Mon, 1 Dec 2003 10:59:39 +0100 (MET) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Dec 2003 10:59:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: network discovery & selection: problem definition Message-ID: Thread-Topic: [eap] Re: network discovery & selection: problem definition Thread-Index: AcO3WKZzRjs77Y8xSEmYnl3+h/LmHAAmJOXw From: "Mark Grayson (mgrayson)" To: "Bernard Aboba" , X-OriginalArrivalTime: 01 Dec 2003 09:59:50.0887 (UTC) FILETIME=[DC614770:01C3B7F1] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Dec 2003 10:59:50 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Bernard I would add a further level of decomposition to the section on Network Discovery to allow separation of the dicovery of the (802.11) access network and, since this may in turn be a common infrastructure shared between a numper of service providers, the dicovery of the service providers using this infrastructure.=20 Cheers, Mark -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Bernard Aboba Sent: 30 November 2003 16:00 To: eap@frascone.com Subject: [eap] Re: network discovery & selection: problem definition I'd suggest that there are three somewhat orthogonal problems being discussed under the rubric of "network selection". First, there is the problem of "Network discovery". This is the problem of discovering access networks available in the vicinity, and the points of presence (POPs) associated with those networks. Second, there is the problem of "Identifier selection". This is the problem of selecting which identity (and credentials) to use to authenticate to a given POP. Thirdly, there is the problem of "Access routing" which involves figuring out how to route the authentication conversation originating from the selected identity back to the home realm. Network Discovery ----------------- Traditionally, the problem of discovering available networks has been handled out-of-band of EAP. RFC 2194 describes the pre-provisioning of dialup roaming clients, which typically included a list of potential phone numbers, updated by the provider(s) with which the client had a contractual relationship. RFC 3017 describes the IETF Proposed Standard for the Roaming Access XML DTD. This covers not only the attributes of the Points of Presence (POPs) and Internet Service Providers (ISPs), but also hints on the appropriate NAI to be used with a particular POP. In IEEE 802.11 WLANs, the Beacon/Probe Request/Response mechanism provides a way for Stations to discover Access Points (APs), as well as the capabilities of those APs. Among the Information Elements (IEs) included within the Beacon and Probe Response is the SSID, a non-unique identifier of the network to which an Access Point is attached. By combining network identification along with capabilities discovery, the Beacon/Probe facility provides the information required for both network discovery and roaming decisions within a single mechanism. As noted in [Velayos], the Beacon mechanism does not scale well; with a Beacon interval of 100ms, and 10 APs in the vicinity, approximately 32 percent of an 802.11b AP's capacity is used for beacon transmission. In addition, since Beacon/Probe Response frames are sent by each AP over the wireless medium, stations can only discover APs within range, which implies substantial coverage overlap for roaming to occur without interruption. A number of enhancements have been proposed to the Beacon/Probe Response mechanism in order to improve scalability and roaming performance. These include allowing APs to announce capabilities of neighbor APs as well as their own, as proposed in IEEE 802.11k; propagation of discovery information over IP, as handled in the CARD protocol developed within the IETF SEAMOBY WG, etc. Typically scalability enhancement mechanisms attempt to get around Beacon/Probe Response restrictions by sending advertisements at the higher rates which are enabled one the station has associated with an AP. Since these mechanisms run over IP, they can utilize IP facilities such as fragmentation, which the Beacon/Probe Response mechanism cannot. Identity selection ------------------ As networks proliferate, it becomes more and more likely that a given EAP peer may have multiple identities and credential sets, available for use in different situations. For example, the EAP peer may have an account with one or more Public WLAN providers; a corporate WLAN; one or more wireless WAN providers. As a result, the EAP peer has to decide which credential set to use when presented with a given set of potential EAP authenticators. Traditionally, hints useful in identity selection have also been provided out-of-band. For example, via the IETF Proposed Standard Roaming Access XML DTD, a client can select between potential POPs, and then based on information provided in the DTD, determine the appropriate NAI to use with the selected POP. However, it is also possible for hints to be embedded within credentials. In [Housley], usage hints are provided within certificates used for wireless authentication. This involves extending the certificate to include the SSIDs with which the certificate can be used. Access routing -------------- Once the identity has been selected, it is necessary for the authentication conversation to be routed back to the home realm. Within the IETF ROAMOPS WG, a number of approaches were considered for this, including source routing techniques based on the NAI [RFC2486], and techniques relying on the AAA infrastructure. Given the relative simplicity of the roaming implementations described in RFC 2194, static routing mechanisms appeared adequate for the task and it was not deemed necessary to develop dynamic routing protocols. As noted in RFC 2607, RADIUS proxies are deployed not only for routing purposes, but also to mask a number of inadequacies in the RADIUS protocol design, such as the lack of standarized retransmission behavior and the need for shared secret provisioning. By removing many of the protocol inadequacies, introducing new AAA agent types such as Redirects, providing support for certificate-based authentication as well as inter and intra-domain service discovery, Diameter allows a NAS to directly open a Diameter connection to the home realm without having to utilize a network of proxies. This is somewhat analagous to the evolution of email delivery. Prior to the widespread proliferation of the Internet, it was necessary to gateway between SMTP-based mail systems and alternative delivery technologies, such as UUCP and FidoNet, and email-address based source-routing was used to handle this. However, as mail could increasingly be delivered directly, the use of source routing disappeared. As with the selection of certificates by stations, a Diameter client wishing to authenticate with a Diameter server may have a choice of available certificates, and therefore it may need to choose between them. References ---------- [Housley] Housley, R., and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in PPP and Wireless LAN", draft-ietf-pkix-wlan-extns-04.txt, Internet Draft (work in progress), June 2003. [Mishra] Mishra, A., Shin, M. and W. Arbaugh, "An empirical analysis of the IEEE 802.11 MAC layer handoff process", University of Maryland Technical Report, UMIACS-TR-2002-75, 2002. [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce IEEE 802.11b MAC Layer Handover Time", Laboratory for Communication Networks, KTH, Royal Institute of Technology, Stockholm, Sweden, TRITA-IMIT-LCN R 03:02 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From diameter-admin@frascone.com Mon Dec 1 06:02:22 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05889 for ; Mon, 1 Dec 2003 06:02:21 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 86873580261 for ; Mon, 1 Dec 2003 05:02:34 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D5275801E2 for ; Mon, 1 Dec 2003 05:00:55 -0600 (CST) Date: Mon, 01 Dec 2003 05:00:55 -0600 Message-ID: <20031201110055.8853.84211.Mailman@wolverine> Subject: frascone.com mailing list memberships reminder From: mailman-owner@wolverine.frascone.com To: eap-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: diameter-admin@frascone.com Errors-To: diameter-admin@frascone.com X-BeenThere: diameter@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a reminder, sent out once a month, about your frascone.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, eap-request@frascone.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@wolverine. Thanks! Passwords for eap-archive@lists.ietf.org: List Password // URL ---- -------- eap@frascone.com ohweow http://mail.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org From eap-admin@frascone.com Mon Dec 1 06:16:22 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06192 for ; Mon, 1 Dec 2003 06:16:19 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 611E5580063; Mon, 1 Dec 2003 05:16:31 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B047C580126; Mon, 1 Dec 2003 05:16:09 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67C42580133 for ; Mon, 1 Dec 2003 05:15:06 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 13375580854 for ; Mon, 1 Dec 2003 05:06:21 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 500B66A901; Mon, 1 Dec 2003 13:06:19 +0200 (EET) Message-ID: <3FCB1F9E.5010901@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Cc: "eap@frascone.com" , Robert Moskowitz Subject: Re: [eap] network discovery & selection: problem definition References: <14866.1070227007@marajade.sandelman.ottawa.on.ca> In-Reply-To: <14866.1070227007@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 13:01:50 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Michael Richardson wrote: > Jari> We could call this the "payload route binding problem". In this > Jari> problem, authentication and l2 support do not guarantee that > Jari> the packets are actually routed through the path that appears to have > Jari> been offered. Basically, if I have a flat fee account *and* a deal > > If I took a shared key from the EAP EMSK somewhere, and used that to > authenticate the DHCP server (3118), it might have a serious positive > benefit. > > In v6 land, we could use the channel created by EAP to provide the > certificates for the SEND secured RA. Both ways, that means that we are > sure we are speaking at layer 3 to the services that we authenticated at > layer two. This is interesting. But, as far as I can see, this does not completely solve the problem. In v4, the attacking node would simply offer its own DHCP server, the user would authenticate it and get an internal IP address from it. Then the attacking node would NAT all the packets to an address provided by the real bandwidth provider. The situation isn't much better in v6, except that we might perhaps expect or even verify that there is no NATs in between. If we could do that, then the RA signatures are sufficient to bind our own address - router - access authentication together. And if the attacker tunnels everything through the access network to a centrally placed server, then neither EMSK or RA certs are going to be very helpful. But in this case the attacker would have to provide at least some central bandwidth, even if he can skip the provisioning of the access network. I'm ccing Bob because he was recently interested in certificates handed out from L2. > I'd like a way to avoid the attack by careful network selection. > If you think it is out of scope - that's fine. But it is, in my opinion Its probably in scope for IETF to figure out, but this might also be bigger than network selection issue and handled separately. Anyway, lets focus on mapping what the problem is, when that concludes we can think about how to divide the work. > one of the major things that has fallen through the cracks between IETF > and IEEE. Agreed. Part of the reason for this is that the understanding of various binding issues has only grown recently... and I think we are still learning, as far it comes to IP vs. L2 issues. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 07:08:56 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07214 for ; Mon, 1 Dec 2003 07:08:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58152580014; Mon, 1 Dec 2003 06:09:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85CB4580027; Mon, 1 Dec 2003 06:09:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E8F23580027 for ; Mon, 1 Dec 2003 06:08:40 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 3D83B580014 for ; Mon, 1 Dec 2003 06:08:39 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 947576A902; Mon, 1 Dec 2003 14:08:38 +0200 (EET) Message-ID: <3FCB2E39.2010700@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com, Michael Richardson Subject: Re: [eap] Re: [Issue 200] channel binding threats References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 14:04:09 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > It seems to me that the "false SSID" attack brought up by Michael > Richardson as part of the "network selection" thread is another variation > on the "channel binding" attack that is discussed in Issue 200. That is, > the AP advertises an SSID to the user, but presumably does not include > this SSID in the Called-Station-Id sent to the AAA server. Right. > Can someone take a look at the proposed resolution of Issue 200 and > determine whether the issue is being adequately handled? My understanding > is that including an exchange of SSIDs within the EAP method would allow > the station and AAA server to determine that the AP had launched this > attack. I think it is adequately handled by the resolution which is given at drizzle.com. (It might have made sense to add a specific example of the SSID lying. But its not so important. Or perhaps that could be done in AUTH48 if we get there with 2284bis.) Michael: the issue 200 text is at http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20200 --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 11:41:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16945 for ; Mon, 1 Dec 2003 11:40:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9A5E3580126; Mon, 1 Dec 2003 10:41:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07E50580027; Mon, 1 Dec 2003 10:41:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 08F7C580127 for ; Mon, 1 Dec 2003 10:40:16 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (noxmail.sandelman.ottawa.on.ca [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 15CE9580063 for ; Mon, 1 Dec 2003 10:40:06 -0600 (CST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hB1Gcit15541; Mon, 1 Dec 2003 11:38:45 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hB1Gg8n05530; Mon, 1 Dec 2003 11:42:08 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB1GWgpH009671 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Dec 2003 11:32:42 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB1GWR9G009667; Mon, 1 Dec 2003 11:32:29 -0500 To: "eap@frascone.com" Cc: jari.arkko@piuha.net, Robert Moskowitz Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: Your message of "Mon, 01 Dec 2003 13:01:50 +0200." <3FCB1F9E.5010901@piuha.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <9666.1070296347@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 11:32:27 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: Jari> Michael Richardson wrote: Jari> We could call this the "payload route binding problem". In this Jari> problem, authentication and l2 support do not guarantee that the Jari> packets are actually routed through the path that appears to have Jari> been offered. Basically, if I have a flat fee account *and* a deal >> If I took a shared key from the EAP EMSK somewhere, and used that to >> authenticate the DHCP server (3118), it might have a serious positive >> benefit. >> >> In v6 land, we could use the channel created by EAP to provide the >> certificates for the SEND secured RA. Both ways, that means that we >> are sure we are speaking at layer 3 to the services that we >> authenticated at layer two. Jari> This is interesting. But, as far as I can see, this does not Jari> completely solve the problem. In v4, the attacking node would Jari> simply offer its own DHCP server, the user would authenticate it Jari> and get an internal IP address from it. Then the attacking node Jari> would NAT all the packets to an address provided by the real Jari> bandwidth provider. Assuming that we can solve the original layer 2 problem - of authenticating with the right AP, then we can also solve the equivalent layer 3 problem >> I'd like a way to avoid the attack by careful network selection. If >> you think it is out of scope - that's fine. But it is, in my opinion ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8ttGYqHRg3pndX9AQF1FwQAxz5MWytsltFJZmpnLNqAHxxyU8L1NC7f a+cZquEqbCP9DS8nLD6tNjVZC5qAzW3HTr0DkpQbFFvvu658ilG8RPq/Yv8lDftm IVMwzpjF5tuP1yn1kVwFxVXSLjxm4/Hj+d8+ctwxt5s3xnJjEz+ufvUO0NtmCIIP Ir+OWTbryKY= =xUwb -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 12:03:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17795 for ; Mon, 1 Dec 2003 12:02:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1DCEF580063; Mon, 1 Dec 2003 11:03:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6F2B4580109; Mon, 1 Dec 2003 11:03:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE20B580127 for ; Mon, 1 Dec 2003 11:02:35 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 5072E580109 for ; Mon, 1 Dec 2003 11:02:31 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0DE7D6A901; Mon, 1 Dec 2003 19:02:30 +0200 (EET) Message-ID: <3FCB7318.1040601@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Cc: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition References: <9666.1070296347@marajade.sandelman.ottawa.on.ca> In-Reply-To: <9666.1070296347@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 18:58:00 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>>>"Jari" == Jari Arkko writes: > > Jari> Michael Richardson wrote: > > Jari> We could call this the "payload route binding problem". In this > Jari> problem, authentication and l2 support do not guarantee that the > Jari> packets are actually routed through the path that appears to have > Jari> been offered. Basically, if I have a flat fee account *and* a deal > >> If I took a shared key from the EAP EMSK somewhere, and used that to > >> authenticate the DHCP server (3118), it might have a serious positive > >> benefit. > >> > >> In v6 land, we could use the channel created by EAP to provide the > >> certificates for the SEND secured RA. Both ways, that means that we > >> are sure we are speaking at layer 3 to the services that we > >> authenticated at layer two. > > Jari> This is interesting. But, as far as I can see, this does not > Jari> completely solve the problem. In v4, the attacking node would > Jari> simply offer its own DHCP server, the user would authenticate it > Jari> and get an internal IP address from it. Then the attacking node > Jari> would NAT all the packets to an address provided by the real > Jari> bandwidth provider. > > Assuming that we can solve the original layer 2 problem - of authenticating > with the right AP, then we can also solve the equivalent layer 3 problem Why? Perhaps I'm missing something obvious. But even if I authenticate Gamma to be Gamma in IEEE/EAP/AAA, and Gamma's router in SEND, Gamma can still NAT all my traffic and send it off to Delta. But perhaps you are thinking that the user will see "Gamma" on his screen and cry foul. I'm not very optimistic that most users would do this... Even you and I might have trouble understanding whether "Gamma Global Roaming WLAN" is a legal, another SSID on a virtualized "Delta" AP or a bad guy performing an attack. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 13:01:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20242 for ; Mon, 1 Dec 2003 13:01:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F8A6580017; Mon, 1 Dec 2003 12:02:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D7A6580027; Mon, 1 Dec 2003 12:02:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 99301580017 for ; Mon, 1 Dec 2003 12:01:36 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (unknown [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 974F3580027 for ; Mon, 1 Dec 2003 12:01:32 -0600 (CST) Received: from lox.sandelman.ottawa.on.ca (IDENT:root@lox.sandelman.ottawa.on.ca [205.150.200.178]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hB1I1Et15886; Mon, 1 Dec 2003 13:01:14 -0500 (EST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lox.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hB1I31t10156; Mon, 1 Dec 2003 13:03:42 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB1HoMpH011808 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 1 Dec 2003 12:50:22 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB1HoLkM011804; Mon, 1 Dec 2003 12:50:21 -0500 To: "eap@frascone.com" Cc: jari.arkko@piuha.net Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: Your message of "Mon, 01 Dec 2003 18:58:00 +0200." <3FCB7318.1040601@piuha.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <11803.1070301021@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 12:50:21 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Jari" == Jari Arkko writes: >> Assuming that we can solve the original layer 2 problem - of >> authenticating with the right AP, then we can also solve the >> equivalent layer 3 problem Jari> Why? Perhaps I'm missing something obvious. But even if I Jari> authenticate Gamma to be Gamma in IEEE/EAP/AAA, and Gamma's router Jari> in SEND, Gamma can still NAT all my traffic and send it off to Jari> Delta. Jari> But perhaps you are thinking that the user will see "Gamma" on his Jari> screen and cry foul. I'm not very optimistic that most users would Jari> do this... Even you and I might have trouble understanding whether Jari> "Gamma Global Roaming WLAN" is a legal, another SSID on a Jari> virtualized "Delta" AP or a bad guy performing an attack. Of course. And his bill will say "Gamma". And if necessary, the customer can dispute it. But, the customer now has the tools to prevent this abuse. If they choose not to, well, fine. That's not our problem. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP8t/WoqHRg3pndX9AQHB/wQA54JxZu55+ii5g/ESUldjCvQdQKZQd3N8 mVOwtN3waR4JRWt0iXpKFIM2XmYrdHdy/t5Z81/d3F8d1npURPzOARXy1oHHZZR2 tnEfofmJXSPhpwc6JWHz07VJLBlw92fVBgizI1LP5yl5GACEvOKuimQr4bTNvnwX fVRU7aNWklE= =f/kR -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 15:43:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28389 for ; Mon, 1 Dec 2003 15:43:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 00373580017; Mon, 1 Dec 2003 14:44:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 75CF1580027; Mon, 1 Dec 2003 14:44:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 80895580027 for ; Mon, 1 Dec 2003 14:43:17 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A9FA3580017 for ; Mon, 1 Dec 2003 14:43:15 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B94086A901; Mon, 1 Dec 2003 22:43:14 +0200 (EET) Message-ID: <3FCBA6D5.7070708@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Richardson Cc: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition References: <11803.1070301021@marajade.sandelman.ottawa.on.ca> In-Reply-To: <11803.1070301021@marajade.sandelman.ottawa.on.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 22:38:45 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Michael Richardson wrote: > Jari> Why? Perhaps I'm missing something obvious. But even if I > Jari> authenticate Gamma to be Gamma in IEEE/EAP/AAA, and Gamma's router > Jari> in SEND, Gamma can still NAT all my traffic and send it off to > Jari> Delta. > > Jari> But perhaps you are thinking that the user will see "Gamma" on his > Jari> screen and cry foul. I'm not very optimistic that most users would > Jari> do this... Even you and I might have trouble understanding whether > Jari> "Gamma Global Roaming WLAN" is a legal, another SSID on a > Jari> virtualized "Delta" AP or a bad guy performing an attack. > > Of course. And his bill will say "Gamma". > And if necessary, the customer can dispute it. > > But, the customer now has the tools to prevent this abuse. If they choose > not to, well, fine. That's not our problem. Ok. I think we agree now. In terms of what to do about it: Bernard and Henrik have added some words to the 2284bis document to describe the (general) issue related to fraudulent claims of authenticators. They have also added a requirement that method specs should say whether or not they offer some protection for this. Can you take a look if you like the text: http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20200 (Solution space: my gut feeling is that this is bigger than individual methods or network selection, and needs to be handled in a general fashion. Without doing an EAPv2 design, the best we can probably do is to design an extension to popular methods, with common parameter formats and AAA attribute definitions.) --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 17:04:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04436 for ; Mon, 1 Dec 2003 17:04:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 75184580017; Mon, 1 Dec 2003 16:05:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC413580027; Mon, 1 Dec 2003 16:05:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D50E8580027 for ; Mon, 1 Dec 2003 16:04:39 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id B4A4D580017 for ; Mon, 1 Dec 2003 16:04:37 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hB1M4ZvD022626; Tue, 2 Dec 2003 07:04:35 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hB1M4Z2j021265; Tue, 2 Dec 2003 07:04:35 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA21264 ; Tue, 2 Dec 2003 07:04:35 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA21360; Tue, 2 Dec 2003 07:04:34 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA14596; Tue, 2 Dec 2003 07:04:34 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hB1M4Xnb009655; Tue, 2 Dec 2003 07:04:33 +0900 (JST) Received: from steelhead ([159.119.168.89]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HP8004QYLBKXB@tsbpo1.po.toshiba.co.jp>; Tue, 2 Dec 2003 07:04:33 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AQw8q-0005Kx-00; Mon, 01 Dec 2003 14:03:40 -0800 From: Yoshihiro Ohba Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: <3FCBA6D5.7070708@piuha.net> To: Jari Arkko Cc: Michael Richardson , "eap@frascone.com" Message-id: <20031201220340.GB17311@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <11803.1070301021@marajade.sandelman.ottawa.on.ca> <3FCBA6D5.7070708@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 14:03:40 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) I am not sure what is agreed on. :) The particular attack Michael mentioned seems to hold even when Gamma AP advertises "gamma" instead of "delta". In that case: - Two authentication signaling paths are valid, i.e., one is: supplicant <-> gamma AP <-> AAA proxy <-> gamma's AAA server (= gamma's customer) the other is: supplicant <-> delta AP <-> AAA proxy <-> delta's AAA server (= gamma AP = delta's customer) - SSIDs advertised by APs are valid. (i.e., gamma AP advertises "gamma", delta AP advertises "delta".) - The data traffic path is still "valid", i.e., supplicant <-> gamma AP <-> delta AP <-> Internet (= gamma's customer) (= NAT router) It seems that actually no entity is doing anything wrong. Just that the Gamma Coffeeshop is smart enough to leverage the existing acocounting and billing schemes to increase its revenue. If the above observation is correct, I don't see any problem with this in terms of security. Yoshihiro Ohba On Mon, Dec 01, 2003 at 10:38:45PM +0200, Jari Arkko wrote: > Michael Richardson wrote: > > > Jari> Why? Perhaps I'm missing something obvious. But even if I > > Jari> authenticate Gamma to be Gamma in IEEE/EAP/AAA, and Gamma's > > router > > Jari> in SEND, Gamma can still NAT all my traffic and send it off to > > Jari> Delta. > > > > Jari> But perhaps you are thinking that the user will see "Gamma" on > > his > > Jari> screen and cry foul. I'm not very optimistic that most users > > would > > Jari> do this... Even you and I might have trouble understanding > > whether > > Jari> "Gamma Global Roaming WLAN" is a legal, another SSID on a > > Jari> virtualized "Delta" AP or a bad guy performing an attack. > > > > Of course. And his bill will say "Gamma". > > And if necessary, the customer can dispute it. > > > > But, the customer now has the tools to prevent this abuse. If they choose > >not to, well, fine. That's not our problem. > > Ok. I think we agree now. > > In terms of what to do about it: Bernard and Henrik have added > some words to the 2284bis document to describe the (general) > issue related to fraudulent claims of authenticators. They have > also added a requirement that method specs should say whether > or not they offer some protection for this. Can you take a look > if you like the text: > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20200 > > (Solution space: my gut feeling is that this is bigger than > individual methods or network selection, and needs to be handled > in a general fashion. Without doing an EAPv2 design, the best we > can probably do is to design an extension to popular methods, > with common parameter formats and AAA attribute definitions.) > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 17:14:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05306 for ; Mon, 1 Dec 2003 17:14:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 574D8580126; Mon, 1 Dec 2003 16:15:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EF4D5580027; Mon, 1 Dec 2003 16:15:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DA7F5580063 for ; Mon, 1 Dec 2003 16:14:11 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 364BE580017 for ; Mon, 1 Dec 2003 16:14:09 -0600 (CST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 61E2C6A901; Tue, 2 Dec 2003 00:14:08 +0200 (EET) Message-ID: <3FCBBC22.2030203@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: Michael Richardson , "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition References: <11803.1070301021@marajade.sandelman.ottawa.on.ca> <3FCBA6D5.7070708@piuha.net> <20031201220340.GB17311@steelhead> In-Reply-To: <20031201220340.GB17311@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 02 Dec 2003 00:09:38 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > - Two authentication signaling paths are valid, i.e., Yes. > > - SSIDs advertised by APs are valid. > (i.e., gamma AP advertises "gamma", delta AP advertises "delta".) Yes. But see below. > - The data traffic path is still "valid", i.e., Yes. > supplicant <-> gamma AP <-> delta AP <-> Internet > (= gamma's customer) (= NAT router) > > > It seems that actually no entity is doing anything wrong. > > Just that the Gamma Coffeeshop is smart enough to leverage the > existing acocounting and billing schemes to increase its revenue. Right. > If the above observation is correct, I don't see any problem with this > in terms of security. Michael started from a case where Gamma was advertising "Delta" instead. He argued that the protocols should be able to prevent such lies. I agreed. The rest is up to the user. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 17:24:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06403 for ; Mon, 1 Dec 2003 17:24:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1A8A5580017; Mon, 1 Dec 2003 16:25:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A695A580027; Mon, 1 Dec 2003 16:25:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 38C47580027 for ; Mon, 1 Dec 2003 16:24:37 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 73115580017 for ; Mon, 1 Dec 2003 16:24:35 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hB1MOYvD027984; Tue, 2 Dec 2003 07:24:34 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hB1MOYwc028612; Tue, 2 Dec 2003 07:24:34 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA28611 ; Tue, 2 Dec 2003 07:24:34 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA26446; Tue, 2 Dec 2003 07:24:33 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA07879; Tue, 2 Dec 2003 07:24:33 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hB1MOWnb013304; Tue, 2 Dec 2003 07:24:32 +0900 (JST) Received: from steelhead ([159.119.168.89]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HP80062AM8VWR@tsbpo1.po.toshiba.co.jp>; Tue, 2 Dec 2003 07:24:32 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AQwS7-0005OD-00; Mon, 01 Dec 2003 14:23:35 -0800 From: Yoshihiro Ohba Subject: Re: [eap] network discovery & selection: problem definition In-reply-to: <3FCBBC22.2030203@piuha.net> To: Jari Arkko Cc: Yoshihiro Ohba , Michael Richardson , "eap@frascone.com" Message-id: <20031201222330.GC17311@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <11803.1070301021@marajade.sandelman.ottawa.on.ca> <3FCBA6D5.7070708@piuha.net> <20031201220340.GB17311@steelhead> <3FCBBC22.2030203@piuha.net> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 01 Dec 2003 14:23:30 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, Dec 02, 2003 at 12:09:38AM +0200, Jari Arkko wrote: > > If the above observation is correct, I don't see any problem with this > > in terms of security. > > Michael started from a case where Gamma was advertising "Delta" > instead. He argued that the protocols should be able to prevent > such lies. I agreed. I agree that the lying NAS problem is a security issue in general. But what I'd like to mention is that the Gamma/Delta coffeshop example might not be an appropriate example for explaining the lyning NAS problem. Yoshihiro Ohba > > The rest is up to the user. > > --Jari > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 19:08:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13436 for ; Mon, 1 Dec 2003 19:07:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 19908580126; Mon, 1 Dec 2003 18:08:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 90CF7580027; Mon, 1 Dec 2003 18:08:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 07CE5580027 for ; Mon, 1 Dec 2003 18:07:52 -0600 (CST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 32726580017 for ; Mon, 1 Dec 2003 18:07:50 -0600 (CST) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hB208iD5020168 for ; Tue, 2 Dec 2003 00:08:44 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hB1NvAJ02872 for ; Mon, 1 Dec 2003 23:57:10 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003120116074308878 ; Mon, 01 Dec 2003 16:07:43 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Dec 2003 16:07:43 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BAC8@orsmsx410.jf.intel.com> Thread-Topic: network discovery & selection: problem definition Thread-Index: AcO10rKwKte6yHocQnGmxYzr6g7DfwCjmXCg From: "Adrangi, Farid" To: Cc: , "Pasi Eronen" X-OriginalArrivalTime: 02 Dec 2003 00:07:43.0698 (UTC) FILETIME=[4EF03320:01C3B868] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RE: network discovery & selection: problem definition Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Dec 2003 16:07:42 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Jari, Thanks again for starting this thread. Please see my replies to=20 your questions inline - Farooq and Pasi may add/subtract! BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, November 28, 2003 9:07 AM > To: eap@frascone.com; Adrangi, Farid; Pasi Eronen > Subject: network discovery & selection: problem definition >=20 >=20 >=20 > Folks, >=20 > In IETF-58 we discussed network discovery and selection=20 > issues, and the straw poll indicated that the WG wants to=20 > work on this. >=20 > I'd like initiate a discussion on the problem definition > for this work before actually adopting it as something that > the EAP WG intends to standardize. As a result of the=20 > discussion, we should know what the issue is, what functions=20 > are required, and what constraints should be placed on a=20 > potential solution. >=20 > Here is the plan for the discussion: >=20 > o All input should be received by December 15. The goal > is to have also a common understanding of the problem > by then. >=20 > o Lets keep the actual solution discussion separate. In > other words, lets not talk about the pros and cons of > different approaches, or where this functionality should > be placed in terms of the network or the protocol stack. >=20 > o The results of the discussion will be summarized by > the chairs. The need for documentation in the form > of a draft will be determined during the process. >=20 > o Next steps after this discussion has been concluded > include another discussion & possible drafts in the > solution space. At that time we also need to make > a decision whether the work should stay in the EAP WG > or be moved elsewhere. >=20 > The following is my first cut at the problem definition.=20 > Comments appreciated -- I'd be happy if you can shoot my=20 > definition down. I have included a few questions within the=20 > definition -- if you have answers I'm sure the group would=20 > like to hear them. >=20 > The primary network discovery and selection issue > is routing within the AAA infrastructure, giving > access to the user from the right home AAA and via > the right AAA proxies. Currently, we have the NAI [RFC2486]=20 > functionality. NAIs allow users to specify their domain so=20 > that the AAA requests can be routed to the right home AAA=20 > servers. However, this does not provide support for the following: >=20 > o Ability of the client to know which of his multiple > home networks are available from a given access? > Can I get to jari.arkko@ericsson.com, or only to > jarkko@piuha.net? >=20 Interesting! This is not within the scope of the problem defined=20 in our draft. But, I guess the Netowrk Information could help the=20 user decide Which identity/credential should be used in cases where multiple credenticals/identities are installed on the user's device.=20 > o Ability of the AAA requests to be routed correctly > where there is no complete, global AAA routing table. >=20 > Deployed AAA mechanisms use an essentially > statically configured local routing tables, > there is no e.g. link state routing protocols > for AAA. >=20 > Such local mechanisms are sufficient when there > limited amout of branching in the AAA network. > For instance, there is no need for a global > routing table if all your clients are either > locally authenticated or served by one other entity > (such as a global ISP, teleoperator, or a roaming > consortium). >=20 > However, if the access network supports two different > intermediaries, it becomes necessary to figure out > which intermediary handles the domain given in a NAI. >=20 > Question: what is the expected number of intermediaries > per one network hop? Can you cite current numbers from > existing networks, or projections of future network > topologies? >=20 Based on the discussions that we had in 3GPP meetings, it is within=20 a range of single digit for current deployments, but it could go up to 50 or so. > Question: Is it necessary to support multiple levels > of selection, e.g. go first to intermediary 1, then > to intermediary 2, etc? > 3GPP currently is concerned about support for one level Of intermediary. =20 > o For commercial reasons, intermediaries want > to participate the AAA transaction. >=20 > Question: Is there a need for someone else than > the access network to control the routing to go > via a special intermediary? This is not very > clear to me. >=20 The access network may not be aware of the user's preference. The user is paying the bill, so he should have the ability to influece routing of the AAA packets through a preferred intermediary to its home network if it is going to make a differnece in his billing. I belive 3GPP also has this as a requirement - Farooq can articualte further. BTW, this does not have to be done manually by the user - it can be done automatically based the policy installed on the user's device. > o For the purposes of choosing an intermediary > with specific properties, users may wish to > control network selection, or at least wish > to be aware of the results. For instance, > I can get to @ericsson.com either via piuha.net > or commercialoperator.net, but since I want to > go via piuha.net since it is free for me. >=20 > Question: what are the security requirements for > this? This is bordering on solution space, but as > far as I know, none of the proposed mechanisms > can support secure advertisements or secure > selection indications. Is this acceptable? As you mentioned in one your e-mails, we view this advertisement as=20 a hint (nothing more, nothing less). Note that SSIDs are also used as hints, and they can be spoofed as well. =20 >=20 > Question: what kind of information needs to be > presented in protocols vs. provisioned in the > clients vs. simply told to the user off-line? > It seems that it would be possible to provide > network name over protocols, but a standardized > format for offered CoS of QoS would probably > not be possible. >=20 We are prposing to provide network names over protocols (specifically, EAP protocol). Other information can be provisioned in clients=20 if needed. > An interesting twist in the AAA routing problem > is that all the above has to work for requests, responses, > as well as server-initiated messages. > Yes. So, tt is important for the server to know the AAA routing=20 information for a received request. This may depend on what=20 format/syntax is used for NAI decoration. =20 > The network discovery and selection problem is closely > related to the problem of access point discovery and > selection in wireless networks. The two problems coincide > when each access point offers exactly one network over > one AAA route. However, the network discovery and selection=20 > problem may exist even where there is just one access point=20 > to attach to, if it offers multiple networks or multiple=20 > routes to these networks. >=20 Yes. My two cents is that we should keep AP selection problems=20 separate from intermediary/mediating network selection. If you=20 come up with a single solution that sloves reasonably - that's great! otherwise, we will end up with two different solutions, one for each. > During the discussion of solutions for these problems, > it has become apparent that there are some additional=20 > constraints that may have to be placed on solutions. Some of=20 > the possible constraints are listed below: >=20 > o Solution can be adopted for the whole network > without requiring changes to the largest base > of installed devices -- access points and > clients. >=20 > o Allow interoperability with clients, access networks, > AAA proxies, and AAA servers that have not been > modified to support network discovery and selection. >=20 > o Works on all AAA protocols. >=20 > o Does not prevent the introduction of new AAA or > access network features, such as link-state AAA > routing protocols (pretty far fetched) or > fast handoffs. >=20 > o Does not consume a significant amount of > resources, such as bandwidth or network > attachment time. >=20 > o Does not cause a problem with limited packet > sizes of current protocols. > > Further discussion can be found from=20 > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network- discovery-and-selection-00.txt (including some solution space issues too). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 19:51:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14495 for ; Mon, 1 Dec 2003 19:50:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CBD4580126; Mon, 1 Dec 2003 18:51:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id BB8A1580027; Mon, 1 Dec 2003 18:51:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67716580027 for ; Mon, 1 Dec 2003 18:50:46 -0600 (CST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by mail.frascone.com (Postfix) with ESMTP id 9BD1D580017 for ; Mon, 1 Dec 2003 18:50:44 -0600 (CST) Received: from xparelay1.ptp.hp.com (xparelay1.ptp.hp.com [15.1.28.62]) by palrel11.hp.com (Postfix) with ESMTP id C22091C00224; Mon, 1 Dec 2003 16:50:43 -0800 (PST) Received: from xpabh1.ptp.hp.com (xpabh1.ptp.hp.com [15.1.28.60]) by xparelay1.ptp.hp.com (Postfix) with ESMTP id B66811004BBB; Mon, 1 Dec 2003 16:50:43 -0800 (PST) Received: by xpabh1.ptp.hp.com with Internet Mail Service (5.5.2655.55) id ; Mon, 1 Dec 2003 16:50:43 -0800 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Bernard Aboba'" , Nick Petroni Cc: eap@frascone.com, stds-802-1@ieee.org Subject: RE: [eap] Issue 204: Peer-to-peer operation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Dec 2003 16:50:41 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) In coming up to speed on this issue, I have a few comments and questions... Sorry for the length of this... In 802.1X, once the control port is opened, it is opened, so when a passthru authenticator receives an Access-Accept from the authentication server as the result of a successful authentication (be it mutual or not) it will open the port from its perspective. If it also has a supplicant configured, the port will remain closed until the supplicant is also successful. However, as part of the resolution of comment 15 in 802.1X-REV/D7.1 we added a local management variable that allows the device to override the supplicant's need to also authenticate and be satisfied with the authenticator's result. This would be used in passthru devices such as bridges and perhaps access points, but less likely in ad-hoc peers. From what I understand from this thread, the situation we are talking about is the case where both supplicant and authenticator are configured and enabled on the same port (i.e. they are both contributing to the opening of the controlled port), and the objective is to avoid running a 2nd authentication in the opposite direction when the 1st authentication, using a mutual method that delivers protected indications, actually succeeded. Since in 802.1X, the supplicant and authenticator machine are independent, it isn't clear how this 2nd authentication would be controlled or avoided. The management variable created as a result of Issue 15 is, perhaps, one approach. There may be others. I have a general question about how the above scenario will work and we should walk through the sets of state machines of both 802.1X and EAP to understand if it does. First question is when there is both an independent supplicant and authenticator configured at the 802.1X layer, is there also a corresponding independent EAP layer above each? I think the answer is yes. I believe the assumption from the 802.1X level is that a received EAP frame is delivered to both supplicant and authenticator in this case, and would thus be handed up to their respective EAP layers. The peer side would be ignoring responses and the authenticator side would be ignoring requests. I think this all works and I believe Jim Burns has walked these scenarios. To aid in my understanding, I'd like to toss out a taxonomy of configurations where both supplicant and authenticator are configured and enabled on a port. Sorry if this makes reading difficult, but perhaps it will help us understand how important this is (or is not). In each of the configurations, it is possible for any one side to complete the initial authentication as the supplicant and the other as the authenticator. The configurations, and possible examples as I see them are as follows: A. standalone to standalone - each side has its own authentication server component - For example, an ad-hoc 802.11 set of stations. B. standalone to passthru - one side is acting as a passthru, but the other is standalone. - passthru side has access to authentication server via another authorized port. - For example, a station connecting to an access point or bridge C. passthru to passthru, each with their own path to their authentication server - both sides can freely talk to their authentication servers via another authorized port - For example, two bridges talking to one another D. passthru to passthru with a single path to the authentication server - both sides need to talk to the authentication server, but one must reach it via the other's controlled port - For example, two bridges talking to one another, only a single authentication server In scenario A, since the EAP conversation is terminated locally, knowledge of the mutual nature of the authentication and receipt of the protected indications is well known on both sides. In this case, the side that acted as authenticator could effectively force its supplicant role to be authorized and the side that acted as supplicant could force its authenticator authorized. I understand, however, that we want the standalone and passthru models to work the same, so this is a bit of a hack. Scenario B is the typical case today where we don't configure both supplicant and authenticator, but rather have the station act as supplicant and the access point act as authenticator. Nonetheless, we must look at this scenario in two cases. The first case, where the passthru mode starts out as authenticator and the standalone as supplicant. In this case the passthru would likely take advantage of the new variable defined for 802.1X that opens the port regardless of what it's supplicant component is saying. It would still run the supplicant machine however, just not depend upon the result, so we would have two authentications taking place if the other side really wanted. The standalone side, however, would know it is satisfied and could force authorize its authenticator and thus not run the second authentication. In the second case, the passthru starts out as supplicant. Again, since the passthru would be satisfied as supplicant, it could force authorize its authenticator and not run the other machine. The standalone side would have to do the same thing based upon its knowledge of the successful mutual authentication. Scenario C would again have to take advantage of the new variable for the side that started out as authenticator and would then need to force authorize on the side that started out supplicant. We can always assume the supplicant has full knowledge of the mutual authentication and protected indications since it must terminate one side of the EAP conversation. The supplicant side can always force authorize its authenticator complement, but since the machines are independent, it is likely that the authenticator is already running and the 2nd authentication is already going on. If the new variable were not configured to ignore the supplicant result, the side that started out as authenticator would always need to run and complete its supplicant component. Scenario D is a strange special case that points out the need for the new variable we added as a result of comment 15. It is simply impossible to support this scenario unless there is the ability for the passthru NAS with the path to the authentication server to open its port regardless of the result of its supplicant component. If it didn't open its port the remote peer acting as authenticator could not talk to the authentication server and we are hung. Conclusion: ----------- The supplicant side or any standalone system always has full knowledge of the mutual nature of the authentication, so it could use this knowledge to disable the other half of the 802.1X component (or force it authorized) and cause only a single authentication exchange to take place. The passthru authenticator side can ignore the result of its supplicant side by using the new control variable, but it does not eliminate the second authentication unless the other side has decided not to initiate one. Paul > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] > On Behalf Of Bernard Aboba > Sent: Tuesday, November 25, 2003 7:27 PM > To: Nick Petroni > Cc: eap@frascone.com > Subject: Re: [eap] Issue 204: Peer-to-peer operation > > > > Do we agree there is no problem on the peer side? If so, > let's turn to > > the authenticator... > > Yes, I agree with this. Not sure about the IEEE 802.1aa > folks. Can anyone who was there fill us in? > > > It seems to me what you are saying is that even after receiving an > > Accept-Accept, the passthrough does not know it is allowed to have > > access even though it is allowed. > > Yes, the pass-through knows it will provide access to the > peer, but doesn't know whether the peer will accept the > access. Note that if the authenticator was not a > pass-through, then it would know, because it would have > received the result indication from the peer. > > > There are two possible solutions I see- > > 1. make Access-Accept mean that BOTH things are ok and that mutual > > auth is known to have succeeded or > > I don't think we can change the meaning of Access-Accept at > this point. > > > 2. make Access-Accept strictly mean the Peer is to be given access, > > and make some other AAA signal/message provide the other > information. > > This one could work. For example, we could add a "P2P > complete" attribute to tell the pass-through that the peer > has sent a successful result indication. > > > If mutual auth is required, the server can tie the auth directly to > > the EAP aaaEapSuccess signal. That is, both must be > authenticated for > > aaaEapSuccess to be true. This only works for case 1 above, > as the AAA > > layer can't separate these two if it is only given binary input. I > > believe THIS is the missing variable you describe? > > I think another variable is needed on the authenticator SM to > indicate that a result indication has been received from the peer. > > > I am really having trouble with the model for why the passthrough > > needs this information. when using a peer and a passthrough > > authenticator, it's tough for me to see the true peer-to-peer > > relationship we are describing in any real-world scenario. > > The scenario that IEEE 802.1af has been looking are bridges > talking to one another. I think that the IEEE 802.11 adhoc > scenario may also be affected. The way to think about this is > "can the two sides confirm that both controlled ports are > passing packets, so that another EAP authentication will not > have to be run in both directions". If the answer is no, > then you need to do another authentication, which is wasteful. > > > That being said, this does not mean we > > shouldn't handle the situation. My understanding of all passthrough > > implementations is that if there was to be mutual > authentication, but > > the peer failed to authenticate the authenticator the peer > will just > > go away (or try again) anyway. > > Yes. > > > Additionally, I understand the argument that we want > passthrough and > > standalone to have the same semantics, but I think even in the peer > > and standalone statemachines it is policy that is tying > together the > > two authentication decisions into a single signal. The > method should > > be set to only succeed in the case of mutual authentication > if mutual > > auth is required. > > I think there may be subtle distinction being made between > mutual auth (where the authenticator might not know whether > the peer is going to accept the access it granted), and > protected result indications, where the authenticator would > know the peer decision, absent the pass-through issues we > just talked about. > > > My current position is that I don't see why you need two > answers. If > > you know you are using a method with mutual authentication, > then you > > should be able to tie the outcome of that method to a two-way > > relationship. > > As mentioned above, I think it's about both sides being able > to confirm that they are willing to talk at L3, not just for > the authenticator to confirm its willingness to offer access > to the peer. _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 20:08:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14948 for ; Mon, 1 Dec 2003 20:08:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2C69F580126; Mon, 1 Dec 2003 19:09:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B4BC1580027; Mon, 1 Dec 2003 19:09:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D9AF580027 for ; Mon, 1 Dec 2003 19:08:37 -0600 (CST) Received: from atlrel6.hp.com (atlrel6.hp.com [156.153.255.205]) by mail.frascone.com (Postfix) with ESMTP id 6C445580017 for ; Mon, 1 Dec 2003 19:08:35 -0600 (CST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel6.hp.com (Postfix) with ESMTP id 081B91C00A94; Mon, 1 Dec 2003 20:08:35 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id E3E711C0130B; Mon, 1 Dec 2003 20:08:34 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2657.72) id ; Mon, 1 Dec 2003 20:08:34 -0500 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: stds-802-1@ieee.org, eap@frascone.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC 2284bis sections 2.3 and 2.4 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Dec 2003 20:08:26 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The EAP working group has asked 802.1 to review (in particular) two areas of the RFC 2284bis draft. I've included them below and this will aid in understanding the email just sent on EAP issue. The EAP issues can be reviewed at the following URL http://www.drizzle.com/~aboba/EAP/eapissues.html. Also, the entire draft RFC 2284bis can be extracted from http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-rfc2284bis-07.txt. Paul 2.3 Pass-through behavior When operating as a "pass-through authenticator", an authenticator performs checks on the Code, Identifier and Length fields as described in Section 4.1. It forwards EAP packets received from the peer and destined to its authenticator layer to the backend authentication server; packets received from the backend authentication server destined to the peer are forwarded to it. A host receiving an EAP packet may only do one of three things with it: act on it, drop it, or forward it. The forwarding decision is typically based only on examination of the Code, Identifier and Length fields. A pass-through authenticator implementation MUST be capable of forwarding to the backend authentication server EAP packets received from the peer with Code=2 (Response). It also MUST be capable of receiving EAP packets from the backend authentication server and forwarding EAP packets of Code=1 (Request), Code=3 (Success), and Code=4 (Failure) to the peer. Unless the authenticator implements one or more authentication methods locally which support the authenticator role, the EAP method layer header fields (Type, Type-Data) are not examined as part of the forwarding decision. Where the authenticator supports local authentication methods, it MAY examine the Type field to determine whether to act on the packet itself or forward it. Compliant pass-through authenticator implementations MUST by default forward EAP packets of any Type. EAP packets received with Code=1 (Request), Code=3 (Success), and Code=4 (Failure) are demultiplexed by the EAP layer and delivered to the peer layer. Therefore unless a host implements an EAP peer layer, these packets will be silently discarded. Similarly, EAP packets received with Code=2 (Response) are demultiplexed by the EAP layer and delivered to the authenticator layer. Therefore unless a host implements an EAP authenticator layer, these packets will be silently discarded. The behavior of a "pass-through peer" is undefined within this specification, and is unsupported by AAA protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP]. The forwarding model is illustrated in Figure 2. Peer Pass-through Authenticator Authentication Server +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | ^ | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP | | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! ! ! ! ! +-------->--------+ +--------->-------+ Figure 2: Pass-through Authenticator For sessions in which the authenticator acts as a pass-through, it MUST determine the outcome of the authentication solely based on the Accept/Reject indication sent by the backend authentication server; the outcome MUST NOT be determined by the contents of an EAP packet sent along with the Accept/Reject indication, or the absence of such an encapsulated EAP packet. 2.4 Peer-to-Peer Operation Since EAP is a peer-to-peer protocol, an independent and simultaneous authentication may take place in the reverse direction (depending on the capabilities of the lower layer). Both peers may act as authenticators and authenticatees at the same time, in which case it is necessary for both peers to implement EAP authenticator and peer layers. In addition, the EAP method implementations on both peers must support both authenticator and peer functionality. Although EAP supports peer-to-peer operation, some EAP implementations, methods, AAA protocols and link layers may not support this. Some EAP methods may support asymmetric authentication, with one type of credential being required for the peer and another type for the authenticator. Hosts supporting peer-to-peer operation with such a method would need to be provisioned with both types of credentials. For example, EAP-TLS [RFC2716] is a client-server protocol with a different certificate profile for the client and server. This implies that a host supporting peer-to-peer authentication with EAP-TLS would need to implement both the EAP peer and authenticator layers; support both peer and authenticator roles in the EAP-TLS implementation; and provision two distinct certificates, one appropriate for each role. AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-EAP] only support "passthrough authenticator" operation. As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-Request encapsulating an EAP-Request, Success or Failure packet with an Access-Reject. There is therefore no support for "passthrough peer" operation. Even where a method is used which supports mutual authentication and protected result indications, several considerations may dictate that two EAP authentications, (one in each direction) are required. These include: [1] Support for bi-directional session key derivation in the lower layer. Lower layers such as IEEE 802.11 may only support uni-directional derivation and transport of transient session keys. For example, the group-key handshake defined in [IEEE-802.11i] is uni-directional, since in IEEE 802.11 infrastructure mode only the Access Point (AP) sends multicast/ broadcast traffic. In IEEE 802.11 ad-hoc mode where either peer may send multicast/broadcast traffic, two uni-directional group-key exchanges are required. Due to limitations of the design, this also implies two unicast key derivations and EAP method exchanges. [2] Support for tie-breaking in the lower layer. Lower layers such as IEEE 802.11 adhoc do not support "tie breaking" wherein two hosts initiating authentication with each other will only go forward with a single authentication. This implies that even if 802.11 were to support a bi-directional group-key handshake, then two authentications, one in each direction, might still occur. [3] Peer policy satisfaction. EAP methods may support protected result indications, enabling the peer to indicate to the EAP server that it successfully authenticated the EAP server. However, a pass-through authenticator will not be aware that the peer has accepted the credentials offered by the EAP server, unless this information is provided to the authenticator via the AAA protocol. As a result, two authentications, one in each direction, may still be needed. It is also possible that the EAP peer's access policy was not satisfied during the EAP method exchange. For example, the authenticator may not have successfully authenticated to the peer, or may not have demonstrated authorization to act in both peer and server roles. For example, in EAP-TLS [RFC2716], the authenticator may have authenticated using a valid TLS server certificate, but not using a valid TLS client certificate. As a result, the peer may require an additional authentication in the reverse direction, even if the peer provided a protected result indication to the EAP server indicating that the server had successfully authenticated to it. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 1 22:09:06 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17933 for ; Mon, 1 Dec 2003 22:09:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A515C580017; Mon, 1 Dec 2003 21:09:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A22F1580027; Mon, 1 Dec 2003 21:09:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2296E580109 for ; Mon, 1 Dec 2003 21:08:23 -0600 (CST) Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by mail.frascone.com (Postfix) with ESMTP id 1F75A580027 for ; Mon, 1 Dec 2003 21:08:21 -0600 (CST) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.11.6/d: major-outer.mc,v 1.9 2003/11/03 20:24:21 root Exp $) with ESMTP id hB2395D5032475; Tue, 2 Dec 2003 03:09:06 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.jf.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id hB2325728827; Tue, 2 Dec 2003 03:02:05 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.1.32) with SMTP id M2003120119080404759 ; Mon, 01 Dec 2003 19:08:04 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 1 Dec 2003 19:08:04 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [eap] Re: network discovery & selection: problem definition Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BAC9@orsmsx410.jf.intel.com> Thread-Topic: [eap] Re: network discovery & selection: problem definition Thread-Index: AcO3WIz5fekrcMBCRgGXM7A2JtTKqQBFX9Hg From: "Adrangi, Farid" To: "Bernard Aboba" Cc: X-OriginalArrivalTime: 02 Dec 2003 03:08:04.0637 (UTC) FILETIME=[80B874D0:01C3B881] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Dec 2003 19:08:04 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Bernard, I have slightly different way of breaking down the problem=20 - maybe we are talking about the same thing and the differences is in wording it! As the name implies, the problem has two=20 aspects: discovery and selection so maybe it is easier to understand the problem by describing the purpose of each aspect. Purpose of Network Discovery: ---------------------------- 1) Discover 802.11 Access Networks within a coverage area. (Note, although our examples are 802.11, it is applicable to any access network). 2) Discover Mediating or Service Networks that a given=20 802.11 access network is affiliated with. (Note that POP=20 is only know to the Access Network, but mediating networks=20 are known to both Access Networks and home service network because of romaing agreements.) Purpose of Network Selection: ---------------------------- 1) Enable the WLAN client (manually or automatically) to select=20 the most appropriate 802.11 Access Network to associate with for a given "Network Identifier/credential" installed on the client's=20 device. 2) The home service network needs to enable a policy mechanism by which the WLAN client (manually or automatically) can influence the routing of AAA packets through the preferred Mediating Network to the WLAN client's home service network. =20 Note: IMO, "Identifier Selection" is an indenpent problem by itself. Best regards, Farid > -----Original Message----- > From: eap-admin@frascone.com [mailto:eap-admin@frascone.com]=20 > On Behalf Of Bernard Aboba > Sent: Sunday, November 30, 2003 8:00 AM > To: eap@frascone.com > Subject: [eap] Re: network discovery & selection: problem definition >=20 >=20 > I'd suggest that there are three somewhat orthogonal problems=20 > being discussed under the rubric of "network selection". >=20 > First, there is the problem of "Network discovery". This is=20 > the problem of discovering access networks available in the=20 > vicinity, and the points of presence (POPs) associated with=20 > those networks. >=20 > Second, there is the problem of "Identifier selection". This=20 > is the problem of selecting which identity (and credentials)=20 > to use to authenticate to a given POP. >=20 > Thirdly, there is the problem of "Access routing" which=20 > involves figuring out how to route the authentication=20 > conversation originating from the selected identity back to=20 > the home realm. >=20 > Network Discovery > ----------------- > Traditionally, the problem of discovering available networks=20 > has been handled out-of-band of EAP. >=20 > RFC 2194 describes the pre-provisioning of dialup roaming=20 > clients, which typically included a list of potential phone=20 > numbers, updated by the > provider(s) with which the client had a contractual=20 > relationship. RFC 3017 describes the IETF Proposed Standard=20 > for the Roaming Access XML DTD. This covers not only the=20 > attributes of the Points of Presence (POPs) and Internet=20 > Service Providers (ISPs), but also hints on the appropriate=20 > NAI to be used with a particular POP. >=20 > In IEEE 802.11 WLANs, the Beacon/Probe Request/Response=20 > mechanism provides a way for Stations to discover Access=20 > Points (APs), as well as the capabilities of those APs. =20 > Among the Information Elements (IEs) included within the=20 > Beacon and Probe Response is the SSID, a non-unique=20 > identifier of the network to which an Access Point is=20 > attached. By combining network identification along with=20 > capabilities discovery, the Beacon/Probe facility provides=20 > the information required for both network discovery and=20 > roaming decisions within a single mechanism. >=20 > As noted in [Velayos], the Beacon mechanism does not scale=20 > well; with a Beacon interval of 100ms, and 10 APs in the=20 > vicinity, approximately 32 percent of an 802.11b AP's=20 > capacity is used for beacon transmission. In addition, since=20 > Beacon/Probe Response frames are sent by each AP over the=20 > wireless medium, stations can only discover APs within=20 > range, which implies substantial coverage overlap for roaming=20 > to occur without interruption. >=20 > A number of enhancements have been proposed to the=20 > Beacon/Probe Response mechanism in order to improve=20 > scalability and roaming performance. These include allowing=20 > APs to announce capabilities of neighbor APs as well as their=20 > own, as proposed in IEEE 802.11k; propagation of discovery=20 > information over IP, as handled in the CARD protocol=20 > developed within the IETF SEAMOBY WG, etc. >=20 > Typically scalability enhancement mechanisms attempt to get=20 > around Beacon/Probe Response restrictions by sending=20 > advertisements at the higher rates which are enabled one the=20 > station has associated with an AP. Since these mechanisms=20 > run over IP, they can utilize IP facilities such as=20 > fragmentation, which the Beacon/Probe Response mechanism cannot. >=20 > Identity selection > ------------------ > As networks proliferate, it becomes more and more likely that=20 > a given EAP peer may have multiple identities and credential=20 > sets, available for use in different situations. For=20 > example, the EAP peer may have an account with one or more=20 > Public WLAN providers; a corporate WLAN; one or more=20 > wireless WAN providers. As a result, the EAP peer has to=20 > decide which credential set to use when presented with a=20 > given set of potential EAP authenticators. >=20 > Traditionally, hints useful in identity selection have also=20 > been provided out-of-band. For example, via the IETF=20 > Proposed Standard Roaming Access XML DTD, a client can select=20 > between potential POPs, and then based on information=20 > provided in the DTD, determine the appropriate NAI to use=20 > with the selected POP. >=20 > However, it is also possible for hints to be embedded within=20 > credentials. In [Housley], usage hints are provided within=20 > certificates used for wireless authentication. This involves=20 > extending the certificate to include the SSIDs with which the=20 > certificate can be used. >=20 >=20 > Access routing > -------------- > Once the identity has been selected, it is necessary for the=20 > authentication conversation to be routed back to the home=20 > realm. Within the IETF ROAMOPS WG, a number of approaches=20 > were considered for this, including source routing techniques=20 > based on the NAI [RFC2486], and techniques relying on the AAA=20 > infrastructure. Given the relative simplicity of the roaming=20 > implementations described in RFC 2194, static routing=20 > mechanisms appeared adequate for the task and it was not=20 > deemed necessary to develop dynamic routing protocols. >=20 > As noted in RFC 2607, RADIUS proxies are deployed not only=20 > for routing purposes, but also to mask a number of=20 > inadequacies in the RADIUS protocol design, such as the lack=20 > of standarized retransmission behavior and the need for=20 > shared secret provisioning. >=20 > By removing many of the protocol inadequacies, introducing=20 > new AAA agent types such as Redirects, providing support for=20 > certificate-based authentication as well as inter and=20 > intra-domain service discovery, Diameter allows a NAS to=20 > directly open a Diameter connection to the home realm without=20 > having to utilize a network of proxies. >=20 > This is somewhat analagous to the evolution of email=20 > delivery. Prior to the widespread proliferation of the=20 > Internet, it was necessary to gateway between SMTP-based mail=20 > systems and alternative delivery technologies, such as UUCP=20 > and FidoNet, and email-address based source-routing was used=20 > to handle this. However, as mail could increasingly be=20 > delivered directly, the use of source routing disappeared. >=20 > As with the selection of certificates by stations, a Diameter=20 > client wishing to authenticate with a Diameter server may=20 > have a choice of available certificates, and therefore it may=20 > need to choose between them. >=20 > References > ---------- >=20 > [Housley] Housley, R., and T. Moore, "Certificate Extensions=20 > and Attributes Supporting Authentication in PPP and Wireless=20 > LAN", draft-ietf-pkix-wlan-extns-04.txt, > Internet Draft (work in progress), June 2003. >=20 > [Mishra] Mishra, A., Shin, M. and W. Arbaugh, "An empirical=20 > analysis of the IEEE 802.11 MAC layer handoff process",=20 > University of Maryland Technical Report, UMIACS-TR-2002-75, 2002. >=20 > [Velayos] Velayos, H. and G. Karlsson, "Techniques to Reduce=20 > IEEE 802.11b MAC Layer Handover Time", Laboratory for=20 > Communication Networks, KTH, Royal Institute of Technology,=20 > Stockholm, Sweden, TRITA-IMIT-LCN R 03:02 >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 00:52:56 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21404 for ; Tue, 2 Dec 2003 00:52:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B55ED580126; Mon, 1 Dec 2003 23:53:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87CA6580063; Mon, 1 Dec 2003 23:53:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C1E9580063 for ; Mon, 1 Dec 2003 23:52:45 -0600 (CST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id AAB0C580027 for ; Mon, 1 Dec 2003 23:52:43 -0600 (CST) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Dec 2003 21:55:33 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB25qeAt026270; Mon, 1 Dec 2003 21:52:40 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.114.100]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 1 Dec 2003 21:57:54 -0800 From: "Joseph Salowey" To: "'Nick Petroni'" Cc: Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <008c01c3b898$7ee34830$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 02 Dec 2003 05:57:54.0691 (UTC) FILETIME=[3A774D30:01C3B899] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 1 Dec 2003 21:52:39 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Nick, Comments inline below: > -----Original Message----- > From: Nick Petroni [mailto:npetroni@cs.umd.edu] > Sent: Wednesday, November 26, 2003 11:01 AM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine > > > 3. Interface to method > > > > The interface to the method seems too complicated. > > > > First I don't think that intCheck should be a different process. > > Integrity checking is done as part of the method processing. Also > > methods aren't required to ingore packets, some methods with ignore > > some problems and return errors on others. I think this behavior > > should be incorporated into m.process. > [npetroni] intCheck is needed because SOMETIMES a method will > decide not to use the packet at all. in this case, intCheck > is the way the method tells the SM it will not be using that > packet. Methods with other ways of dealing with this will > just not set intCheck to be true. [Joe] Int check should be internal to the method. It should be possible for the method to signal that a packet should be ignored. I think breaking it out like this is misleading. > > > On a separate but related note it seems that the method state and > > decision is very complex. I don't really see the need for the > > independent methodState and decision variables. M.process() should > > return one of serverl possible results: IGNORE, CONTINUE, > > COND_SUCCESS, SUCCESS, FAILURE. MethodState should be able > to take on > > CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. I don't think a separate > > decision variable is necessary. > [npetroni] This is meant to show that a method really has its > own state machine and that these states are separate from the > final decision. I think it provides nice way of separating > the two, but I am willing to discuss this alternative notation. > [Joe] I agree that a method has its own state machine, however I think exposing it here creates some problems. First it complicates the EAP state machine and second the internal state machine of the method will vary from method to method. I think it would be best to make the method opaque as possible and use the minimal interface between method and EAP state machines. > > > > 4. Idle timer > > > > It seems that there is a problem with the idle timer. It would be > > possible for the peer to never time out if it keeps on receiving > > packets that it discards. This is not so good. > [npetroni] hmm, that seems like a trivial DoS, no? Send > enough bad packets to the Peer and it goes away for a while? > > > 5. rxSuccess and rxFailure > > > > Shouldn't rxSuccess and rxFailure check to see if (reqId == > > lastReqID)? > [npetroni] probably so. I think this should be added. > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 05:33:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10994 for ; Tue, 2 Dec 2003 05:32:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CF46E580027; Tue, 2 Dec 2003 04:33:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 16C87580063; Tue, 2 Dec 2003 04:33:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 993FC580063 for ; Tue, 2 Dec 2003 04:32:48 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id D9BFC580027 for ; Tue, 2 Dec 2003 04:32:46 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hB2AWT4u023631; Tue, 2 Dec 2003 05:32:29 -0500 (EST) From: Nick Petroni To: Joseph Salowey Cc: Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine In-Reply-To: <008c01c3b898$7ee34830$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Dec 2003 05:32:29 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thanks for the comments Joe. I have some comments as well. > [Joe] Int check should be internal to the method. It should be possible intCheck IS set by an internal method, m.integrityCheck(). > for the method to signal that a packet should be ignored. I think > breaking it out like this is misleading. [npetroni] I would say it IS possible for the method to signal that a packet should be ignored just by setting intCheck. Perhaps it's the name you just don't like? I don't see how this is any different from how it works now. > > [npetroni] This is meant to show that a method really has its > > own state machine and that these states are separate from the > > final decision. I think it provides nice way of separating > > the two, but I am willing to discuss this alternative notation. > > > [Joe] I agree that a method has its own state machine, however I think > exposing it here creates some problems. First it complicates the EAP [npetroni] This is not exposing the ACTUAL method state machine (IMHO), just a minimal set of signals that need to be exported. There could be more. > state machine and second the internal state machine of the method will > vary from method to method. I think it would be best to make the method > opaque as possible and use the minimal interface between method and EAP > state machines. [npetroni] Perhaps the notation is confusing to some, I don't think it is overly complex. Author's bias perhaps? I am open to changing it, but I guess I still don't understand the argument completely. I would love to get additional input- any consensus from the group would be great. > > > 4. Idle timer > > > > > > It seems that there is a problem with the idle timer. It would be > > > possible for the peer to never time out if it keeps on receiving > > > packets that it discards. This is not so good. > > [npetroni] hmm, that seems like a trivial DoS, no? Send > > enough bad packets to the Peer and it goes away for a while? [npetroni] I guess I am responding to my own comment here, but I went back and read your original thoughts on this and I think I see your point now. I misread where you thought the timer should be set. I think there could be a good argument for moving the idleWhile setting to INITIALIZE and SEND_RESPONE. I don't think it should be in METHOD just for abstraction. Besides, you would have to do it conditionally in METHOD anyway. Are there other opinions on this? The problem comes down to bad packets resetting the client timeout such that the peer can still go ClientTimeout without receiving a good packet and yet not timeout. I guess the question is does the timeout go between GOOD packets or just packets? I see no reason why this is explicitly a peer problem. Wouldn't the authenticator work the same? Thanks for the feedback- anything that helps make the document more understandable (and more correct :) ) is a good thing. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 11:54:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26775 for ; Tue, 2 Dec 2003 11:53:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CB701580127; Tue, 2 Dec 2003 10:54:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 44E5F580063; Tue, 2 Dec 2003 10:54:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 64428580063 for ; Tue, 2 Dec 2003 10:53:20 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 84571580027 for ; Tue, 2 Dec 2003 10:53:18 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hB2GpnvD015989; Wed, 3 Dec 2003 01:51:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hB2GpnDW016039; Wed, 3 Dec 2003 01:51:49 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA16035 ; Wed, 3 Dec 2003 01:51:49 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA24505; Wed, 3 Dec 2003 01:51:48 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA28138; Wed, 3 Dec 2003 01:51:48 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hB2GplCP006781; Wed, 3 Dec 2003 01:51:47 +0900 (JST) Received: from steelhead ([159.119.168.110]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HPA00B681I99H@tsbpo1.po.toshiba.co.jp>; Wed, 3 Dec 2003 01:51:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1ARDiQ-0006gh-00; Tue, 02 Dec 2003 08:49:34 -0800 From: Yoshihiro Ohba Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine In-reply-to: To: Nick Petroni Cc: Joseph Salowey , eap@frascone.com Message-id: <20031202164934.GA23444@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <008c01c3b898$7ee34830$0200000a@amer.cisco.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 02 Dec 2003 08:49:34 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, Dec 02, 2003 at 05:32:29AM -0500, Nick Petroni wrote: > Thanks for the comments Joe. I have some comments as well. > > > [Joe] Int check should be internal to the method. It should be possible > intCheck IS set by an internal method, m.integrityCheck(). > > > for the method to signal that a packet should be ignored. I think > > breaking it out like this is misleading. > [npetroni] I would say it IS possible for the method to signal that a > packet should be ignored just by setting intCheck. Perhaps it's the name > you just don't like? I don't see how this is any different from how it > works now. > > > > [npetroni] This is meant to show that a method really has its > > > own state machine and that these states are separate from the > > > final decision. I think it provides nice way of separating > > > the two, but I am willing to discuss this alternative notation. > > > > > [Joe] I agree that a method has its own state machine, however I think > > exposing it here creates some problems. First it complicates the EAP > [npetroni] This is not exposing the ACTUAL method state machine (IMHO), > just a minimal set of signals that need to be exported. There could be > more. > > > state machine and second the internal state machine of the method will > > vary from method to method. I think it would be best to make the method > > opaque as possible and use the minimal interface between method and EAP > > state machines. > [npetroni] Perhaps the notation is confusing to some, I don't think it is > overly complex. Author's bias perhaps? I am open to changing it, but I > guess I still don't understand the argument completely. I would love to > get additional input- any consensus from the group would be great. I agree with Joe that from implementation point of view, it is better to reduce the number of variables needed for the interface between method and EAP state machines. On the other hand, the other role of the EAP state machines document is to help implementers understand how RFC2284bis works. I think describing the peer state machine by using the two variables (i.e., methodState and decision) helps us understand Implementation Note in Section 4.2 of RFC2284bis pretty well. So, I would suggest keeping the currnet state machine as it is (i.e., use methodState and decision variables), but adding the following statement in "Implementation Consideration" section: "In the peer state machine, implementations may integrate methodState and decision variables into a single variable that may be obtained as a return value of m.process() method procedure." > > > > > > 4. Idle timer > > > > > > > > It seems that there is a problem with the idle timer. It would be > > > > possible for the peer to never time out if it keeps on receiving > > > > packets that it discards. This is not so good. > > > [npetroni] hmm, that seems like a trivial DoS, no? Send > > > enough bad packets to the Peer and it goes away for a while? > [npetroni] I guess I am responding to my own comment here, but I went back > and read your original thoughts on this and I think I see your point now. > I misread where you thought the timer should be set. I think there could > be a good argument for moving the idleWhile setting to INITIALIZE and > SEND_RESPONE. I don't think it should be in METHOD just for abstraction. > Besides, you would have to do it conditionally in METHOD anyway. Are > there other opinions on this? The problem comes down to bad packets > resetting the client timeout such that the peer can still go > ClientTimeout without receiving a good packet and yet not timeout. I > guess the question is does the timeout go between GOOD packets or just > packets? I see no reason why this is explicitly a peer problem. Wouldn't > the authenticator work the same? I agree that in both peer and authenticator state machines it is not good to reset the timer value when the received message is discarded. On the other hand, the peer idle timer should be set only once in INITIALIZE state and should not be reset anywhere else. This is because (correct me if I am wrong) the idle timer for authenticator and the idle timer for peer are used for different purposes. The former timer is message retranmission timer and the latter timer is authentication session timeout timer. Yoshihiro Ohba > > Thanks for the feedback- anything that helps make the document more > understandable (and more correct :) ) is a good thing. > > Regards, > nick > > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 12:10:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27989 for ; Tue, 2 Dec 2003 12:10:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 58CF9580128; Tue, 2 Dec 2003 11:10:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D4E18580063; Tue, 2 Dec 2003 11:10:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DF17D580063 for ; Tue, 2 Dec 2003 11:09:06 -0600 (CST) Received: from redmailwall2.attws.com (redmailwall2.attws.com [198.180.219.46]) by mail.frascone.com (Postfix) with ESMTP id F2521580027 for ; Tue, 2 Dec 2003 11:09:04 -0600 (CST) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.12.10/8.12.6) with ESMTP id hB2H93Ax009387; Tue, 2 Dec 2003 09:09:04 -0800 (PST) Received: from nwestmail.entp.attws.com by viruswall1.entp.attws.com (8.11.7p1+Sun/AT&T Wireless Services, Inc.) id hB2H92b01309; Tue, 2 Dec 2003 09:09:02 -0800 (PST) Received: from WA-MSGBH01-BTH.wireless.attws.com (WA-MSGBH01-BTH.wireless.attws.com [135.214.26.241]) by nwestmail.entp.attws.com (8.8.8p2+Sun/8.8.8) with ESMTP id JAA15878; Tue, 2 Dec 2003 09:09:02 -0800 (PST) Received: from WA-MSG10-BTH.wireless.attws.com ([135.214.41.74]) by WA-MSGBH01-BTH.wireless.attws.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 2 Dec 2003 09:09:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] RE: network discovery & selection: problem definition Message-ID: Thread-Topic: [eap] RE: network discovery & selection: problem definition Thread-Index: AcO10rKwKte6yHocQnGmxYzr6g7DfwCjmXCgACPyVzA= From: "Bari, Farooq" To: "Adrangi, Farid" , Cc: , "Pasi Eronen" X-OriginalArrivalTime: 02 Dec 2003 17:09:02.0528 (UTC) FILETIME=[FBF79C00:01C3B8F6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Dec 2003 09:09:02 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Pls see my comments below -----Original Message----- From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] On Behalf Of Adrangi, Farid Sent: Monday, December 01, 2003 4:08 PM To: jari.arkko@piuha.net Cc: eap@frascone.com; Pasi Eronen Subject: [eap] RE: network discovery & selection: problem definition Hi Jari, Thanks again for starting this thread. Please see my replies to=20 your questions inline - Farooq and Pasi may add/subtract! BR, Farid > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Friday, November 28, 2003 9:07 AM > To: eap@frascone.com; Adrangi, Farid; Pasi Eronen > Subject: network discovery & selection: problem definition >=20 >=20 >=20 > Folks, >=20 > In IETF-58 we discussed network discovery and selection > issues, and the straw poll indicated that the WG wants to=20 > work on this. >=20 > I'd like initiate a discussion on the problem definition > for this work before actually adopting it as something that the EAP WG > intends to standardize. As a result of the discussion, we should know=20 > what the issue is, what functions are required, and what constraints=20 > should be placed on a potential solution. >=20 > Here is the plan for the discussion: >=20 > o All input should be received by December 15. The goal > is to have also a common understanding of the problem > by then. >=20 > o Lets keep the actual solution discussion separate. In > other words, lets not talk about the pros and cons of > different approaches, or where this functionality should > be placed in terms of the network or the protocol stack. >=20 > o The results of the discussion will be summarized by > the chairs. The need for documentation in the form > of a draft will be determined during the process. >=20 > o Next steps after this discussion has been concluded > include another discussion & possible drafts in the > solution space. At that time we also need to make > a decision whether the work should stay in the EAP WG > or be moved elsewhere. >=20 > The following is my first cut at the problem definition. > Comments appreciated -- I'd be happy if you can shoot my=20 > definition down. I have included a few questions within the=20 > definition -- if you have answers I'm sure the group would=20 > like to hear them. >=20 > The primary network discovery and selection issue > is routing within the AAA infrastructure, giving > access to the user from the right home AAA and via > the right AAA proxies. Currently, we have the NAI [RFC2486] > functionality. NAIs allow users to specify their domain so=20 > that the AAA requests can be routed to the right home AAA=20 > servers. However, this does not provide support for the following: >=20 > o Ability of the client to know which of his multiple > home networks are available from a given access? > Can I get to jari.arkko@ericsson.com, or only to > jarkko@piuha.net? >=20 Interesting! This is not within the scope of the problem defined=20 in our draft. But, I guess the Netowrk Information could help the=20 user decide Which identity/credential should be used in cases where multiple credenticals/identities are installed on the user's device.=20 [FB] My understanding of the problem space we are trying to solve is that the authentication/authorization is for a particular service that the user has subscribed to (and not for the user in general who may have subscription to several services with different identities and credentials). For a particular service, the user will have only one credentials and only one home network. So multiple user credentials with multiple home networks is out of scope of the problem space that we are trying to address[FB] =20 > o Ability of the AAA requests to be routed correctly > where there is no complete, global AAA routing table. >=20 > Deployed AAA mechanisms use an essentially > statically configured local routing tables, > there is no e.g. link state routing protocols > for AAA. >=20 > Such local mechanisms are sufficient when there > limited amout of branching in the AAA network. > For instance, there is no need for a global > routing table if all your clients are either > locally authenticated or served by one other entity > (such as a global ISP, teleoperator, or a roaming > consortium). >=20 > However, if the access network supports two different > intermediaries, it becomes necessary to figure out > which intermediary handles the domain given in a NAI. >=20 > Question: what is the expected number of intermediaries > per one network hop? Can you cite current numbers from > existing networks, or projections of future network > topologies? >=20 Based on the discussions that we had in 3GPP meetings, it is within=20 a range of single digit for current deployments, but it could go up to 50 or so. [FB] The number of intermediaries / roaming partners can be significantly high (e.g. roaming agreements of GSMA operators can be in hundreds). I would not say more than that here as we are discussing problem space and not a solution as to how to advertise them. [FB] > Question: Is it necessary to support multiple levels > of selection, e.g. go first to intermediary 1, then > to intermediary 2, etc? > 3GPP currently is concerned about support for one level Of intermediary. [FB] Agree with Farid - 3GPP has considered one level of intermediary where the intermediary has business (roaming) agreements with both the WLAN ISP and the home network. [FB] > o For commercial reasons, intermediaries want > to participate the AAA transaction. >=20 > Question: Is there a need for someone else than > the access network to control the routing to go > via a special intermediary? This is not very > clear to me. >=20 The access network may not be aware of the user's preference. The user is paying the bill, so he should have the ability to influece routing of the AAA packets through a preferred intermediary to its home network if it is going to make a differnece in his billing. I belive 3GPP also has this as a requirement - Farooq can articualte further. BTW, this does not have to be done manually by the user - it can be done automatically based the policy installed on the user's device. [FB] In the end it is the user who has to pay the bill based on his agreement with the home operator. Since the intermediary network choice effects the amount the user/operator has to pay to its roaming partner (i.e. intermediary), the choice of intermediary really should rest with the user and the home operator. The access network will not have information on roaming partners of the home operator and also can not be expected to make such decisions as it will have conflict of interest to increase its revenue by trying to sell a more expensive AAA path where it makes more money (i.e. the home operator pays more). [FB] > o For the purposes of choosing an intermediary > with specific properties, users may wish to > control network selection, or at least wish > to be aware of the results. For instance, > I can get to @ericsson.com either via piuha.net > or commercialoperator.net, but since I want to > go via piuha.net since it is free for me. >=20 > Question: what are the security requirements for > this? This is bordering on solution space, but as > far as I know, none of the proposed mechanisms > can support secure advertisements or secure > selection indications. Is this acceptable? As you mentioned in one your e-mails, we view this advertisement as=20 a hint (nothing more, nothing less). Note that SSIDs are also used as hints, and they can be spoofed as well. =20 [FB] Agree with Farid here. The user (or the device that he is using) is part of the decision making process. The process can be either automatic or manual. Also advertisement is only a hint that should be available to any devices that is try to have access to the network. The actual user authentication for a service happens after the advertisement and this is where we need to have security (and that is not part of this draft)[FB] >=20 > Question: what kind of information needs to be > presented in protocols vs. provisioned in the > clients vs. simply told to the user off-line? > It seems that it would be possible to provide > network name over protocols, but a standardized > format for offered CoS of QoS would probably > not be possible. >=20 We are prposing to provide network names over protocols (specifically, EAP protocol). Other information can be provisioned in clients=20 if needed. [FB] Agree with Farid - the scope of this draft is specifically on roaming partner information. It can not be provisioned since it will only be needed when WLAN ISP does not have any roaming agreement with the user home operator (so WLAN user device will not be able to know it upfront). The user expectation will be to have this process automated and not having to find a piece of advertisements or being informed offline of a long list of WLAN ISPs roaming partners and then having to compare it with a long list of his home operator's roaming partners and then having to find the best match for roaming intermediary [FB] > An interesting twist in the AAA routing problem > is that all the above has to work for requests, responses, > as well as server-initiated messages. > Yes. So, tt is important for the server to know the AAA routing=20 information for a received request. This may depend on what=20 format/syntax is used for NAI decoration. =20 > The network discovery and selection problem is closely related to the=20 > problem of access point discovery and selection in wireless networks.=20 > The two problems coincide when each access point offers exactly one=20 > network over one AAA route. However, the network discovery and=20 > selection problem may exist even where there is just one access point > to attach to, if it offers multiple networks or multiple=20 > routes to these networks. >=20 Yes. My two cents is that we should keep AP selection problems=20 separate from intermediary/mediating network selection. If you=20 come up with a single solution that sloves reasonably - that's great! otherwise, we will end up with two different solutions, one for each. [FB] Agree with Farid [FB] > During the discussion of solutions for these problems, > it has become apparent that there are some additional > constraints that may have to be placed on solutions. Some of=20 > the possible constraints are listed below: >=20 > o Solution can be adopted for the whole network > without requiring changes to the largest base > of installed devices -- access points and > clients. >=20 > o Allow interoperability with clients, access networks, > AAA proxies, and AAA servers that have not been > modified to support network discovery and selection. >=20 > o Works on all AAA protocols. >=20 > o Does not prevent the introduction of new AAA or > access network features, such as link-state AAA > routing protocols (pretty far fetched) or > fast handoffs. >=20 > o Does not consume a significant amount of > resources, such as bandwidth or network > attachment time. >=20 > o Does not cause a problem with limited packet > sizes of current protocols. > > Further discussion can be found from > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network- discovery-and-selection-00.txt (including some solution space issues too). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 12:14:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28244 for ; Tue, 2 Dec 2003 12:13:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D492E580027; Tue, 2 Dec 2003 11:14:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7AC76580063; Tue, 2 Dec 2003 11:14:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DFE46580063 for ; Tue, 2 Dec 2003 11:13:59 -0600 (CST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id 0E4E0580027 for ; Tue, 2 Dec 2003 11:13:58 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB2HDsAt004771; Tue, 2 Dec 2003 09:13:55 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.114.100]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 09:19:09 -0800 From: "Joseph Salowey" To: "'Nick Petroni'" Cc: Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <00a101c3b8f7$a9ec3b90$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 02 Dec 2003 17:19:09.0339 (UTC) FILETIME=[65A79EB0:01C3B8F8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Dec 2003 09:13:53 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Nick Petroni [mailto:npetroni@cs.umd.edu] > Sent: Tuesday, December 02, 2003 2:32 AM > To: Joseph Salowey > Cc: eap@frascone.com > Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine > > > Thanks for the comments Joe. I have some comments as well. > > > [Joe] Int check should be internal to the method. It should be > > possible > intCheck IS set by an internal method, m.integrityCheck(). > > > for the method to signal that a packet should be ignored. I think > > breaking it out like this is misleading. > [npetroni] I would say it IS possible for the method to > signal that a packet should be ignored just by setting > intCheck. Perhaps it's the name you just don't like? I don't > see how this is any different from how it works now. > > > > [npetroni] This is meant to show that a method really has its own > > > state machine and that these states are separate from the final > > > decision. I think it provides nice way of separating the > two, but I > > > am willing to discuss this alternative notation. > > > > > [Joe] I agree that a method has its own state machine, > however I think > > exposing it here creates some problems. First it > complicates the EAP > [npetroni] This is not exposing the ACTUAL method state > machine (IMHO), just a minimal set of signals that need to be > exported. There could be more. > [Joe] I guess what I am really compaining about is that there seems to be an overabundance of signals, some of which seem to be internal to the method. I would like to see the minimal set of signals used between the method and the EAP state machine. Perhaps we already have the minimal set of signals, but there seems to be a lot (1 boolean and two tri-states). I think this can be simplified to 4 different signals from the method, IGNORE, COND_SUCCESS, SUCCESS, FAILURE. However the machine is sufficiently complex that I could be missing something. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 13:21:56 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00659 for ; Tue, 2 Dec 2003 13:21:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D87BA580063; Tue, 2 Dec 2003 12:22:07 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89DD9580109; Tue, 2 Dec 2003 12:22:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E89C6580109 for ; Tue, 2 Dec 2003 12:21:27 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 48E05580063 for ; Tue, 2 Dec 2003 12:21:26 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hB2IKO4u003902; Tue, 2 Dec 2003 13:20:24 -0500 (EST) From: Nick Petroni To: Joseph Salowey Cc: Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine In-Reply-To: <00a101c3b8f7$a9ec3b90$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Dec 2003 13:20:24 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > [Joe] I guess what I am really compaining about is that there seems to > be an overabundance of signals, some of which seem to be internal to the > method. I would like to see the minimal set of signals used between the > method and the EAP state machine. Perhaps we already have the minimal > set of signals, but there seems to be a lot (1 boolean and two > tri-states). I think this can be simplified to 4 different signals from > the method, IGNORE, COND_SUCCESS, SUCCESS, FAILURE. However the > machine is sufficiently complex that I could be missing something. No, you understand it perfectly. I guess the difference in opinion is whether or not there is any value in showing more detail. I think the first question would be if there is such value (and I believe Yoshihiro's point was that there may be). The second question is whether the current representation provides both the appropriate level of extra information and the accuracy of that information. It could very well be that the best state machine has the least amount of variables and just more text describing what might happen in a method. nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 13:55:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01861 for ; Tue, 2 Dec 2003 13:54:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D3AB580027; Tue, 2 Dec 2003 12:55:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3D0B580063; Tue, 2 Dec 2003 12:55:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 18BC0580063 for ; Tue, 2 Dec 2003 12:54:29 -0600 (CST) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mail.frascone.com (Postfix) with ESMTP id E31C5580027 for ; Tue, 2 Dec 2003 12:54:26 -0600 (CST) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB2IsNw5003111; Tue, 2 Dec 2003 10:54:24 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.114.100]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 10:59:37 -0800 From: "Joseph Salowey" To: "'Yoshihiro Ohba'" , "'Nick Petroni'" Cc: Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <00b401c3b905$b2f48450$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <20031202164934.GA23444@steelhead> Importance: Normal X-OriginalArrivalTime: 02 Dec 2003 18:59:37.0433 (UTC) FILETIME=[6EADC490:01C3B906] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Dec 2003 10:54:21 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Tuesday, December 02, 2003 8:50 AM > To: Nick Petroni > Cc: Joseph Salowey; eap@frascone.com > Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine > > > > On Tue, Dec 02, 2003 at 05:32:29AM -0500, Nick Petroni wrote: > > Thanks for the comments Joe. I have some comments as well. > > > > > [Joe] Int check should be internal to the method. It should be > > > possible > > intCheck IS set by an internal method, m.integrityCheck(). > > > > > for the method to signal that a packet should be ignored. > I think > > > breaking it out like this is misleading. > > [npetroni] I would say it IS possible for the method to > signal that a > > packet should be ignored just by setting intCheck. Perhaps it's the > > name you just don't like? I don't see how this is any > different from > > how it works now. > > > > > > [npetroni] This is meant to show that a method really > has its own > > > > state machine and that these states are separate from the final > > > > decision. I think it provides nice way of separating > the two, but > > > > I am willing to discuss this alternative notation. > > > > > > > [Joe] I agree that a method has its own state machine, however I > > > think exposing it here creates some problems. First it > complicates > > > the EAP > > [npetroni] This is not exposing the ACTUAL method state machine > > (IMHO), just a minimal set of signals that need to be > exported. There > > could be more. > > > > > state machine and second the internal state machine of the method > > > will vary from method to method. I think it would be > best to make > > > the method opaque as possible and use the minimal > interface between > > > method and EAP state machines. > > [npetroni] Perhaps the notation is confusing to some, I > don't think it > > is overly complex. Author's bias perhaps? I am open to changing it, > > but I guess I still don't understand the argument > completely. I would > > love to get additional input- any consensus from the group would be > > great. > > I agree with Joe that from implementation point of view, it > is better to reduce the number of variables needed for the > interface between method and EAP state machines. > > On the other hand, the other role of the EAP state machines > document is to help implementers understand how RFC2284bis > works. I think describing the peer state machine by using > the two variables (i.e., methodState and decision) helps us > understand Implementation Note in Section 4.2 of RFC2284bis > pretty well. > [Joe] I find it more confusing than enlightening. I think the two variables introduce a lot of complexity. If you want to describe the internal workings of the EAP-Method you should have a different state machine for that. > So, I would suggest keeping the currnet state machine as it > is (i.e., use methodState and decision variables), but adding > the following statement in "Implementation Consideration" section: > > "In the peer state machine, implementations may integrate > methodState and decision variables into a single variable that > may be obtained as a return value of m.process() method procedure." > [Joe] I would rather see the EAP state machine simple and have text describe how a method may implement its internal state machine. I also think m.intCheck should be integrated into m.process() as well. > > > > > > > > > 4. Idle timer > > > > > > > > > > It seems that there is a problem with the idle timer. > It would > > > > > be possible for the peer to never time out if it keeps on > > > > > receiving packets that it discards. This is not so good. > > > > [npetroni] hmm, that seems like a trivial DoS, no? Send > enough bad > > > > packets to the Peer and it goes away for a while? > > [npetroni] I guess I am responding to my own comment here, > but I went > > back and read your original thoughts on this and I think I see your > > point now. I misread where you thought the timer should be set. I > > think there could be a good argument for moving the > idleWhile setting > > to INITIALIZE and SEND_RESPONE. I don't think it should be > in METHOD > > just for abstraction. Besides, you would have to do it > conditionally > > in METHOD anyway. Are there other opinions on this? The > problem comes > > down to bad packets resetting the client timeout such that the peer > > can still go ClientTimeout without receiving a good packet > and yet not > > timeout. I guess the question is does the timeout go between GOOD > > packets or just packets? I see no reason why this is > explicitly a peer > > problem. Wouldn't the authenticator work the same? > > I agree that in both peer and authenticator state machines it > is not good to reset the timer value when the received > message is discarded. > > On the other hand, the peer idle timer should be set only > once in INITIALIZE state and should not be reset anywhere > else. This is because (correct me if I am wrong) the idle > timer for authenticator and the idle timer for peer are used > for different purposes. The former timer is message > retranmission timer and the latter timer is authentication > session timeout timer. > [Joe] I think I agree, I haven't had a chance to take a close look at the authenticator side of the state machine, but I think you are correct. > Yoshihiro Ohba > > > > > Thanks for the feedback- anything that helps make the document more > > understandable (and more correct :) ) is a good thing. > > > > Regards, > > nick > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 2 15:35:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08523 for ; Tue, 2 Dec 2003 15:34:59 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AFB1A580129; Tue, 2 Dec 2003 14:35:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 667C9580063; Tue, 2 Dec 2003 14:35:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3F84B580063 for ; Tue, 2 Dec 2003 14:34:19 -0600 (CST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.frascone.com (Postfix) with ESMTP id 4BC68580027 for ; Tue, 2 Dec 2003 14:34:17 -0600 (CST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08321; Tue, 2 Dec 2003 15:34:03 -0500 (EST) Message-Id: <200312022034.PAA08321@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: eap@frascone.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] I-D ACTION:draft-ietf-eap-rfc2284bis-07.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 02 Dec 2003 15:34:03 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk Filename : draft-ietf-eap-rfc2284bis-07.txt Pages : 67 Date : 2003-12-2 This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as PPP or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-eap-rfc2284bis-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-eap-rfc2284bis-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-2153957.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-eap-rfc2284bis-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-eap-rfc2284bis-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-2153957.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 3 02:33:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04083 for ; Wed, 3 Dec 2003 02:33:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4C2A5580127; Wed, 3 Dec 2003 01:34:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EA744580063; Wed, 3 Dec 2003 01:34:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D25F580063 for ; Tue, 2 Dec 2003 22:22:49 -0600 (CST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.frascone.com (Postfix) with ESMTP id 37CF4580027 for ; Tue, 2 Dec 2003 22:22:47 -0600 (CST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 20:22:11 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Dec 2003 20:22:45 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 20:22:52 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 20:23:30 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Dec 2003 20:22:50 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7122.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: [802.1] RE: [eap] Issue 204: Peer-to-peer operation Message-ID: Thread-Topic: [802.1] RE: [eap] Issue 204: Peer-to-peer operation Thread-Index: AcO4boCaBFlswB4nSKKAZ44QSt3hBAA5OeuG From: "Bernard Aboba" To: "CONGDON,PAUL (HP-Roseville,ex1)" , "Bernard Aboba" , "Nick Petroni" Cc: , X-OriginalArrivalTime: 03 Dec 2003 04:22:50.0161 (UTC) FILETIME=[1CB6DA10:01C3B955] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 2 Dec 2003 20:22:44 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B955.1910458E" ------_=_NextPart_001_01C3B955.1910458E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hope everyone had a joyous thanksgiving holiday.=20 =20 To clarify, Issue 204 was filed against the EAP State Machine document = in order to address a problem in the EAP authenticator state machine = pointed out in the resolution of Comment 15 on the IEEE 802.1aa D7.1 = ballot. The EAP issues list is available here: http://www.drizzle.com/~aboba/EAP/eapissues.html =20 The EAP WG discussion of Issue 204 is available starting here: http://mail.frascone.com/pipermail/public/eap/2003-November/001896.html =20 The resolution to Issue 15 pointed out an asymmetry in the operation of = a pass-through authenticator and a non-passthrough authenticator with = respect to peer-to-peer operation. Since in EAP the two cases are = supposed to behave identically with respect to the on-the-wire protocol, = this is believed to represent a bug in the operation of the = authenticator state machine, as well as a potential difficiency in AAA, = which may require the definition of a new attribute. =20 =20 A proposed fix to the EAP authenticator SM which would also affect the = 802.1X/EAP state machine interface, is available here: http://mail.frascone.com/pipermail/public/eap/2003-November/001915.html =20 RFC 2284bis sections 2.3 and 2.4 were posted to the list for reference = purposes, since they discuss the authenticator pass-through model and = peer-to-peer operation in general, even they do not discuss the = authenticator state machine or the proposed fixes to it. The entire text = of RFC 2284bis-07 (which has now completed IETF last call) is available = for inspection here: =20 http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-07.txt =20 =20 =20 =20 ------_=_NextPart_001_01C3B955.1910458E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [802.1] RE: [eap] Issue 204: Peer-to-peer operation=0A= =0A= =0A=
=0A=
Hope = everyone had a =0A= joyous thanksgiving holiday. 
=0A=
 
=0A=
To clarify, Issue 204 was filed against the EAP State = Machine =0A= document in order to address a problem in the EAP authenticator = state =0A= machine pointed out in the resolution of Comment 15 on the IEEE = 802.1aa =0A= D7.1 ballot. The EAP issues list is available here:
=0A= =0A=
 
=0A=
The EAP WG discussion of Issue 204 is available starting =0A= here:
=0A= =0A=
 
=0A=
The resolution to Issue 15 pointed out an asymmetry in = the =0A= operation of a pass-through authenticator and a non-passthrough = authenticator =0A= with respect to peer-to-peer operation.  Since in EAP the two cases = are =0A= supposed to behave identically with respect to the on-the-wire protocol, = this is =0A= believed to represent a bug in the operation of the authenticator state = machine, =0A= as well as a potential difficiency in AAA, which may require = the =0A= definition of a new attribute.  
=0A=
 
=0A=
=0A=
A proposed fix to the EAP authenticator SM which would = also affect =0A= the 802.1X/EAP state machine interface, is available here:
=0A=
=0A=
 
=0A=
RFC 2284bis sections 2.3 and 2.4 were posted to the list = for =0A= reference purposes, since they discuss the authenticator pass-through = model and =0A= peer-to-peer operation in general, even they do not discuss the = authenticator =0A= state machine or the proposed fixes to it. The entire text of RFC = 2284bis-07 =0A= (which has now completed IETF last call) is available for inspection = here:
=0A=
 
=0A= =0A=
 
=0A=
 
=0A=
 
=0A=
 
=0A= =0A= =0A= ------_=_NextPart_001_01C3B955.1910458E-- --------------InterScan_NT_MIME_Boundary-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 3 07:39:01 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12882 for ; Wed, 3 Dec 2003 07:39:00 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AD773580063; Wed, 3 Dec 2003 06:39:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7451C580109; Wed, 3 Dec 2003 06:39:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E0081580109 for ; Wed, 3 Dec 2003 06:38:11 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 9AED8580063 for ; Wed, 3 Dec 2003 06:38:02 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hB3Cc14u029817; Wed, 3 Dec 2003 07:38:01 -0500 (EST) From: Nick Petroni To: "CONGDON,PAUL (HP-Roseville,ex1)" Cc: "'Bernard Aboba'" , , Subject: RE: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Dec 2003 07:38:01 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Thanks for picking up on this thread Paul. Some comments are inline. > From what I understand from this thread, the situation we are talking about > is the case where both supplicant and authenticator are configured and > enabled on the same port (i.e. they are both contributing to the opening of > the controlled port), and the objective is to avoid running a 2nd > authentication in the opposite direction when the 1st authentication, using > a mutual method that delivers protected indications, actually succeeded. Ok, that's my understanding as well. > understand if it does. First question is when there is both an independent > supplicant and authenticator configured at the 802.1X layer, is there also a > corresponding independent EAP layer above each? I think the answer is yes. Depending on how you draw/label your layers there are probably not 2 "EAP Layers," but certainly the Peer and Authenticator traffic gets demultiplexed to separate state machines. Figure 2 in 2284bis, which you included in your second email, shows this best I think. Either way, I think your conclusion that they are separate is the right one. > I believe the assumption from the 802.1X level is that a received EAP frame > is delivered to both supplicant and authenticator in this case, and would > thus be handed up to their respective EAP layers. The peer side would be > ignoring responses and the authenticator side would be ignoring requests. I > think this all works and I believe Jim Burns has walked these scenarios. Yes, I think this is right. > A. standalone to standalone > B. standalone to passthru > C. passthru to passthru, each with their own path to their authentication > server > D. passthru to passthru with a single path to the authentication server ok. I didn't quite understand D, but I think I'm still with you. > In scenario A, since the EAP conversation is terminated locally, knowledge > of the mutual nature of the authentication and receipt of the protected > indications is well known on both sides. In this case, the side that acted I agree that both sides can know the authentication information but from a purely abstract point of view I think we should be clear which LAYERS know this information. The state machines are designed around a specific interface and the semantics may not be as clear as they could be in this case. I would argue that on the peer side eapSuccess only gets set if BOTH the peer and the authenticator have satisfied their policies. This is to avoid session hijacking and other attacks that can occur if the Peer EAP layer is not selective about when it tells the lower layer it will allow access. The reverse is not (necessarily) true of eapSuccess on the Authenticator side, even in the standalone case. I think it's ambiguous what a method is supposed to return if mutual auth fails but the peer is authenticated. Most would probably argue eapSuccess only means the peer has been authenticated in the Authenticator, but IMHO this is not the same as the peer side. It would be possible, however, to configure a (hypothetical) method to only return succees if it is confirmed that both sides accept the authentication. The question, at least for me, comes down to what the signals mean explicitly. > authenticator authorized. I understand, however, that we want the > standalone and passthru models to work the same, so this is a bit of a hack. I agree we want these to be the same. Furthermore, I would argue that the semantics of the interface variables need to be the same, not just the overall system to behave the same. > Scenario B is the typical case today where we don't configure both > supplicant and authenticator, but rather have the station act as supplicant > and the access point act as authenticator. Nonetheless, we must look at > this scenario in two cases. The first case, where the passthru mode starts > out as authenticator and the standalone as supplicant. In this case the > passthru would likely take advantage of the new variable defined for 802.1X > that opens the port regardless of what it's supplicant component is saying. > It would still run the supplicant machine however, just not depend upon the > result, so we would have two authentications taking place if the other side Ok, so I think you are saying this new variable indicates that the authenticator was sufficiently satisfied by the first authentication so it doesn't care about the second. Makes sense. > really wanted. The standalone side, however, would know it is satisfied and > could force authorize its authenticator and thus not run the second > authentication. In the second case, the passthru starts out as supplicant. > Again, since the passthru would be satisfied as supplicant, it could force > authorize its authenticator and not run the other machine. The standalone hmm, this part I am not so sure about, but maybe I just haven't worked it out right in my head. If the passthru is the supplicant, then the backend will not be involved in that particular authentication right? I mean, there is no passthru supplicant per se, so I am confused how the server part of the authentication gets done in this direction. I think I get really confused when we get to C and D too, as I don't understand exactly where the authentication is taking place. Before I say anymore, perhaps someone could clarify for me what C and D really look like. When you have two passthru machines, where does the supplicant live? My understanding was that the passthru device has a local supplicant, but then when it is acting this way how does it involve its backend server? > Scenario C would again have to take advantage of the new variable for the > side that started out as authenticator and would then need to force > authorize on the side that started out supplicant. We can always assume the > supplicant has full knowledge of the mutual authentication and protected > indications since it must terminate one side of the EAP conversation. The > supplicant side can always force authorize its authenticator complement, but > since the machines are independent, it is likely that the authenticator is > already running and the 2nd authentication is already going on. If the new > variable were not configured to ignore the supplicant result, the side that > started out as authenticator would always need to run and complete its > supplicant component. > > Scenario D is a strange special case that points out the need for the new > variable we added as a result of comment 15. It is simply impossible to > support this scenario unless there is the ability for the passthru NAS with > the path to the authentication server to open its port regardless of the > result of its supplicant component. If it didn't open its port the remote > peer acting as authenticator could not talk to the authentication server and > we are hung. > > Conclusion: > ----------- > > The supplicant side or any standalone system always has full knowledge of > the mutual nature of the authentication, so it could use this knowledge to I think you are right, but it depends on the semantics of eapSuccess I think. If eapSuccess only indicates confirmation of one-way authentication, then I think even though the local system 'knows' both sides are happy, EAP needs to make this clear somehow to the lower layer. > disable the other half of the 802.1X component (or force it authorized) and > cause only a single authentication exchange to take place. The passthru > authenticator side can ignore the result of its supplicant side by using the > new control variable, but it does not eliminate the second authentication > unless the other side has decided not to initiate one. OK, This seems fine to me. Assuming it has the information it needs from above, this works I think. Thanks Paul. Comment welcome. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 3 10:22:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19386 for ; Wed, 3 Dec 2003 10:22:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D222C580127; Wed, 3 Dec 2003 09:23:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 39CDC580063; Wed, 3 Dec 2003 09:23:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 87523580063 for ; Wed, 3 Dec 2003 09:22:20 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6B224580027 for ; Wed, 3 Dec 2003 09:22:18 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hB3FeIj11356; Wed, 3 Dec 2003 07:40:19 -0800 From: Bernard Aboba To: Nick Petroni Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com, stds-802-1@ieee.org Subject: RE: [eap] Issue 204: Peer-to-peer operation In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Dec 2003 07:40:18 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > understand if it does. First question is when there is both an independent > supplicant and authenticator configured at the 802.1X layer, is there also a > corresponding independent EAP layer above each? I think the answer is yes. I'd say that there is a single EAP layer on the host, but EAP authenticator and peer layers will be present above that. This makes it possible for the host to process traffic *both* for the EAP peer (EAP Request (Code=1), Success (3), Failure (4)) and for the authenticator (EAP Response (Code=2)). However, an EAP packet will only be processed if there is a method registered corresponding to the Type code in the packet *and* the method has registered with the EAP peer or authenticator layer or both. So if a method has only registered with the EAP peer layer and a packet destined for the authenticator layer is received (e.g. Code=2), then that packet will be dropped. > I believe the assumption from the 802.1X level is that a received EAP frame > is delivered to both supplicant and authenticator in this case, and would > thus be handed up to their respective EAP layers. The peer side would be > ignoring responses and the authenticator side would be ignoring requests. I > think this all works and I believe Jim Burns has walked these > scenarios. There are not two EAP layers operating. This is like saying that an IPv4 host that is both a TCP initiator and listener has two IP stacks. The EAP layer is capable of demultiplexing traffic between the EAP peer and authenticator layers, using the Code field in the EAP packet. The authenticator side would also be ignoring Success (3) and Failure (4) packets. > A. standalone to standalone > B. standalone to passthru > C. passthru to passthru, each with their own path to their authentication > server > D. passthru to passthru with a single path to the authentication server RFC 2284bis only defines passthrough operation for the EAP authenticator layer, not the EAP peer layer. AAA protocols such as RADIUS & Diameter only support pass-through of packets handled by the authenticator layer. That said, EAP WG has had presentations where EAP methods were resident on a smartcard, and "peer pass-through" was implemented for methods supported by the smartcard. However, the "peer pass-through" is a very different animal from a AAA server, so I'm also unclear about case D. > In this case the passthru would likely take advantage of the new > variable defined for 802.1X that opens the port regardless of what it's > supplicant component is saying. It would still run the supplicant > machine however, just not depend upon the result, so we would have two > authentications taking place if the other side One thing to keep in mind is the operation of a device such as an AP which also acts as an EAP peer to the switch to which it is attached. In this case, the AP is authenticating to the switch, presumably so as to prevent the insertion of rogue APs. Depending on the method used, if an authentication initiated by the switch fails, then the switch will not enable its controlled port, and the AP may also not enable the controlled port on its wired (DS) side. I am not sure that the operation of the AP is determined by a variable, so much as the operation of the method in question. After all, the AP is as much concerned with whether it is attaching to an authenticatic network as the switch is concerned about rogue APs. Adding more knobs just increases the probability that they will be set incorrectly. > Ok, so I think you are saying this new variable indicates that the > authenticator was sufficiently satisfied by the first authentication so it > doesn't care about the second. Makes sense. It makes sense if the variable is set by the method. > hmm, this part I am not so sure about, but maybe I just haven't worked it > out right in my head. If the passthru is the supplicant, then the backend > will not be involved in that particular authentication right? I mean, > there is no passthru supplicant per se, so I am confused how the server > part of the authentication gets done in this direction. I think I get > really confused when we get to C and D too, as I don't understand exactly > where the authentication is taking place. In C, one could assume the authentication taking place in a smartcard attached to the Supplicant/peer. > Scenario D is a strange special case that points out the need for the new > variable we added as a result of comment 15. It is simply impossible to > support this scenario unless there is the ability for the passthru NAS with > the path to the authentication server to open its port regardless of the > result of its supplicant component. If it didn't open its port the remote > peer acting as authenticator could not talk to the authentication server and > we are hung. I'm not sure that's incorrect, actually. Imagine an AP authenticating to a switch. The AP will not be able to access its authentication server until it convinces the switch that it is authentic, so that the switch will enable the controlled port. It is an interesting question whether the switch would be able to reach an authentication server operating on the wireless side of the AP, especially if in an EAP authentication initiated by the switch, the switch fails to authenticate to the peer in an EAP method supporting mutual authentication. I believe the answer to that question is that the authentication server would not be reachable. > disable the other half of the 802.1X component (or force it authorized) and > cause only a single authentication exchange to take place. The passthru > authenticator side can ignore the result of its supplicant side by using the > new control variable, but it does not eliminate the second authentication > unless the other side has decided not to initiate one. I believe this is correct. Regardless of what one side decides, the other side can always decide that its policy isn't satisfied and that it wants to initiate an authentication in the other direction. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 3 14:17:02 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29779 for ; Wed, 3 Dec 2003 14:16:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C385D580027; Wed, 3 Dec 2003 13:17:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7920A580063; Wed, 3 Dec 2003 13:17:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 092DE580063 for ; Wed, 3 Dec 2003 13:16:57 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id D3F03580027 for ; Wed, 3 Dec 2003 13:16:54 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hB3JZdh25146 for ; Wed, 3 Dec 2003 11:35:41 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [802.1] Confirmation ballot of P802.1X-REV/D8 (fwd) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Dec 2003 11:35:39 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Tony Jeffree Sent: Wednesday, December 03, 2003 9:45 AM To: stds-802-1@ieee.org Subject: [802.1] Confirmation ballot of P802.1X-REV/D8 This Email is attached to an official 802.1 Confirmation ballot form for P802.1X-REV/D8. As this is a confirmation ballot, some different rules apply: - The balloting period is only 15 days; the closing date is: 19 DECEMBER 2003 - The subject matter of the ballot is NOT the entire document; the scope of this ballot is ONLY those changes to the draft that were made in order to resolve the ballot comments on the previous draft (P802.1X-REV/D7.1, and any ballot resolutions that may have been incorrectly applied. - You need to return a ballot ONLY if you wish to change your previous vote on P802.1X-REV/D7.1. If you do not return a ballot, your previous vote will apply unchanged. - Responses are particularly solicited from those voters that made Disapprove votes on the previous ballot, in order to confirm whether or not the agreed ballot resolutions address their concerns. - If this ballot completes with no new negative votes, there will shortly be a sponsor ballot on this draft. The scope of the Sponsor ballot is the whole text. The editors particularly request that any issues identified with the document that are not within the scope of the confirmation ballot be separately identified now if at all possible to allow the group maximum time to consider the correct action to be taken. The chair extends his usual invitation to submit sponsor ballot comments on behalf of anyone not in the sponsor ballot pool. - Only those 802.1 voting members and liaisons that were eligible to vote on the P802.1X-REV/D7.1 ballot are entitled to vote in this ballot. Those people are: D7.1 vote Name ------- ---- DNV Floyd Backes n Les Bell y Paul Bottorff DNV Laura Bridge y Jim Burns y Dirceu Cavendish y Paul Congdon y Hesham Elbakoury y Norm Finn y David Frattura y Gerard Goubert y Steve Haddock DNV Ran Ish-Shalom y Neil Jarvis y Tony Jeffree t Hal Keen t Bill Lane y Roger Lapuh y Loren Larsen y Dinesh Mohan n Bob Moskowitz Y Don O'Connor Y Glenn Parsons y Frank Reichstein y John Roese y Allyn Romanow y Dan Romascanu t Dolors Sala y Mick Seaman DNV Kazuo Takagi y Michel Thorsen y Dennis Volpano y Karl Weber y Michael D. Wright N Russ Housley Y Dorothy Stanley Y Jesse Walker (Y = Approve, N = Disapprove, T = Abstain due to lack of time, DNV = Did Not Vote) The PDF file of P802.1X-REV/D8, with change bars, can be found at: http://www.ieee802.org/1/files/private/x-REV-drafts/d8/802-1X-REV-d8-cb.pdf The same document with change bars removed can be found at: http://www.ieee802.org/1/files/private/x-REV-drafts/d8/802-1X-REV-d8.pdf The disposition of the comments on the previous P802.1X-REV ballot can be found at: http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf To access either file, the following userID/Password are needed: User ID: p8021 Password: go_wildcats If you have any difficulty downloading or reading either file, let me know. As is normal with 802.1 ballots, any ballot comments must specify not only what problems have been identified with the text, but also what the commenter proposes as a solution. In particular, any Disapprove ballots are required to be accompanied by a clear statement of the changes that the voter requires to be made to the text in order for the ballot to be changed to Approve. Any comments accompanying the ballot must be presented using the following template: NAME: COMMENT TYPE: CLAUSE: PAGE: LINE: COMMENT START:
COMMENT END: SUGGESTED CHANGES START:
SUGGESTED CHANGES END: RETURNING YOUR BALLOT FORM ========================== Your ballot must be returned to: stds-802-1@ieee.org You are requested to use (exactly!) the appropriate Subject line from the following set when returning your ballot. Please send your ballot with the Subject line explicitly set, rather than using the Reply function in your mailer. P802.1X-REV/D8 Ballot - Approve P802.1X-REV/D8 Ballot - Comments (with approve) P802.1X-REV/D8 Ballot - Disapprove P802.1X-REV/D8 Ballot - Comments (with abstain) P802.1X-REV/D8 Ballot - Abstain Regards, Tony Jeffree, 802.1 Chair. ****************************** Ballot form follows..... ****************************** ------------------------------------------------------------------------ ------------------------------------------------------------------------ NOTE: EMAIL ALL BALLOT RESPONSES ONLY TO: stds-802-1@ieee.org ------------------------------------------------------------------------ ------------------------------------------------------------------------ P802.1X-REV/D8 EMAIL BALLOT 1th October 2003 TO: Tony Jeffree Editor, P802.1X-REV SUBJECT: P802.1X-REV - Port Access Control - Revision _____ I Approve (may attach non-binding comments below) _____ I Disapprove (must attach binding comments below) _____ Non-Voter - Comment Only (comments attached below) _____ I Abstain for the following reasons (may attach non-binding comments below): ______ Lack of Time ______ Lack of Expertise ______ Other: _______________________________________________ ____________________________________________ (Name) ____________________________________________ (Telephone No.) ------------------------------------------------------------------------ INCLUDE COMMENTS BELOW THIS POINT _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 3 15:08:15 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02167 for ; Wed, 3 Dec 2003 15:07:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B652B58012C; Wed, 3 Dec 2003 14:08:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1ABCA580127; Wed, 3 Dec 2003 14:08:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8CCA2580127 for ; Wed, 3 Dec 2003 14:07:29 -0600 (CST) Received: from deneb.mtghouse.com (unknown [206.152.191.132]) by mail.frascone.com (Postfix) with SMTP id A340C580126 for ; Wed, 3 Dec 2003 14:07:27 -0600 (CST) Received: (qmail 11327 invoked from network); 3 Dec 2003 20:07:26 -0000 Received: from unknown (HELO mtghouse.com) (192.168.11.223) by deneb.mtghouse.com with SMTP; 3 Dec 2003 20:07:26 -0000 Message-ID: <3FCE4282.80005@mtghouse.com> From: Jim Burns User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030829 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Nick Petroni , "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com, stds-802-1@ieee.org Subject: Re: [eap] Issue 204: Peer-to-peer operation References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 03 Dec 2003 15:07:30 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi folks, Comments below. Jim B. Bernard Aboba wrote: >>understand if it does. First question is when there is both an independent >>supplicant and authenticator configured at the 802.1X layer, is there also a >>corresponding independent EAP layer above each? I think the answer is yes. >> >> > >I'd say that there is a single EAP layer on the host, but EAP >authenticator and peer layers will be present above that. This makes it >possible for the host to process traffic *both* for the EAP peer >(EAP Request (Code=1), Success (3), Failure (4)) and for the authenticator >(EAP Response (Code=2)). However, an EAP packet will only be processed >if there is a method registered corresponding to the Type code >in the packet *and* the method has registered with the EAP peer or >authenticator layer or both. So if a method has only registered with the >EAP peer layer and a packet destined for the authenticator layer is >received (e.g. Code=2), then that packet will be dropped. > > Our original assumption in the design of the .1X/EAP state machines was that EAP was a functional entity that could have multiple instantiations, one for each state machine. So, the current .1X design delivers the EAP frame once to each EAP machine (which looks like two deliveries of the same frame if there is a single EAP mux/demux layer). The .1X transport does not filter the frames as EAP peer frames and EAP authenticator frames because there is no indication in the EAPOL header of the type of EAP frame being carried and their is no logic in .1X which is related to the EAP header. So, we need to answer the question: Is their a single EAP layer above the lower layer transport that does mux/demux? Does the EAP layer assume there is a single channel to the lower layer transport or one for each of its EAP's state machine? If the answer is that there is a single EAP layer that wants only one copy of the EAP frame then I believe there are several possibilities (all with consequences): 1. Add a mux/demux layer to the .1X standard that looks at the EAP header and directs only one copy of the frame to the correct .1X state machine. This is a layer violation and any changes to the EAP header will require a change to the .1X standard. I imagine that this will slow any changes just due to inter-standards bodies coordination. 2. Modify EAPOL to have a field that indicates which component generated it (Authenticator or Supplicant) and then add a mux/demux layer to the .1X standard that looks at this EAPOL header and directs the incoming frame appropriately. This has backwards compatibility problems. What do we do with a frame from an older version of .1X that does not have this field? (look at the EAP header? deliver the frame to both .1X machines (and hence deliver two copies to the mux/demux layer of EAP)) 3. Alter the .1X state machines so that there is a single state machine that signals to EAP that an EAP frame is available, rather than have both .1X machines do this. This solves the problem in one direction -- EAP only gets one copy of the EAP frame and .1X did not cause a layer violation. Unfortunately, the .1X state machines will both transition as if an EAP frame had been seen and both will need a correct response from both EAP machines. Since the EAP mux/demux will only send the EAP frame to the correct EAP machine there will only be one response forthcoming and the .1X/EAP machines will be out of sync. If the mux/demux EAP machine when it delivered the frame to one EAP machine, at the same time signalled the other .1X machine it would get no response (sets eapNoResp for .1X supplicant or sets eapNoReq for the .1X authenticator) then I think this may solve the problem without layer violations, multiple frame deliveries or backwards compatibilty problems. This doesn't solve the other issue we seem to be discussing: both machines running, a mutual authentication EAP method is used between two of the machines so there is no need to run the two machines in the opposite direction. As an aside, if there is a single EAP layer, then the control variables between the EAP layer and the .1X layer should have different names between the supplicant and authenticator (for instance, eapSuccess and eapFailure signaled from a single EAP layer is not meaningful since there is no context as to which machine is signalling success. Rather, the EAP layer will need to signal eapPeerSuccess or eapAuthSuccess, etc. Again, our assumption of an EAP instance per .1X state machine. > > >>I believe the assumption from the 802.1X level is that a received EAP frame >>is delivered to both supplicant and authenticator in this case, and would >>thus be handed up to their respective EAP layers. The peer side would be >>ignoring responses and the authenticator side would be ignoring requests. I >>think this all works and I believe Jim Burns has walked these >>scenarios. >> >> > >There are not two EAP layers operating. This is like saying that an IPv4 >host that is both a TCP initiator and listener has two IP stacks. The >EAP layer is capable of demultiplexing traffic between the EAP peer and >authenticator layers, using the Code field in the EAP packet. > >The authenticator side would also be ignoring Success (3) and Failure (4) >packets. > > This means that EAP is to be treated as a network layer, rather than a functional component that can have multiple instantiations within a single network layer. Hence the requirement that it receive only a single stream of frames. --------------------------------------------------------- With regard to the other issue, namely, if both machines are running in a single entity and one of the machines successfully completes a mutual authentication method then how can this open the controlled port (without the other machine needing to complete successfully or complete at all for that matter): In an attempt to clarify how EAP could control this, I have created a picture which attempts to show the variables that control the controlled port within the .1X state machine in the case that both machines are active: ********> This is an inter state-machine signal -----------> This indicates a data flow +------------------------------------------------------------------+ | Higher Layer (EAP/AAA) | +------------------------------------------------------------------+ | * ^ ^ * | | * | | * | EAP eapSuccess EAP EAP eapSuccess EAP response eapFail request response eapFail request | * success | * success | * fail | * fail | * | | * | V V | | V V +----------------------------------+ +----------------------------------+ | .1X Supplicant | | .1X Authenticator | |switch (suppControlledPortControl)| |switch(authControlledPortControl) | | Force Unauthorized: | | Force Unauthorized: | | suppPortStatus = FALSE | | authPortStatus = FALSE | | Force Authorized: | | Force Authorized: | | suppPortStatus = TRUE | | authPortStatus = TRUE | | Auto: | | Auto: | | suppPortStatus = (eapSuccess | | authPortStatus = (eapSuccess | | && | | && | | portValid) | | portValid) | +----------------------------------+ +----------------------------------+ ^ ^ | | +--------------------------------------| | V +----------------------------------+ +----------------------------------+ | .1X Controlled Port | | .1X Uncontrolled Port | | AuthControlledPortStatus | | | | = portStatus | | | | = (suppPortStatus && | | | | authPortStatus) | | | +----------------------------------+ +----------------------------------+ ^ ^ | | +-----------------+-------------------+ | | V I have taken a liberty with suppPortStatus and authPortStatus and indicated that they are directly set by eapSuccess...actually this is not 100% true, eapSuccess indirectly causes the setting of these variables, but for simplicity I have indicated as I have. If the EAP/Higher layer detects that a mutual authentication has taken place on one of its machines set the .1X variable for the alternate machine (suppControlledPortControl or authControlledPortControl) to Force Authorized. Actually, there may be some issues with this, but this is the basic idea: EAP knows it no longer cares about the result from the alternate machine and wishes to open the controlled port despite that machine's result so it sets a variable forcing the result from that machine to TRUE. These two variables would need to be indicated as another inter state-machine variable in appendix F. This is based on draft 7-2 of .1X. I just received the draft 8 of 1X in my inbox, but want to get this out to folks. Later, Jim B. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 3 17:22:03 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12721 for ; Wed, 3 Dec 2003 17:21:58 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7C2E9580027; Wed, 3 Dec 2003 16:22:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9F7D6580063; Wed, 3 Dec 2003 16:22:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 67FD1580063 for ; Wed, 3 Dec 2003 16:21:12 -0600 (CST) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by mail.frascone.com (Postfix) with ESMTP id DEC84580027 for ; Wed, 3 Dec 2003 16:21:10 -0600 (CST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel8.hp.com (Postfix) with ESMTP id 0418B1C01271; Wed, 3 Dec 2003 17:21:10 -0500 (EST) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id E53121C00C51; Wed, 3 Dec 2003 17:21:09 -0500 (EST) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Dec 2003 17:21:09 -0500 Message-ID: From: "CONGDON,PAUL (HP-Roseville,ex1)" To: "'Bernard Aboba'" , Nick Petroni Cc: "CONGDON,PAUL (HP-Roseville,ex1)" , eap@frascone.com, stds-802-1@ieee.org Subject: RE: [802.1] RE: [eap] Issue 204: Peer-to-peer operation MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 3 Dec 2003 17:21:05 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Clearly I didn't articulate scenario D very well, and I was never assuming there was a pass-thru supplicant. I always assumed that if there were a supplicant component configured and running, the EAP conversation was terminated locally there, so thus the knowledge of whether the authentication was mutual and included protected indications was well known on the supplicant. So, scenario D was trying to describe the following case (and yes, the AP<->Switch example is a good one): ------------- ------------- ------------------------- | | | | | | | pass-thru | | pass-thru | | authentication server | | | | | | | ------------- ------------- ------------------------- | | | | ------------------------ ---------------------------- Both of these devices share the same authentication server. Since both are running both authenticator and supplicant, the AP's authenticator obviously can't complete until the switch has opened its controlled port. So the AP supplicant would authenticate to the switch authenticator who could talk to the AS, then the AP authenticator would authenticate the switch supplicant, but since the switch has the new variable enabled, this doesn't prevent the controlled port from being opened. Hope this makes sense... Paul > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of > Bernard Aboba > Sent: Wednesday, December 03, 2003 7:40 AM > To: Nick Petroni > Cc: CONGDON,PAUL (HP-Roseville,ex1); eap@frascone.com; > stds-802-1@ieee.org > Subject: [802.1] RE: [eap] Issue 204: Peer-to-peer operation > > > > > understand if it does. First question is when there is both an > > independent supplicant and authenticator configured at the 802.1X > > layer, is there also a corresponding independent EAP layer > above each? > > I think the answer is yes. > > I'd say that there is a single EAP layer on the host, but EAP > authenticator and peer layers will be present above that. > This makes it possible for the host to process traffic *both* > for the EAP peer (EAP Request (Code=1), Success (3), Failure > (4)) and for the authenticator (EAP Response (Code=2)). > However, an EAP packet will only be processed if there is a > method registered corresponding to the Type code in the > packet *and* the method has registered with the EAP peer or > authenticator layer or both. So if a method has only > registered with the EAP peer layer and a packet destined for > the authenticator layer is received (e.g. Code=2), then that > packet will be dropped. > > > I believe the assumption from the 802.1X level is that a > received EAP > > frame is delivered to both supplicant and authenticator in > this case, > > and would thus be handed up to their respective EAP layers. > The peer > > side would be ignoring responses and the authenticator side > would be > > ignoring requests. I think this all works and I believe > Jim Burns has > > walked these scenarios. > > There are not two EAP layers operating. This is like saying > that an IPv4 host that is both a TCP initiator and listener > has two IP stacks. The EAP layer is capable of > demultiplexing traffic between the EAP peer and authenticator > layers, using the Code field in the EAP packet. > > The authenticator side would also be ignoring Success (3) and > Failure (4) packets. > > > A. standalone to standalone > > B. standalone to passthru > > C. passthru to passthru, each with their own path to their > authentication > > server > > D. passthru to passthru with a single path to the authentication > > server > > RFC 2284bis only defines passthrough operation for the EAP > authenticator layer, not the EAP peer layer. AAA protocols > such as RADIUS & Diameter only support pass-through of > packets handled by the authenticator layer. That said, EAP WG > has had presentations where EAP methods were resident on a > smartcard, and "peer pass-through" was implemented for > methods supported by the smartcard. However, the "peer > pass-through" is a very different animal from a AAA server, > so I'm also unclear about case D. > > > In this case the passthru would likely take advantage of the new > > variable defined for 802.1X that opens the port regardless of what > > it's supplicant component is saying. It would still run the > supplicant > > machine however, just not depend upon the result, so we > would have two > > authentications taking place if the other side > > One thing to keep in mind is the operation of a device such > as an AP which also acts as an EAP peer to the switch to > which it is attached. In this case, the AP is authenticating > to the switch, presumably so as to prevent the insertion of > rogue APs. Depending on the method used, if an > authentication initiated by the switch fails, then the switch > will not enable its controlled port, and the AP may also not > enable the controlled port on its wired (DS) side. I am not > sure that the operation of the AP is determined by a > variable, so much as the operation of the method in question. > After all, the AP is as much concerned with whether it is > attaching to an authenticatic network as the switch is > concerned about rogue APs. Adding more knobs just increases > the probability that they will be set incorrectly. > > > Ok, so I think you are saying this new variable indicates that the > > authenticator was sufficiently satisfied by the first > authentication > > so it doesn't care about the second. Makes sense. > > It makes sense if the variable is set by the method. > > > hmm, this part I am not so sure about, but maybe I just > haven't worked > > it out right in my head. If the passthru is the supplicant, > then the > > backend will not be involved in that particular > authentication right? > > I mean, there is no passthru supplicant per se, so I am > confused how > > the server part of the authentication gets done in this > direction. I > > think I get really confused when we get to C and D too, as I don't > > understand exactly where the authentication is taking place. > > In C, one could assume the authentication taking place in a > smartcard attached to the Supplicant/peer. > > > Scenario D is a strange special case that points out the > need for the > > new variable we added as a result of comment 15. It is simply > > impossible to support this scenario unless there is the ability for > > the passthru NAS with the path to the authentication server to open > > its port regardless of the result of its supplicant > component. If it > > didn't open its port the remote peer acting as > authenticator could not > > talk to the authentication server and we are hung. > > I'm not sure that's incorrect, actually. Imagine an AP > authenticating to a switch. The AP will not be able to > access its authentication server until it convinces the > switch that it is authentic, so that the switch will enable > the controlled port. It is an interesting question whether > the switch would be able to reach an authentication server > operating on the wireless side of the AP, especially if in an > EAP authentication initiated by the switch, the switch fails > to authenticate to the peer in an EAP method supporting > mutual authentication. I believe the answer to that question > is that the authentication server would not be reachable. > > > disable the other half of the 802.1X component (or force it > > authorized) and cause only a single authentication exchange to take > > place. The passthru authenticator side can ignore the > result of its > > supplicant side by using the new control variable, but it does not > > eliminate the second authentication unless the other side > has decided > > not to initiate one. > > I believe this is correct. Regardless of what one side > decides, the other side can always decide that its policy > isn't satisfied and that it wants to initiate an > authentication in the other direction. > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 8 05:40:24 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04241 for ; Mon, 8 Dec 2003 05:40:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EC4D458012D; Mon, 8 Dec 2003 04:40:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7EAF3580023; Mon, 8 Dec 2003 04:40:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 213FB580023 for ; Mon, 8 Dec 2003 04:39:24 -0600 (CST) Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by mail.frascone.com (Postfix) with ESMTP id BF321580017 for ; Mon, 8 Dec 2003 04:39:21 -0600 (CST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB8Ad0O26165; Mon, 8 Dec 2003 10:39:00 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 10:39:01 -0000 Message-ID: From: "Mark Watson" To: "'jari.arkko@piuha.net'" , "'eap@frascone.com'" , "'Adrangi, Farid'" , "'Pasi Eronen'" Subject: RE: [eap] network discovery & selection: problem definition MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BD77.7911D2F8" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 8 Dec 2003 10:38:53 -0000 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BD77.7911D2F8 Content-Type: text/plain Hi Jari, Some comments on your questions below ... I agree with your plan. > > The primary network discovery and selection issue > is routing within the AAA infrastructure, giving > access to the user from the right home AAA and via > the right AAA proxies. Currently, we have the NAI [RFC2486] > functionality. NAIs allow users to specify their domain so > that the AAA requests can be routed to the right home AAA > servers. However, this does not provide support for the following: > > o Ability of the client to know which of his multiple > home networks are available from a given access? > Can I get to jari.arkko@ericsson.com, or only to > jarkko@piuha.net? Interesting question. This is not a requirement that 3GPP have discussed, since a given user identity (IMSI) is associated with a single Home Network. Bu I wonder if this problem is in fact a sub-problem of the 'AAA intermediary selection' problem when you consider: a) The AAA server in the WLAN does not know whether the 'next hop' AAA servers that the user requsts routing to is in fact an intermediaries or a home network for this user. The WLAN owner just knows that they have an agreement with this other network which allows them to be paid for users authenticated by that route - this is all they care about. B) At this stage we are considering user selection only of a single 'hop' for the AAA message > > o Ability of the AAA requests to be routed correctly > where there is no complete, global AAA routing table. > > Deployed AAA mechanisms use an essentially > statically configured local routing tables, > there is no e.g. link state routing protocols > for AAA. > > Such local mechanisms are sufficient when there > limited amout of branching in the AAA network. > For instance, there is no need for a global > routing table if all your clients are either > locally authenticated or served by one other entity > (such as a global ISP, teleoperator, or a roaming > consortium). > > However, if the access network supports two different > intermediaries, it becomes necessary to figure out > which intermediary handles the domain given in a NAI. > > Question: what is the expected number of intermediaries > per one network hop? Can you cite current numbers from > existing networks, or projections of future network > topologies? I think in the short/medium term we will be staying with statically configured routing tables just because these tables represent not just message routing but business relationships between the various AAA entities. If my AAA server is configured to believe Authentication success messages returning from a someone elses AAA server then I assume I must have some business relationship with that other person which covers: (i) the effectiveness of the authentication scheme they use (ii) a commitment to pay for the access used by the people they authenticate [mayby (i) is their problem, not mine] It would be difficult to create a system for dynamic update of routing tables which maintained the integrity of these business relationships. I would usually expect there to be a single intermediary in the path from the local access network to the Home Network. At least this is the 3GPP model. I would envisage that a WLAN hotspot provided would make agreements with several 'local' 3GPP network providers. These local providers act as intermediaries to other 3GPP networks across the world. I don't rule out the possibility that rather than making these agreements themselves, a hotspot provided might make a single agreement with some single local aggregator who has then the agreements with the various 3GPP networks. But this is just the hotspot owner outsourcing this aspect of the system - it's invisible to the architecture. > > Question: Is it necessary to support multiple levels > of selection, e.g. go first to intermediary 1, then > to intermediary 2, etc? > I don't think this is necessary. Even if someone found a realistic use-case, I would argue that it's overcomplicated for the first phase of this work. > o For commercial reasons, intermediaries want > to participate the AAA transaction. > > Question: Is there a need for someone else than > the access network to control the routing to go > via a special intermediary? This is not very > clear to me. Do you mean, 'why do we need user selection at all?'. The cost to the user may depend on the intermediary chosen (it depends on the deal made between the chosen intermediary and the Home Network). So then the user should be able to make this choice - presumably based on information obtained (out-of-band) from their Home Network on costs & possibly other factors. The access network would always choose the intermediary with whom they have struck the 'best deal' - i.e. most expensive for the user. > > o For the purposes of choosing an intermediary > with specific properties, users may wish to > control network selection, or at least wish > to be aware of the results. For instance, > I can get to @ericsson.com either via piuha.net > or commercialoperator.net, but since I want to > go via piuha.net since it is free for me. > > Question: what are the security requirements for > this? This is bordering on solution space, but as > far as I know, none of the proposed mechanisms > can support secure advertisements or secure > selection indications. Is this acceptable? It should be possible for the user/Home network to verify that the request was indeed routed through the user's choice of intermediary. As for 'securing' network advertisements (including SSIDs etc.) then I'm not sure what this means. The user has no prior relationship with the access network - even if I could be sure that an access network claiming to be 'Joe's access network' really does have that name and that the advertisement has not been modified by anybody else, I am no better off because I do not know if I can trust Joe at all. A 'rouge' access point might be able to attract authentication attempts with false advertisements, but if they have no relationship with a 'real' intermediary, then they will not be able to provide any service. If they do have a relationship with a 'real' intermediary then their false advertisement will presumably be in breach of that agreement or their agreement with another intermediary. For example, access networks have an incentive to include false information in the advertisement which directs users to the intermediary that is most lucrative for the access network. This presumably involves including false information about intermediaries which are cheaper for the user, or omitting that information altogether. The cheaper intermediary will not be happy about this, but as for whether we should include mechanisms to help them discover such fraudulent activity, I am not sure. So, I would suggest we restrict our requirements to verifying that the intermediary used was the one requested by the user. > > Question: what kind of information needs to be > presented in protocols vs. provisioned in the > clients vs. simply told to the user off-line? > It seems that it would be possible to provide > network name over protocols, but a standardized > format for offered CoS of QoS would probably > not be possible. > Agreed. > An interesting twist in the AAA routing problem > is that all the above has to work for requests, responses, > as well as server-initiated messages. > I had assumed that once the intial request was sent, this estalishes some kind of 'session state' in the AAA devices so that all subsequent messages related to that initial request follow the same path. Is this not correct ? Do some intemediaries operate in a completely stateless fashion ? > The network discovery and selection problem is closely > related to the problem of access point discovery and > selection in wireless networks. The two problems coincide > when each access point offers exactly one network over > one AAA route. However, the network discovery and selection > problem may exist even where there is just one access point > to attach to, if it offers multiple networks or multiple > routes to these networks. > > During the discussion of solutions for these problems, > it has become apparent that there are some additional > constraints that may have to be placed on solutions. Some of > the possible constraints are listed below: > > o Solution can be adopted for the whole network > without requiring changes to the largest base > of installed devices -- access points and > clients. > Not sure how we could introduce intermediate selection without impacting the clients. For 3GPP, anyway, client impacts are assumed because at least we have to implement EAP-SIM/AKA. Do you mean that any solution should be backwards compatible with existing clients ? i.e. existing clients can still be supported on a network which also provides advertisements and allows intermediary selection. That would seem essential. > o Allow interoperability with clients, access networks, > AAA proxies, and AAA servers that have not been > modified to support network discovery and selection. > > o Works on all AAA protocols. > > o Does not prevent the introduction of new AAA or > access network features, such as link-state AAA > routing protocols (pretty far fetched) or > fast handoffs. > > o Does not consume a significant amount of > resources, such as bandwidth or network > attachment time. > > o Does not cause a problem with limited packet > sizes of current protocols. > > Further discussion can be found from > http://www.ietf.org/internet-drafts/draft-adrangi-eap-network- discovery-and-selection-00.txt (including some solution space issues too). --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------_=_NextPart_001_01C3BD77.7911D2F8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [eap] network discovery & selection: problem = definition

Hi Jari,

Some comments on your questions below ...

<snip - proposed plan for discussion>

I agree with your plan.

>
> The primary network discovery and selection = issue
> is routing within the AAA infrastructure, = giving
> access to the user from the right home AAA and = via
> the right AAA proxies. Currently, we have the = NAI [RFC2486]
> functionality. NAIs allow users to specify = their domain so
> that the AAA requests can be routed to the = right home AAA
> servers. However, this does not provide support = for the following:
>
>    o  Ability of the client = to know which of his multiple
>       home = networks are available from a given access?
>       Can I get = to jari.arkko@ericsson.com, or only to
>       = jarkko@piuha.net?

Interesting question. This is not a requirement that = 3GPP have discussed, since a given user identity (IMSI) is associated = with a single Home Network.

Bu I wonder if this problem is in fact a sub-problem = of the 'AAA intermediary selection' problem when you consider:
a) The AAA server in the WLAN does not know whether = the 'next hop' AAA servers that the user requsts routing to is in fact = an intermediaries or a home network for this user. The WLAN owner just = knows that they have an agreement with this other network which allows = them to be paid for users authenticated by that route - this is all = they care about.

B) At this stage we are considering user selection = only of a single 'hop' for the AAA message

>
>    o  Ability of the AAA = requests to be routed correctly
>       where there = is no complete, global AAA routing table.
>
>       Deployed = AAA mechanisms use an essentially
>       statically = configured local routing tables,
>       there is no = e.g. link state routing protocols
>       for = AAA.
>
>       Such local = mechanisms are sufficient when there
>       limited = amout of branching in the AAA network.
>       For = instance, there is no need for a global
>       routing = table if all your clients are either
>       locally = authenticated or served by one other entity
>       (such as a = global ISP, teleoperator, or a roaming
>       = consortium).
>
>       However, if = the access network supports two different
>       = intermediaries, it becomes necessary to figure out
>       which = intermediary handles the domain given in a NAI.
>
>       Question: = what is the expected number of intermediaries
>       per one = network hop? Can you cite current numbers from
>       existing = networks, or projections of future network
>       = topologies?

I think in the short/medium term we will be staying = with statically configured routing tables just because these tables = represent not just message routing but business relationships between = the various AAA entities. If my AAA server is configured to believe = Authentication success messages returning from a someone elses AAA = server then I assume I must have some business relationship with that = other person which covers:

(i) the effectiveness of the authentication scheme = they use
(ii) a commitment to pay for the access used by the = people they authenticate

[mayby (i) is their problem, not mine]

It would be difficult to create a system for dynamic = update of routing tables which maintained the integrity of these = business relationships.

I would usually expect there to be a single = intermediary in the path from the local access network to the Home = Network. At least this is the 3GPP model. I would envisage that a WLAN = hotspot provided would make agreements with several 'local' 3GPP = network providers. These local providers act as intermediaries to other = 3GPP networks across the world.

I don't rule out the possibility that rather than = making these agreements themselves, a hotspot provided might make a = single agreement with some single local aggregator who has then the = agreements with the various 3GPP networks. But this is just the hotspot = owner outsourcing this aspect of the system - it's invisible to the = architecture. 

>
>       Question: = Is it necessary to support multiple levels
>       of = selection, e.g. go first to intermediary 1, then
>       to = intermediary 2, etc?
>

I don't think this is necessary. Even if someone = found a realistic use-case, I would argue that it's overcomplicated for = the first phase of this work.

>    o  For commercial = reasons, intermediaries want
>       to = participate the AAA transaction.
>
>       Question: = Is there a need for someone else than
>       the access = network to control the routing to go
>       via a = special intermediary? This is not very
>       clear to = me.

Do you mean, 'why do we need user selection at = all?'.

The cost to the user may depend on the intermediary = chosen (it depends on the deal made between the chosen intermediary and = the Home Network). So then the user should be able to make this choice = - presumably based on information obtained (out-of-band) from their = Home Network on costs & possibly other factors.

The access network would always choose the = intermediary with whom they have struck the 'best deal' - i.e. most = expensive for the user.

>
>    o  For the purposes of = choosing an intermediary
>       with = specific properties, users may wish to
>       control = network selection, or at least wish
>       to be aware = of the results. For instance,
>       I can get = to @ericsson.com either via piuha.net
>       or = commercialoperator.net, but since I want to
>       go via = piuha.net since it is free for me.
>
>       Question: = what are the security requirements for
>       this? This = is bordering on solution space, but as
>       far as I = know, none of the proposed mechanisms
>       can support = secure advertisements or secure
>       selection = indications. Is this acceptable?

It should be possible for the user/Home network to = verify that the request was indeed routed through the user's choice of = intermediary.

As for 'securing' network advertisements (including = SSIDs etc.) then I'm not sure what this means. The user has no prior = relationship with the access network - even if I could be sure that an = access network claiming to be 'Joe's access network' really does have = that name and that the advertisement has not been modified by anybody = else, I am no better off because I do not know if I can trust Joe at = all.

A 'rouge' access point might be able to attract = authentication attempts with false advertisements, but if they have no = relationship with a 'real' intermediary, then they will not be able to = provide any service. If they do have a relationship with a 'real' = intermediary then their false advertisement will presumably be in = breach of that agreement or their agreement with another = intermediary.

For example, access networks have an incentive to = include false information in the advertisement which directs users to = the intermediary that is most lucrative for the access network. This = presumably involves including false information about intermediaries = which are cheaper for the user, or omitting that information = altogether. The cheaper intermediary will not be happy about this, but = as for whether we should include mechanisms to help them discover such = fraudulent activity, I am not sure.

So, I would suggest we restrict our requirements to = verifying that the intermediary used was the one requested by the = user.

>
>       Question: = what kind of information needs to be
>       presented = in protocols vs. provisioned in the
>       clients vs. = simply told to the user off-line?
>       It seems = that it would be possible to provide
>       network = name over protocols, but a standardized
>       format for = offered CoS of QoS would probably
>       not be = possible.
>

Agreed.

> An interesting twist in the AAA routing = problem
> is that all the above has to work for requests, = responses,
> as well as server-initiated messages.
>

I had assumed that once the intial request was sent, = this estalishes some kind of 'session state' in the AAA devices so that = all subsequent messages related to that initial request follow the same = path. Is this not correct ? Do some intemediaries operate in a = completely stateless fashion ?

> The network discovery and selection problem is = closely
> related to the problem of access point = discovery and
> selection in wireless networks. The two = problems coincide
> when each access point offers exactly one = network over
> one AAA route. However, the network discovery = and selection
> problem may exist even where there is just one = access point
> to attach to, if it offers multiple networks or = multiple
> routes to these networks.
>
> During the discussion of solutions for these = problems,
> it has become apparent that there are some = additional
> constraints that may have to be placed on = solutions. Some of
> the possible constraints are listed = below:
>
>    o  Solution can be = adopted for the whole network
>       without = requiring changes to the largest base
>       of = installed devices -- access points and
>       = clients.
>

Not sure how we could introduce intermediate = selection without impacting the clients. For 3GPP, anyway, client = impacts are assumed because at least we have to implement = EAP-SIM/AKA.

Do you mean that any solution should be backwards = compatible with existing clients ? i.e. existing clients can still be = supported on a network which also provides advertisements and allows = intermediary selection. That would seem essential.


>    o  Allow interoperability = with clients, access networks,
>       AAA = proxies, and AAA servers that have not been
>       modified to = support network discovery and selection.
>
>    o  Works on all AAA = protocols.
>
>    o  Does not prevent the = introduction of new AAA or
>       access = network features, such as link-state AAA
>       routing = protocols (pretty far fetched) or
>       fast = handoffs.
>
>    o  Does not consume a = significant amount of
>       resources, = such as bandwidth or network
>       attachment = time.
>
>    o  Does not cause a = problem with limited packet
>       sizes of = current protocols.
>
> Further discussion can be found from
> http://www.ietf.org/internet-drafts/draft-adrangi-eap-= network-
discovery-and-selection-00.txt
(including some solution space issues too).

--Jari


_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap

------_=_NextPart_001_01C3BD77.7911D2F8-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 8 07:10:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07008 for ; Mon, 8 Dec 2003 07:10:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1727C58012C; Mon, 8 Dec 2003 06:11:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6DE30580023; Mon, 8 Dec 2003 06:11:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 36D4D580023 for ; Mon, 8 Dec 2003 06:10:05 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 1491C580017 for ; Mon, 8 Dec 2003 06:10:03 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB8CA1v07376 for ; Mon, 8 Dec 2003 14:10:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Dec 2003 14:10:00 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 14:09:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Re: network discovery & selection: problem definition Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C38C9@esebe023.ntc.nokia.com> Thread-Topic: [eap] Re: network discovery & selection: problem definition Thread-Index: AcO3WIz5fekrcMBCRgGXM7A2JtTKqQBFX9HgAUQt+RA= From: To: , Cc: X-OriginalArrivalTime: 08 Dec 2003 12:09:58.0690 (UTC) FILETIME=[3315B820:01C3BD84] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 8 Dec 2003 14:09:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Farid, I actually like Bernard's idea of including identity (credential) selection, since I don't think the assumption that the user's terminal will have only a single set of credentials is very realistic. Even if the terminal has only a single identity for Public Wireless LANs, private WLANs (corporate, home) are much more widely used. Fortunately, it seems that all the proposed solutions will at least partially solve this problem as well, so including it doesn't seem to complicate things very much. Other than that, I think your definition also captures the essential parts of the problem quite well. The most difficult thing seems to be going from discovery to selection. Just knowing which choices are available is probably enough for manual selection (and we certainly should support that as a fallback). However, I think that automatic selection is much more important, and to select which of the choices is=20 the "most appropriate", the terminal needs more information=20 than just realm names. o Some credentials (identities) may be preferred to others=20 (e.g. use private corporate WLAN if available, and =20 pay-for PWLAN only if outside office) o Use of an access network with direct connection to home=20 network may be preferred over using mediating networks. o Some mediating networks may be preferred to others, most=20 likely based on cost (but note that optimizing cost is not a=20 trivial problem, because the total cost may be a combination=20 of a fixed fee, per-minute, per-megabyte, volume discounts, etc.) o Some access networks may be preferred to others, based on e.g.=20 cost, bandwidth, quality of service, coverage, or value-added=20 services. o Preferences may come from the user, his or her employer (who's paying the bill), home network, or access network. It seems to me that one of the main differences between different approaches (discovering mediating networks with EAP or virtual APs, or pre-provisioned SSID phonebook) is what kind of "cost functions" they easily support for the automatic selection problem. For instance, implementing automatic selection that always selects an access network with direct connection to home network (if available) seems to be much easier with virtual APs and "SSID phonebook" methods than EAP-based advertisements.=20 Or to take a second example, considering costs in automatic=20 selection is probably difficult without an "SSID phonebook". I'm not saying that supporting everything is necessary, but it's at least good to know what trade-offs we're making, and what kind of automatic selection criteria we're supporting and not supporting. Best regards, Pasi > -----Original Message----- > From: Adrangi, Farid > Sent: Tuesday, December 02, 2003 5:08 AM > To: Bernard Aboba > Cc: eap@frascone.com > Subject: RE: [eap] Re: network discovery & selection: problem = definition >=20 > Hi Bernard, > I have slightly different way of breaking down the problem=20 > - maybe we are talking about the same thing and the differences > is in wording it! As the name implies, the problem has two=20 > aspects: discovery and selection so maybe it is easier > to understand the problem by describing the purpose of each > aspect. >=20 >=20 > Purpose of Network Discovery: > ---------------------------- > 1) Discover 802.11 Access Networks within a coverage area. > (Note, although our examples are 802.11, it is applicable to > any access network). >=20 > 2) Discover Mediating or Service Networks that a given=20 > 802.11 access network is affiliated with. (Note that POP=20 > is only know to the Access Network, but mediating networks=20 > are known to both Access Networks and home service network > because of romaing agreements.) >=20 >=20 > Purpose of Network Selection: > ---------------------------- > 1) Enable the WLAN client (manually or automatically) to select=20 > the most appropriate 802.11 Access Network to associate with for > a given "Network Identifier/credential" installed on the client's=20 > device. >=20 > 2) The home service network needs to enable a policy=20 > mechanism by which the WLAN client (manually or automatically)=20 > can influence the routing of AAA packets through the preferred=20 > Mediating Network to the WLAN client's home service network. =20 >=20 > Note: IMO, "Identifier Selection" is an indenpent problem by=20 > itself. >=20 > Best regards, > Farid _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 8 09:41:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10821 for ; Mon, 8 Dec 2003 09:41:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B0081580017; Mon, 8 Dec 2003 08:42:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A7368580023; Mon, 8 Dec 2003 08:42:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE1CC580023 for ; Mon, 8 Dec 2003 08:41:12 -0600 (CST) Received: from relay4.alcatel.be (alc245.alcatel.be [195.207.101.245]) by mail.frascone.com (Postfix) with ESMTP id E3416580017 for ; Mon, 8 Dec 2003 08:41:10 -0600 (CST) Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by relay4.alcatel.be (8.12.10/8.12.10) with ESMTP id hB8Ef9eA023536 for ; Mon, 8 Dec 2003 15:41:09 +0100 Received: from alcatel.be (bt0pxa [138.203.85.210]) by btm34m.sh.bel.alcatel.be (8.8.8p2+Sun/8.8.8/1.1) with ESMTP id PAA13352 for ; Mon, 8 Dec 2003 15:41:06 +0100 (MET) Message-ID: <3FD48D82.8D2B5B46@alcatel.be> From: nagi reddy jonnala Organization: Alcatel Telecom X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 08 Dec 2003 15:41:06 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I was going through this draft to find more discussion about network discovery and selection topic. So I ended up in this solution space issue :-) In a couple of places, the draft appears to make the assumption that the displayable message is terminated by a null character. Based on the assumption, It is also mentioned that Network Information MUST be placed after the null character. RFC-2284 disagrees with this. See the below text from RFC-2284, Section 3.1 - Identity. "This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." I guess the Option-1 of Delivery mechanism is completely ruled out. But then how can AP initiated EAP-Identity/Request message carries the network info? Regards Nagi. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 8 09:54:56 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11265 for ; Mon, 8 Dec 2003 09:54:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 7FFDA580017; Mon, 8 Dec 2003 08:55:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 31C74580023; Mon, 8 Dec 2003 08:55:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 612F3580023 for ; Mon, 8 Dec 2003 08:54:08 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 6A3B3580017 for ; Mon, 8 Dec 2003 08:54:06 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hB8FCNs09640; Mon, 8 Dec 2003 07:12:23 -0800 From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: farid.adrangi@intel.com, eap@frascone.com Subject: RE: [eap] Re: network discovery & selection: problem definition In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38C9@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C38C9@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 8 Dec 2003 07:12:23 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > I actually like Bernard's idea of including identity > (credential) selection, since I don't think the assumption that > the user's terminal will have only a single set of credentials > is very realistic. Even if the terminal has only a single > identity for Public Wireless LANs, private WLANs (corporate, > home) are much more widely used. It is also possible that a terminal will have different EAP identities/credentials depending on the media (PPP, 802.11, etc.). > Fortunately, it seems that all the proposed solutions will at > least partially solve this problem as well, so including it > doesn't seem to complicate things very much. There are some issues in identity/credential selection that are not covered by the proposals. For example, see: http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-04.txt > The most difficult thing seems to be going from discovery to > selection. Just knowing which choices are available is probably > enough for manual selection (and we certainly should support > that as a fallback). Yes. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 8 10:42:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15250 for ; Mon, 8 Dec 2003 10:42:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 970DB58012C; Mon, 8 Dec 2003 09:43:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41575580023; Mon, 8 Dec 2003 09:43:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D790F580017 for ; Mon, 8 Dec 2003 09:42:23 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 83741580023 for ; Mon, 8 Dec 2003 09:42:21 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hB8FgK818054 for ; Mon, 8 Dec 2003 17:42:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 8 Dec 2003 17:42:20 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 8 Dec 2003 17:42:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 204: Peer-to-peer operation Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122337@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 204: Peer-to-peer operation Thread-Index: AcO52VfuoqM4xrS+RuSKzmmFWNM4bQDxr7YQ From: To: Cc: , X-OriginalArrivalTime: 08 Dec 2003 15:42:19.0755 (UTC) FILETIME=[DD59F3B0:01C3BDA1] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 8 Dec 2003 17:42:19 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Jim Burns wrote: > > Our original assumption in the design of the .1X/EAP state machines > was that EAP was a functional entity that could have multiple > instantiations, one for each state machine. So, the current .1X > design delivers the EAP frame once to each EAP machine (which looks > like two deliveries of the same frame if there is a single EAP > mux/demux layer). >=20 > The .1X transport does not filter the frames as EAP peer frames and > EAP authenticator frames because there is no indication in the EAPOL > header of the type of EAP frame being carried and their is no logic > in .1X which is related to the EAP header. >=20 > So, we need to answer the question: Is their a single EAP layer > above the lower layer transport that does mux/demux? Does the EAP > layer assume there is a single channel to the lower layer transport > or one for each of its EAP's state machine? The current versions of EAP state machines don't mind if all EAP frames are delivered to both state machines. The EAP Peer state machine ignores all EAP Responses (by setting eapNoResp to TRUE),=20 and EAP Authenticator state machine ignores EAP Requests, Successes and Failure (by setting eapNoReq to TRUE). Adding a "EAP demultiplexing layer" somewhere might be more elegant than delivering the frames twice, but personally I could=20 live with the current approach (especially since these state=20 machines specify only externally visible behavior, not=20 implementation). Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 8 19:02:58 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14366 for ; Mon, 8 Dec 2003 19:02:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1956580128; Mon, 8 Dec 2003 18:03:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 47942580129; Mon, 8 Dec 2003 18:03:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FFF4580128 for ; Mon, 8 Dec 2003 18:02:09 -0600 (CST) Received: from noxmail.sandelman.ottawa.on.ca (oetest.freeswan.org [205.150.200.166]) by mail.frascone.com (Postfix) with ESMTP id 3D25B580023 for ; Mon, 8 Dec 2003 18:02:05 -0600 (CST) Received: from sandelman.ottawa.on.ca (gpo.tor.istop.com [66.11.164.149]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id hB901mq28340 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 8 Dec 2003 19:01:57 -0500 (EST) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB8MYCpL000799 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 8 Dec 2003 17:34:13 -0500 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id hB8MYBsQ000795 for ; Mon, 8 Dec 2003 17:34:12 -0500 To: eap@frascone.com Subject: Re: [eap] Re: network discovery & selection: problem definition In-reply-to: Your message of "Mon, 08 Dec 2003 14:09:57 +0200." <052E0C61B69C3741AFA5FE88ACC775A6010C38C9@esebe023.ntc.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Message-ID: <794.1070922851@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 08 Dec 2003 17:34:11 -0500 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) -----BEGIN PGP SIGNED MESSAGE----- So, I have another network selection problem/challenge. Feel free to tell me I'm out of scope, but don't ask what I'm smoking, because you can't have any :-) It involves interactions between layers. I would like to be able to move around from place to place, and have things "just work". (vs how things went at the last IETF...) At one colleague's office there is wireless. It happens to be a non-WEP (we use IPsec, wavesec.org), with an unannounced ESSID. The DHCP will give out public IP addresses, and also include other options that I want to recognize. The next office over has a totally open network, NAT'ed. I won't want to be on that network. Naively, if you don't do the right thing, you wind up on the wrong network, because the thing that knows what network I want to be one is the DHCP, while the 802.11 stuff has already happened. Meanwhile, at a different location, I want to recognize that I'm being offered a for-pay EAP system. So, ideally, I'd like to have only one system. I'd like to have EAP, DHCP and PPPoE discovery state machines all integrated together. Frankly, I rather wish that we did EAP and PPPoE inside of DHCP. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP9T8YYqHRg3pndX9AQEczAP/bt69Jk3WWYewaVJWoptPbwTqYWva0mgp 2goECNPBPaE5PLTkXQkU2L1tB167ERZga+hw/MxWwRjkggkMd0GnNdpGZs0dSSWd K8ANyD83zOoR66MsvG0o5bz2nemcUrMmtMYyDTT4BF9R+H5XLab4zFDxaA87Tkz4 6pMYZSl7HJg= =mGLn -----END PGP SIGNATURE----- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 06:50:55 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23187 for ; Tue, 9 Dec 2003 06:50:53 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D2CA3580126; Tue, 9 Dec 2003 05:51:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F1D7E580017; Tue, 9 Dec 2003 05:51:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D113A580017 for ; Tue, 9 Dec 2003 05:50:54 -0600 (CST) Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by mail.frascone.com (Postfix) with ESMTP id 9D091580014 for ; Tue, 9 Dec 2003 05:50:52 -0600 (CST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB9Bofm07660; Tue, 9 Dec 2003 11:50:42 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 11:50:42 -0000 Message-ID: From: "Mark Watson" To: "'nagi reddy jonnala'" , "'eap@frascone.com'" Subject: RE: [eap] Issue with draft-adrangi-eap-network-discovery-and-sele ction-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE4A.AB87C548" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 9 Dec 2003 11:50:41 -0000 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BE4A.AB87C548 Content-Type: text/plain Nagi, Although it is very unclear when stated out of context, I believe the field which MUST NOT be null terminated is the Identity provided in the *response*. I understand that the displayable message in the *Request* is null terminated. It is after this displayable message in the request that we have suggested placing the network advertisement information. I believe there are already APs on the market which place some proprietary information in this space. Regards...Mark -----Original Message----- From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be] Sent: 08 December 2003 14:41 To: eap@frascone.com Subject: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt I was going through this draft to find more discussion about network discovery and selection topic. So I ended up in this solution space issue :-) In a couple of places, the draft appears to make the assumption that the displayable message is terminated by a null character. Based on the assumption, It is also mentioned that Network Information MUST be placed after the null character. RFC-2284 disagrees with this. See the below text from RFC-2284, Section 3.1 - Identity. "This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." I guess the Option-1 of Delivery mechanism is completely ruled out. But then how can AP initiated EAP-Identity/Request message carries the network info? Regards Nagi. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------_=_NextPart_001_01C3BE4A.AB87C548 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [eap] Issue with = draft-adrangi-eap-network-discovery-and-selection-00.txt

Nagi,

Although it is very unclear when stated out of = context, I believe the field which MUST NOT be null terminated is the = Identity provided in the *response*. I understand that the displayable = message in the *Request* is null terminated. It is after this = displayable message in the request that we have suggested placing the = network advertisement information. I believe there are already APs on = the market which place some proprietary information in this = space.

 
Regards...Mark

-----Original Message-----
From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@= alcatel.be]
Sent: 08 December 2003 14:41
To: eap@frascone.com
Subject: [eap] Issue with = draft-adrangi-eap-network-discovery-and-selection-00.txt


I was going through this draft to find more = discussion about network discovery and selection topic.  So I = ended up in this solution space issue :-)

In a couple of places, the draft appears to make the = assumption that the displayable message is terminated by a null = character.  Based on the assumption, It is also mentioned that = Network Information MUST be placed after the null character.

RFC-2284 disagrees with this. See the below text from = RFC-2284, Section 3.1 - Identity.

     "This field MAY contain = a displayable message in the Request.  The
      Response uses this = field to return the Identity.  If the Identity
      is unknown, this = field should be zero bytes in length.  The field
      MUST NOT be null = terminated.  The length of this field is derived
      from the Length field = of the Request/Response packet and hence a
      null is not = required."

I guess the Option-1 of  Delivery mechanism is = completely ruled out. But then how can AP initiated = EAP-Identity/Request message carries the network info?

Regards
Nagi.


_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap

------_=_NextPart_001_01C3BE4A.AB87C548-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 08:41:15 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25439 for ; Tue, 9 Dec 2003 08:41:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 20BE65801A3; Tue, 9 Dec 2003 07:41:22 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3DEB95801A9; Tue, 9 Dec 2003 07:41:12 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CD77C5801A7 for ; Tue, 9 Dec 2003 07:40:58 -0600 (CST) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by mail.frascone.com (Postfix) with ESMTP id 7BDA75801A4 for ; Tue, 9 Dec 2003 07:40:48 -0600 (CST) Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id hB9Bgbr2007021; Tue, 9 Dec 2003 12:42:37 +0100 Received: from alcatel.be (bt0pxa [138.203.85.210]) by btm34m.sh.bel.alcatel.be (8.8.8p2+Sun/8.8.8/1.1) with ESMTP id OAA01972; Tue, 9 Dec 2003 14:40:40 +0100 (MET) Message-ID: <3FD5D0D8.3B46EAA4@alcatel.be> From: nagi reddy jonnala Organization: Alcatel Telecom X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Watson Cc: "'eap@frascone.com'" Subject: Re: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt References: Content-Type: multipart/alternative; boundary="------------3FEC6CC21601CD964A212D09" X-Scanned-By: MIMEDefang 2.37 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 14:40:40 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --------------3FEC6CC21601CD964A212D09 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark, I believe it is applicable to *Identity request* as well. See the text below. "The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." I guess the intention was to recommend the use of length fileld rather than NULL in both Request and Response. Regards Nagi. PS : I undetstand that RFC-2284bis-07 also makes the same assumption. I think it is better to start a new thread on this issue. Mark Watson wrote: > > > Nagi, > > Although it is very unclear when stated out of context, I believe the > field which MUST NOT be null terminated is the Identity provided in > the *response*. I understand that the displayable message in the > *Request* is null terminated. It is after this displayable message in > the request that we have suggested placing the network advertisement > information. I believe there are already APs on the market which place > some proprietary information in this space. > > > Regards...Mark > > -----Original Message----- > From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be] > Sent: 08 December 2003 14:41 > To: eap@frascone.com > Subject: [eap] Issue with > draft-adrangi-eap-network-discovery-and-selection-00.txt > > I was going through this draft to find more discussion about network > discovery and selection topic. So I ended up in this solution space > issue :-) > > In a couple of places, the draft appears to make the assumption that > the displayable message is terminated by a null character. Based on > the assumption, It is also mentioned that Network Information MUST be > placed after the null character. > > RFC-2284 disagrees with this. See the below text from RFC-2284, > Section 3.1 - Identity. > > "This field MAY contain a displayable message in the Request. > The > Response uses this field to return the Identity. If the > Identity > is unknown, this field should be zero bytes in length. The > field > MUST NOT be null terminated. The length of this field is > derived > from the Length field of the Request/Response packet and hence a > > null is not required." > > I guess the Option-1 of Delivery mechanism is completely ruled out. > But then how can AP initiated EAP-Identity/Request message carries the > network info? > > Regards > Nagi. > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap --------------3FEC6CC21601CD964A212D09 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Mark,

I believe it is applicable to *Identity request* as well.  See the text below.

"The length of this field is derived  from the Length field of the Request/Response packet and hence a null is not required."

I guess the intention was to recommend the use of length fileld rather than NULL in both Request and Response.

Regards
Nagi.

PS : I undetstand that RFC-2284bis-07 also makes the same assumption. I think it is better to start a new thread on this issue.
 

Mark Watson wrote:

 

Nagi,

Although it is very unclear when stated out of context, I believe the field which MUST NOT be null terminated is the Identity provided in the *response*. I understand that the displayable message in the *Request* is null terminated. It is after this displayable message in the request that we have suggested placing the network advertisement information. I believe there are already APs on the market which place some proprietary information in this space.
 

Regards...Mark

-----Original Message-----
From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be]
Sent: 08 December 2003 14:41
To: eap@frascone.com
Subject: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt

I was going through this draft to find more discussion about network discovery and selection topic.  So I ended up in this solution space issue :-)

In a couple of places, the draft appears to make the assumption that the displayable message is terminated by a null character.  Based on the assumption, It is also mentioned that Network Information MUST be placed after the null character.

RFC-2284 disagrees with this. See the below text from RFC-2284, Section 3.1 - Identity.

     "This field MAY contain a displayable message in the Request.  The
      Response uses this field to return the Identity.  If the Identity
      is unknown, this field should be zero bytes in length.  The field
      MUST NOT be null terminated.  The length of this field is derived
      from the Length field of the Request/Response packet and hence a
      null is not required."

I guess the Option-1 of  Delivery mechanism is completely ruled out. But then how can AP initiated EAP-Identity/Request message carries the network info?

Regards
Nagi.

_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap

--------------3FEC6CC21601CD964A212D09-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 08:57:05 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25971 for ; Tue, 9 Dec 2003 08:57:04 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 01D415801AC; Tue, 9 Dec 2003 07:57:18 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E6B745801B1; Tue, 9 Dec 2003 07:57:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 915855801B0 for ; Tue, 9 Dec 2003 07:56:16 -0600 (CST) Received: from relay4.alcatel.be (alc245.alcatel.be [195.207.101.245]) by mail.frascone.com (Postfix) with ESMTP id 0E4665801AB for ; Tue, 9 Dec 2003 07:56:10 -0600 (CST) Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by relay4.alcatel.be (8.12.10/8.12.10) with ESMTP id hB9Du4eA030650 for ; Tue, 9 Dec 2003 14:56:04 +0100 Received: from alcatel.be (bt0pxa [138.203.85.210]) by btm34m.sh.bel.alcatel.be (8.8.8p2+Sun/8.8.8/1.1) with ESMTP id OAA02581 for ; Tue, 9 Dec 2003 14:56:03 +0100 (MET) Message-ID: <3FD5D473.476E605D@alcatel.be> From: nagi reddy jonnala Organization: Alcatel Telecom X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: eap@frascone.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] RFC-2284bis-07 Identity request Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 14:56:03 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit I understand that RFC2284bis-07 Section 5.1 conflicts with the RFC2284 Section 3.1 See the text from 2284-bis. " This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet. " See the text from 2284 Section 3.1 - Identity Type-Data field. "This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." Particularly, the last sentence (of 2284) means that the Request cannot have a NULL. I guess the intention was to recommend the use of length rather than a NULL. Though I don't have any objections to use the space after NULL, I would like to know if that causes any issues. At the same time, I propose to explicitly mention the same thing in the 2284-bis. Regards Nagi. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 09:03:14 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26150 for ; Tue, 9 Dec 2003 09:03:07 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EFF7358013A; Tue, 9 Dec 2003 08:03:18 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B592E580128; Tue, 9 Dec 2003 08:03:09 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DEF5E5801CF for ; Tue, 9 Dec 2003 08:02:42 -0600 (CST) Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by mail.frascone.com (Postfix) with ESMTP id 754FF5801CC for ; Tue, 9 Dec 2003 08:02:36 -0600 (CST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hB9E2Fm17816; Tue, 9 Dec 2003 14:02:15 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Dec 2003 14:02:15 -0000 Message-ID: From: "Mark Watson" To: "'nagi reddy jonnala'" Cc: "'eap@frascone.com'" Subject: RE: [eap] Issue with draft-adrangi-eap-network-discovery-and-sel ection-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3BE5D.07437244" X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 9 Dec 2003 14:02:05 -0000 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3BE5D.07437244 Content-Type: text/plain Well, the text is ambiguous, so it is hard to make definitive statements about the intention. At least rfc2284bis-07 now states explicitly in the description of the Type-Data field in an EAP identity request/response: " This field MAY contain a displayable message in the Request, containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where the Request contains a null, only the portion of the field prior to the null is displayed. If the Identity is unknown, the Identity Response field should be zero bytes in length. The Identity Response field MUST NOT be null terminated. In all cases, the length of the Type-Data field is derived from the Length field of the Request/Response packet. Regards, Mark -----Original Message----- From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be] Sent: 09 December 2003 13:41 To: Watson, Mark [MOP:EP10:EXCH] Cc: 'eap@frascone.com' Subject: Re: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt Mark, I believe it is applicable to *Identity request* as well. See the text below. "The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." I guess the intention was to recommend the use of length fileld rather than NULL in both Request and Response. Regards Nagi. PS : I undetstand that RFC-2284bis-07 also makes the same assumption. I think it is better to start a new thread on this issue. Mark Watson wrote: Nagi, Although it is very unclear when stated out of context, I believe the field which MUST NOT be null terminated is the Identity provided in the *response*. I understand that the displayable message in the *Request* is null terminated. It is after this displayable message in the request that we have suggested placing the network advertisement information. I believe there are already APs on the market which place some proprietary information in this space. Regards...Mark -----Original Message----- From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be ] Sent: 08 December 2003 14:41 To: eap@frascone.com Subject: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt I was going through this draft to find more discussion about network discovery and selection topic. So I ended up in this solution space issue :-) In a couple of places, the draft appears to make the assumption that the displayable message is terminated by a null character. Based on the assumption, It is also mentioned that Network Information MUST be placed after the null character. RFC-2284 disagrees with this. See the below text from RFC-2284, Section 3.1 - Identity. "This field MAY contain a displayable message in the Request. The Response uses this field to return the Identity. If the Identity is unknown, this field should be zero bytes in length. The field MUST NOT be null terminated. The length of this field is derived from the Length field of the Request/Response packet and hence a null is not required." I guess the Option-1 of Delivery mechanism is completely ruled out. But then how can AP initiated EAP-Identity/Request message carries the network info? Regards Nagi. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap ------_=_NextPart_001_01C3BE5D.07437244 Content-Type: text/html Message
Well, the text is ambiguous, so it is hard to make definitive statements about the intention. At least rfc2284bis-07 now states explicitly in the description of the Type-Data field in an EAP identity request/response:
 
"     This field MAY contain a displayable message in the Request,
      containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
      the Request contains a null, only the portion of the field prior
      to the null is displayed.  If the Identity is unknown, the
      Identity Response field should be zero bytes in length.  The
      Identity Response field MUST NOT be null terminated.  In all
      cases, the length of the Type-Data field is derived from the
      Length field of the Request/Response packet.
 
Regards,
 
Mark
-----Original Message-----
From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be]
Sent: 09 December 2003 13:41
To: Watson, Mark [MOP:EP10:EXCH]
Cc: 'eap@frascone.com'
Subject: Re: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt

Mark,

I believe it is applicable to *Identity request* as well.  See the text below.

"The length of this field is derived  from the Length field of the Request/Response packet and hence a null is not required."

I guess the intention was to recommend the use of length fileld rather than NULL in both Request and Response.

Regards
Nagi.

PS : I undetstand that RFC-2284bis-07 also makes the same assumption. I think it is better to start a new thread on this issue.
 

Mark Watson wrote:

 

Nagi,

Although it is very unclear when stated out of context, I believe the field which MUST NOT be null terminated is the Identity provided in the *response*. I understand that the displayable message in the *Request* is null terminated. It is after this displayable message in the request that we have suggested placing the network advertisement information. I believe there are already APs on the market which place some proprietary information in this space.
 

Regards...Mark

-----Original Message-----
From: nagi reddy jonnala [mailto:Nagi_Reddy.Jonnala@alcatel.be]
Sent: 08 December 2003 14:41
To: eap@frascone.com
Subject: [eap] Issue with draft-adrangi-eap-network-discovery-and-selection-00.txt

I was going through this draft to find more discussion about network discovery and selection topic.  So I ended up in this solution space issue :-)

In a couple of places, the draft appears to make the assumption that the displayable message is terminated by a null character.  Based on the assumption, It is also mentioned that Network Information MUST be placed after the null character.

RFC-2284 disagrees with this. See the below text from RFC-2284, Section 3.1 - Identity.

     "This field MAY contain a displayable message in the Request.  The
      Response uses this field to return the Identity.  If the Identity
      is unknown, this field should be zero bytes in length.  The field
      MUST NOT be null terminated.  The length of this field is derived
      from the Length field of the Request/Response packet and hence a
      null is not required."

I guess the Option-1 of  Delivery mechanism is completely ruled out. But then how can AP initiated EAP-Identity/Request message carries the network info?

Regards
Nagi.

_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap

------_=_NextPart_001_01C3BE5D.07437244-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 09:37:54 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26987 for ; Tue, 9 Dec 2003 09:37:53 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 331AE580023; Tue, 9 Dec 2003 08:38:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A4CAF580126; Tue, 9 Dec 2003 08:38:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1F43A580126 for ; Tue, 9 Dec 2003 08:37:36 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id A0F80580023 for ; Tue, 9 Dec 2003 08:37:34 -0600 (CST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id DB7406A902; Tue, 9 Dec 2003 16:37:32 +0200 (EET) Message-ID: <3FD5DD13.2040109@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nagi reddy jonnala Cc: eap@frascone.com Subject: Re: [eap] RFC-2284bis-07 Identity request References: <3FD5D473.476E605D@alcatel.be> In-Reply-To: <3FD5D473.476E605D@alcatel.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 16:32:51 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit We discussed this in issue 142, see http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20142 and the mail archives. The working group agreed at that time, do we have some new information at this time that would make us reconsider this? I'm not sure there is. Having said that, I think Appendix A of RFC 2284bis is misleading because it just talks about the ISO character set clarifications in 5.1 and 5.2, but does not mention this issue. Perhaps we should add the following text to Appendix A, right after the item that talks about 5.1: o The null character is forbidden in the Type-Data field of an Identity Response message, as it is in RFC 2284. But the this rule has been relaxed for Identity Requests, and it is now required that if the Type-Data field of an Identity Request contains a null character, only the part before the null is displayed. Would this work for you? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 09:52:59 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27352 for ; Tue, 9 Dec 2003 09:52:55 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id CFD605801A8; Tue, 9 Dec 2003 08:53:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A584E580140; Tue, 9 Dec 2003 08:53:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 91D1C580140 for ; Tue, 9 Dec 2003 08:52:27 -0600 (CST) Received: from bt0g2p.god.bel.alcatel.be (alc250.alcatel.be [195.207.101.250]) by mail.frascone.com (Postfix) with ESMTP id E53A458013B for ; Tue, 9 Dec 2003 08:52:25 -0600 (CST) Received: from btm34m.sh.bel.alcatel.be (btm34m.sh.bel.alcatel.be [138.203.192.124]) by bt0g2p.god.bel.alcatel.be (8.12.10/8.12.10) with ESMTP id hB9CsEr2015860; Tue, 9 Dec 2003 13:54:14 +0100 Received: from alcatel.be (bt0pxa [138.203.85.210]) by btm34m.sh.bel.alcatel.be (8.8.8p2+Sun/8.8.8/1.1) with ESMTP id PAA05369; Tue, 9 Dec 2003 15:52:21 +0100 (MET) Message-ID: <3FD5E1A5.E984CB04@alcatel.be> From: nagi reddy jonnala Organization: Alcatel Telecom X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net Cc: eap@frascone.com Subject: Re: [eap] RFC-2284bis-07 Identity request References: <3FD5D473.476E605D@alcatel.be> <3FD5DD13.2040109@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.37 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 09 Dec 2003 15:52:21 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Jari, Yes, it is perfect if you add the text to Appendix A. Thanks Nagi Jari Arkko wrote: > We discussed this in issue 142, see > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20142 > > and the mail archives. The working group agreed at that time, > do we have some new information at this time that would make > us reconsider this? I'm not sure there is. > > Having said that, I think Appendix A of RFC 2284bis is misleading > because it just talks about the ISO character set clarifications > in 5.1 and 5.2, but does not mention this issue. Perhaps we should > add the following text to Appendix A, right after the item that > talks about 5.1: > > o The null character is forbidden in the Type-Data field of an > Identity Response message, as it is in RFC 2284. But the this rule > has been relaxed for Identity Requests, and it is now required > that if the Type-Data field of an Identity Request contains a > null character, only the part before the null is displayed. > > Would this work for you? > > --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 9 13:54:57 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07662 for ; Tue, 9 Dec 2003 13:54:56 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7486580135; Tue, 9 Dec 2003 12:55:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 03393580063; Tue, 9 Dec 2003 12:55:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E38E7580063 for ; Tue, 9 Dec 2003 12:54:17 -0600 (CST) Received: from mailgw.local.ipunplugged.com (unknown [213.80.52.78]) by mail.frascone.com (Postfix) with ESMTP id E87FB580016 for ; Tue, 9 Dec 2003 12:54:15 -0600 (CST) Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hB9In3HW017535; Tue, 9 Dec 2003 19:49:03 +0100 From: Henrik Levkowetz To: nagi reddy jonnala Cc: jari.arkko@piuha.net, eap@frascone.com Subject: Re: [eap] RFC-2284bis-07 Identity request Message-Id: <20031209194856.076e76ac.henrik@levkowetz.com> In-Reply-To: <3FD5E1A5.E984CB04@alcatel.be> References: <3FD5D473.476E605D@alcatel.be> <3FD5DD13.2040109@piuha.net> <3FD5E1A5.E984CB04@alcatel.be> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__9_Dec_2003_19_48_57_+0100_UcPo.eM0wbJHKoU9" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 9 Dec 2003 19:48:56 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) --Signature=_Tue__9_Dec_2003_19_48_57_+0100_UcPo.eM0wbJHKoU9 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Jari, Nagi, A version of the document (-08.a) updated according to the text below is available at http://ietf.levkowetz.com/drafts/eap/rfc2284bis/. Jari, I guess that formally we'll supply this as an RFC editor note during the Author's 48 hours? Regards, Henrik On Tuesday, 9 Dec 2003, nagi wrote: > Jari, > > Yes, it is perfect if you add the text to Appendix A. > > Thanks > Nagi > > > > Jari Arkko wrote: > > > We discussed this in issue 142, see > > > > http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%20142 > > > > and the mail archives. The working group agreed at that time, > > do we have some new information at this time that would make > > us reconsider this? I'm not sure there is. > > > > Having said that, I think Appendix A of RFC 2284bis is misleading > > because it just talks about the ISO character set clarifications > > in 5.1 and 5.2, but does not mention this issue. Perhaps we should > > add the following text to Appendix A, right after the item that > > talks about 5.1: > > > > o The null character is forbidden in the Type-Data field of an > > Identity Response message, as it is in RFC 2284. But the this rule > > has been relaxed for Identity Requests, and it is now required > > that if the Type-Data field of an Identity Request contains a > > null character, only the part before the null is displayed. > > > > Would this work for you? > > > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap --Signature=_Tue__9_Dec_2003_19_48_57_+0100_UcPo.eM0wbJHKoU9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/1hkgeVhrtTJkXCMRArkAAJ9bsRMyvsM5eAjNkduxR9qVe7/4WQCg4xui srCSmQCweEy7geLWQ6aGv0s= =B9jV -----END PGP SIGNATURE----- --Signature=_Tue__9_Dec_2003_19_48_57_+0100_UcPo.eM0wbJHKoU9-- _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 10 20:18:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29622 for ; Wed, 10 Dec 2003 20:18:10 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F0A9D580016; Wed, 10 Dec 2003 19:18:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 92062580017; Wed, 10 Dec 2003 19:18:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3B856580017 for ; Wed, 10 Dec 2003 19:17:40 -0600 (CST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id 3E30C580016 for ; Wed, 10 Dec 2003 19:17:38 -0600 (CST) Subject: Re: [eap] network discovery & selection: problem definition From: Alper Yegin To: , "eap@frascone.com" , "Adrangi, Farid" , Pasi Eronen Message-ID: In-Reply-To: <3FC780BF.1020808@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 10 Dec 2003 17:18:57 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > The primary network discovery and selection issue > is routing within the AAA infrastructure, giving > access to the user from the right home AAA and via > the right AAA proxies. I'd say network selection also impacts "data traffic routing", which should not have to be hard-bound to the AAA routing (or, my home AAA server). For example, I might want to select ISPx among several, and let it charge my alper@visa.com account. ... > > However, if the access network supports two different > intermediaries, it becomes necessary to figure out > which intermediary handles the domain given in a NAI. Sure this is important. If we are strictly talking about how AAA routing takes place (not data traffic routing) then I'd ask if this is something that the client hosts should be dealing with? Maybe this AAA intermediary selection is not for the hosts but for the access networks to deal with. > o For commercial reasons, intermediaries want > to participate the AAA transaction. > > Question: Is there a need for someone else than > the access network to control the routing to go > via a special intermediary? This is not very > clear to me. Yes, this is what I'm questioning as well. > > During the discussion of solutions for these problems, > it has become apparent that there are some additional > constraints that may have to be placed on solutions. > Some of the possible constraints are listed below: > > o Solution can be adopted for the whole network > without requiring changes to the largest base > of installed devices -- access points and > clients. Good objective. But we should also identify what we could do if we didn't have this constraint. This is useful at least for future updates of the relevant protocols. Alper _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Dec 11 02:56:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21682 for ; Thu, 11 Dec 2003 02:56:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 89DF4580126; Thu, 11 Dec 2003 01:56:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3E434580017; Thu, 11 Dec 2003 01:56:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9DFA6580017 for ; Thu, 11 Dec 2003 01:55:28 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 28BA7580016 for ; Thu, 11 Dec 2003 01:55:27 -0600 (CST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 67BB16A904; Thu, 11 Dec 2003 09:55:25 +0200 (EET) Message-ID: <3FD822C3.2030107@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Cc: "eap@frascone.com" Subject: Re: [eap] network discovery & selection: problem definition References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Dec 2003 09:54:43 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Alper Yegin wrote: >>The primary network discovery and selection issue >>is routing within the AAA infrastructure, giving >>access to the user from the right home AAA and via >>the right AAA proxies. > > > I'd say network selection also impacts "data traffic routing", > which should not have to be hard-bound to the AAA routing (or, my home AAA Yes, this is a good point, thanks for bringing it up! Here's a question for you: do you expect some mechanism which allows you to control data traffic routing, or is the requirement simply that it is not hard-bound to the AAA routing? Currently, there is no user-level way to control routing (and probably shouldn't be). But access, intermediate, and home networks can control routing to an extent e.g. through mandatory tunneling. > server). For example, I might want to select ISPx among several, and let > it charge my alper@visa.com account. Hmm... wouldn't visa.com then be your home network, and the selected ISP just an access (or intermediate) network? --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Dec 11 13:45:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13570 for ; Thu, 11 Dec 2003 13:45:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0D686580126; Thu, 11 Dec 2003 12:45:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2D308580017; Thu, 11 Dec 2003 12:45:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 85F19580017 for ; Thu, 11 Dec 2003 12:44:13 -0600 (CST) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by mail.frascone.com (Postfix) with ESMTP id CA696580016 for ; Thu, 11 Dec 2003 12:44:11 -0600 (CST) Subject: Re: [eap] network discovery & selection: problem definition From: Alper Yegin To: Cc: "eap@frascone.com" Message-ID: In-Reply-To: <3FD822C3.2030107@piuha.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 11 Dec 2003 10:45:32 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit >> I'd say network selection also impacts "data traffic routing", >> which should not have to be hard-bound to the AAA routing (or, my home AAA > > Yes, this is a good point, thanks for bringing it up! Here's a > question for you: do you expect some mechanism which allows you > to control data traffic routing, I don't expect the host to control end2end routing of its data packets. But its ISP selection will determine how the packets are routed eventually. [I'm thinking of the scenario where a NAP - network access provider - is providing service for multiple ISPs] > or is the requirement simply that > it is not hard-bound to the AAA routing? Currently, there is no > user-level way to control routing (and probably shouldn't be). But > access, intermediate, and home networks can control routing to > an extent e.g. through mandatory tunneling. > >> server). For example, I might want to select ISPx among several, and let >> it charge my alper@visa.com account. > > Hmm... wouldn't visa.com then be your home network, and the selected > ISP just an access (or intermediate) network? Yes, "visa.com" would be my home network in the AAA sense, but not in IP routing sense (my data packets don't have to go through the network domain where AAA servers reside). Alper > > --Jari > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 07:55:19 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06031 for ; Mon, 15 Dec 2003 07:55:15 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id AE738580027; Mon, 15 Dec 2003 06:55:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FFC158000B; Mon, 15 Dec 2003 06:55:07 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 345D058000B for ; Mon, 15 Dec 2003 06:54:42 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 21A5F580009 for ; Mon, 15 Dec 2003 06:54:25 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFCsLn24465 for ; Mon, 15 Dec 2003 14:54:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 14:54:20 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 14:54:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C38D6@esebe023.ntc.nokia.com> Thread-Topic: [eap] [Issue] Comments on EAP-Peer state machine Thread-Index: AcOvrUM5EXtCt0jAQn+tIDsW+jubDATXRpiw From: To: , X-OriginalArrivalTime: 15 Dec 2003 12:54:19.0671 (UTC) FILETIME=[8E0B7270:01C3C30A] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Dec 2003 14:54:18 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Thanks for your comments, Joe! (and sorry it took=20 me so long to respond). - I think items 1 and 2 are addressed in proposed resolution=20 of issue 198: = http://mail.frascone.com/pipermail/public/eap/2003-November/001852.html - Item 3 is a bit more complicated.=20 Integrity check is currently a separate procedure to show that=20 when a packet is silently discarded, methodState and decision=20 (and other state) remain unchanged. You're right in that a=20 method can produce an error for invalid packets instead... Maybe it would be better if we rename m.integrityCheck() to=20 m.check() and "intCheck" to "discard"? (and change transition=20 "!intCheck" to "discard") =20 Combining methodState and decision to a single variable is=20 certainly possible, but four different states (plus one=20 indication for IGNORE) are not enough: there are seven different combinations. The reason we originally split it was to make the=20 transitions to SUCCESS and FAILURE states a bit more compact=20 (they're quite complex anyway, but become totally unreadable=20 if the variables are combined...).=20 One thing we could do is get rid of the "x =3D FOO | BAR" notation, and instead make m.process() set the variables, and change METHOD pseudocode to something like this: discard =3D m.check(eapReqData) if (!discard) { (methodState,decision,allowNotifications) =3D=20 m.process(eapReqData) /* methodState is CONT, MAY_CONT, or DONE */=20 /* decision is FAIL, COND_SUCC or UNCOND_SUCC */ eapRespData =3D m.buildResp(reqId) if (m.isKeyAvailable()) eapKeyData =3D m.getKey() } Would this be better? - Item 4: I think your suggestion (reset timer in INITIALIZE=20 and SEND_RESPONSE) is ok. - Item 5: it might check (reqId !=3D lastReqId) (not "=3D=3D"),=20 but I don't think this is necessary, since Success/Failure=20 are never retransmitted. Best regards, Pasi > -----Original Message----- > From: eap-admin@frascone.com=20 > [mailto:eap-admin@frascone.com]On Behalf Of > ext Joseph Salowey > Sent: Thursday, November 20, 2003 11:27 PM > To: eap@frascone.com > Subject: [eap] [Issue] Comments on EAP-Peer state machine >=20 >=20 > Submitter name: Joe Salowey > Submitter email address: jsalowey@cisco.com > Date first submitted: 11/20/2003 > Reference:=20 > Document: State Machine > Comment type: 'E'ditorial > Priority: '1' Should fix=20 > Section: 4.x > Rationale/Explanation of issue: >=20 > 1. portEnabled >=20 > portEnabled seems very .1x/PPP specific. EAP is being used in cases > such as IKE and PANA where this concept may a bit more abstract. > Perhaps we can change the name of the variable and/or expand its > definition to include other cases. =20 >=20 > Suggestion: > Perhaps "indicates that a lower layer communcation channel has been > established". >=20 > 2. EAPTunneled >=20 > The behavior inside tunnels needs to be defined by the tunnel as there > are severl ways you can handle EAP within a tunnel. I think=20 > we decided > to remove this variable at the meeting, but I want to mae=20 > sure we track > it. In PEAPv2 we started out with a behavior similar to what is > described in the state machine, but in order to make sure=20 > the policy on > the peer and authenticator stayed in sync we introduced itermediate > result indicators which I think change the state machine a little. >=20 > Suggestion: > Remove variable. We could explore this in an apppendix or a separate > document. >=20 > 3. Interface to method >=20 > The interface to the method seems too complicated. =20 >=20 > First I don't think that intCheck should be a different process. > Integrity checking is done as part of the method processing. Also > methods aren't required to ingore packets, some methods with=20 > ignore some > problems and return errors on others. I think this behavior should be > incorporated into m.process. >=20 > On a separate but related note it seems that the method state and > decision is very complex. I don't really see the need for the > independent methodState and decision variables. M.process() should > return one of serverl possible results: IGNORE, CONTINUE,=20 > COND_SUCCESS, > SUCCESS, FAILURE. MethodState should be able to take on CONTINUE, > COND_SUCCESS, SUCCESS, FAILURE. I don't think a separate decision > variable is necessary. >=20 > Suggestion >=20 > In method: >=20 > methodResult =3D m.process(eapRespData) > If (methodResult !=3D IGNORE) > { > methodState =3D methodResult > allowNotifications =3D TRUE|FALSE > eapRespData =3D m.buildResponse(reqID) > if (methodState =3D=3D SUCCESS || methodState =3D=3D COND_SUCCESS) > { > eapKeyData =3D NONE|m.getKey() > } > } >=20 > Transition to discard: (methodResult =3D=3D IGNORE) > Combine methodState and decision transition conditions >=20 > 4. Idle timer >=20 > It seems that there is a problem with the idle timer. It would be > possible for the peer to never time out if it keeps on=20 > receiving packets > that it discards. This is not so good. =20 >=20 > Suggestion: >=20 > Perhaps the client timeout should be set outside the IDLE state in the > INITIALIZE state and in the METHOD or SEND_RESPONSE state. >=20 > 5. rxSuccess and rxFailure >=20 > Shouldn't rxSuccess and rxFailure check to see if (reqId =3D=3D=20 > lastReqID)? >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap >=20 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 08:07:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06833 for ; Mon, 15 Dec 2003 08:07:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6CF8C58002A; Mon, 15 Dec 2003 07:07:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 94973580009; Mon, 15 Dec 2003 07:07:05 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1720F580009 for ; Mon, 15 Dec 2003 07:06:01 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 89A41580008 for ; Mon, 15 Dec 2003 07:05:57 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hBFD5ked020857; Mon, 15 Dec 2003 08:05:46 -0500 (EST) From: Nick Petroni To: Cc: , Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38D6@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Dec 2003 08:05:46 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Pasi, just one quick note- > - Item 5: it might check (reqId != lastReqId) (not "=="), > but I don't think this is necessary, since Success/Failure > are never retransmitted. It's still a violation of the protocol though for the packet to have the same ID as the previous one. I agree the change won't affect how one transitions in the state machine since eventually you will go to success anyway, but it seems if the identity were not new the packet should be discarded. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 11:03:26 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14845 for ; Mon, 15 Dec 2003 11:03:24 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 332A7580009; Mon, 15 Dec 2003 10:03:18 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DB84758002A; Mon, 15 Dec 2003 10:03:08 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F28D9580008 for ; Mon, 15 Dec 2003 10:02:37 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 21F5058002C for ; Mon, 15 Dec 2003 10:02:33 -0600 (CST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFG2Wn02555 for ; Mon, 15 Dec 2003 18:02:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 18:02:32 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 18:02:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 193: Peer SM review Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612233F@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 193: Peer SM review Thread-Index: AcOnPcLD/0e3o/x6TtSWUEpGhi18hgb5U3dw From: To: , X-OriginalArrivalTime: 15 Dec 2003 16:02:31.0454 (UTC) FILETIME=[D878CBE0:01C3C324] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Dec 2003 18:02:30 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi, I finally got around to checking the remaining open issues, and found one nit in #193: > The INITIALIZE state does not initialize all variables.=20 > Non-initialized variables include: >=20 > eapKeyData =3D NONE > eapKeyAvailable =3D FALSE > eapSuccess =3D FALSE > eapFail =3D FALSE > methodState =3D NONE > selectedMethod =3D NONE > decision =3D FAIL >=20 > The initialization values seem important since transitions=20 > can be based on them before they are initialized. Re-initializing=20 > variables in the INITIALIZE state is a bit different from giving=20 > the variables initial values before they are ever used. Of these, methodState, selectedMethod, and decision are already=20 initialized (though the exact value for "decision" was not exactly right).=20 However, eapSuccess and eapFail must be initialized by=20 the lower layer; otherwise there's a race condition. I'm not not quite sure about eapKeyData and eapKeyAvailable. I would prefer if they were also initialized by the lower layer (in general, variables that trigger a transition in some=20 other state machine must be reset in the state machine that=20 reads them; otherwise some extra synchronization is needed), but possibly eapSuccess provides the needed "extra synchronization". Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 11:15:23 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15246 for ; Mon, 15 Dec 2003 11:15:21 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F91658000B; Mon, 15 Dec 2003 10:15:22 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 37ED9580038; Mon, 15 Dec 2003 10:15:11 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 487D858002E for ; Mon, 15 Dec 2003 10:14:47 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8F538580016 for ; Mon, 15 Dec 2003 10:14:42 -0600 (CST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7FEB16A901; Mon, 15 Dec 2003 18:14:40 +0200 (EET) Message-ID: <3FDDDDC0.8080803@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aboba@internaut.com, eap@frascone.com Subject: Re: [eap] Issue 193: Peer SM review References: <052E0C61B69C3741AFA5FE88ACC775A612233F@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612233F@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Dec 2003 18:13:52 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Of these, methodState, selectedMethod, and decision are already > initialized (though the exact value for "decision" was not > exactly right). > > However, eapSuccess and eapFail must be initialized by > the lower layer; otherwise there's a race condition. > > I'm not not quite sure about eapKeyData and eapKeyAvailable. > I would prefer if they were also initialized by the lower layer > (in general, variables that trigger a transition in some > other state machine must be reset in the state machine that > reads them; otherwise some extra synchronization is needed), > but possibly eapSuccess provides the needed "extra synchronization". Right. I support this approach. Do not rely on eapSuccess to provide the extra sync. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 11:36:21 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15902 for ; Mon, 15 Dec 2003 11:36:19 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A2BF158002E; Mon, 15 Dec 2003 10:36:19 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 53AF2580032; Mon, 15 Dec 2003 10:36:09 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B960958002F for ; Mon, 15 Dec 2003 10:35:09 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 725D7580030 for ; Mon, 15 Dec 2003 10:35:01 -0600 (CST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBFGZ0H15474 for ; Mon, 15 Dec 2003 18:35:00 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 15 Dec 2003 18:35:00 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 15 Dec 2003 18:34:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] Issue 193: Peer SM review Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122340@esebe023.ntc.nokia.com> Thread-Topic: [eap] Issue 193: Peer SM review Thread-Index: AcOnPcLD/0e3o/x6TtSWUEpGhi18hgb5U3dwAADLGlA= From: To: , X-OriginalArrivalTime: 15 Dec 2003 16:34:59.0895 (UTC) FILETIME=[61D54C70:01C3C329] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Dec 2003 18:34:59 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Replying to myself (not a good habit): > > However, eapSuccess and eapFail must be initialized by=20 > the lower layer; otherwise there's a race condition. ...but 1X-REV/D8 explicitly states that they are=20 initialized by EAP. And yes, there's a race condition. Here's a possible sequence of events: 1. portEnabled becomes TRUE 2. Supplicant PAE moves to CONNECTING state and executes it 3. After a while, eapolEap becomes TRUE (a request is received) 4. Supplicant PAE moves to RESTART state and executes it,=20 setting eapRestart to TRUE 5. EAP peer moves to DISABLED state and executes it, resetting eapRestart to FALSE 6. Supplicant PAE moves to AUTHENTICATING state and executes it, setting suppStart to TRUE (among other things). 7. Supplicant backend was sitting happily in the IDLE state. Now it checks the conditions "eapFail && suppStart" and "eapSuccess && suppStart". 8. EAP peer moves to INITIALIZE state and executes it; but it's now too late to initialize eapSuccess and eapFail! =20 Hmm, would this change fix it? = =20 portEnabled && eapRestart | V =20 +----------------------+ +----------+ | INITIALIZE | | DISABLED | +----------------------+ !portEnabled --->+----------+--portEnabled-->| eapSuccess=3DFALSE | | | | eapFail=3DFALSE | +----------+ | ... | | eapRestart=3DFALSE | +----------------------+ | UCT |=20 V Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 14:24:00 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21253 for ; Mon, 15 Dec 2003 14:23:57 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EB9B058003A; Mon, 15 Dec 2003 13:23:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1FBA9580009; Mon, 15 Dec 2003 13:23:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 57994580128 for ; Mon, 8 Dec 2003 17:12:12 -0600 (CST) Received: from hotmail.com (bay7-f109.bay7.hotmail.com [64.4.11.109]) by mail.frascone.com (Postfix) with ESMTP id 7301A580023 for ; Mon, 8 Dec 2003 17:12:10 -0600 (CST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 8 Dec 2003 15:12:09 -0800 Received: from 207.46.228.98 by by7fd.bay7.hotmail.msn.com with HTTP; Mon, 08 Dec 2003 23:12:09 GMT X-Originating-IP: [207.46.228.98] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, jeb@mtghouse.com Cc: eap@frascone.com, stds-802-1@ieee.org Subject: RE: [802.1] RE: [eap] Issue 204: Peer-to-peer operation Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 08 Dec 2003 23:12:09.0552 (UTC) FILETIME=[B4862500:01C3BDE0] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 08 Dec 2003 15:12:09 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) >Adding a "EAP demultiplexing layer" somewhere might be more >elegant than delivering the frames twice, but personally I could >live with the current approach (especially since these state >machines specify only externally visible behavior, not >implementation). Exactly. The state machines don't require that an implementation process every packet twice. _________________________________________________________________ Wonder if the latest virus has gotten to your computer? Find out. Run the FREE McAfee online computer scan! http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Mon Dec 15 23:11:14 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15315 for ; Mon, 15 Dec 2003 23:11:12 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id EDCC1580008; Mon, 15 Dec 2003 22:11:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC76A580014; Mon, 15 Dec 2003 22:11:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26164580014 for ; Mon, 15 Dec 2003 22:10:23 -0600 (CST) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.frascone.com (Postfix) with ESMTP id 32D4B580008 for ; Mon, 15 Dec 2003 22:10:21 -0600 (CST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Dec 2003 20:13:34 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBG4ABZ6018516; Mon, 15 Dec 2003 20:10:18 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.97.62]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Dec 2003 20:15:37 -0800 From: "Joseph Salowey" To: , Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <004901c3c38a$80fd4150$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C38D6@esebe023.ntc.nokia.com> X-OriginalArrivalTime: 16 Dec 2003 04:15:37.0244 (UTC) FILETIME=[420BB5C0:01C3C38B] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Mon, 15 Dec 2003 20:10:12 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Pasi, Comments inline. Cheers, Joe > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, December 15, 2003 4:54 AM > To: jsalowey@cisco.com; eap@frascone.com > Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine > > > > Thanks for your comments, Joe! (and sorry it took > me so long to respond). > > - I think items 1 and 2 are addressed in proposed resolution > of issue 198: > > http://mail.frascone.com/pipermail/public/eap/2003-November/00 > 1852.html > [Joe] I agree > - Item 3 is a bit more complicated. > > Integrity check is currently a separate procedure to show that > when a packet is silently discarded, methodState and decision > (and other state) remain unchanged. You're right in that a > method can produce an error for invalid packets instead... > Maybe it would be better if we rename m.integrityCheck() to > m.check() and "intCheck" to "discard"? (and change transition > "!intCheck" to "discard") > > Combining methodState and decision to a single variable is > certainly possible, but four different states (plus one > indication for IGNORE) are not enough: there are seven different > combinations. The reason we originally split it was to make the > transitions to SUCCESS and FAILURE states a bit more compact > (they're quite complex anyway, but become totally unreadable > if the variables are combined...). > [Joe] I think integrity check is internal to the mechanism and should not be exposed outside the mechanism. I think there should be a single call into the method that results in one of n possible results. In looking at the state machine I counted 5: IGNORE, CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. What are the additional values? > One thing we could do is get rid of the "x = FOO | BAR" notation, > and instead make m.process() set the variables, and change > METHOD pseudocode to something like this: > > discard = m.check(eapReqData) > if (!discard) { > (methodState,decision,allowNotifications) = > m.process(eapReqData) > /* methodState is CONT, MAY_CONT, or DONE */ > /* decision is FAIL, COND_SUCC or UNCOND_SUCC */ > eapRespData = m.buildResp(reqId) > if (m.isKeyAvailable()) > eapKeyData = m.getKey() > } > > Would this be better? > [Joe] Not really, I don't like breaking up m.check() and m.process(). I think they should be part of the same method. I also think the method state and decision should be combined if possible. I would rather go with the proposal pasted from below with additional variables added to method result if necessary. > > methodResult = m.process(eapRespData) > > If (methodResult != IGNORE) > > { > > methodState = methodResult > > allowNotifications = TRUE|FALSE > > eapRespData = m.buildResponse(reqID) > > if (methodState == SUCCESS || methodState == COND_SUCCESS) > > { > > eapKeyData = NONE|m.getKey() > > } > > } > - Item 4: I think your suggestion (reset timer in INITIALIZE > and SEND_RESPONSE) is ok. > > - Item 5: it might check (reqId != lastReqId) (not "=="), > but I don't think this is necessary, since Success/Failure > are never retransmitted. [Joe] I've lost the context to this, but I thought that EAP-Success and EAP-Failure had the same ID as the previous request and response. From 2284bis Section 4.2: "Identifier The Identifier field is one octet and aids in matching replies to Responses. The Identifier field MUST match the Identifier field of the Response packet that it is sent in response to." > > Best regards, > Pasi > > > -----Original Message----- > > From: eap-admin@frascone.com > > [mailto:eap-admin@frascone.com]On Behalf Of > > ext Joseph Salowey > > Sent: Thursday, November 20, 2003 11:27 PM > > To: eap@frascone.com > > Subject: [eap] [Issue] Comments on EAP-Peer state machine > > > > > > Submitter name: Joe Salowey > > Submitter email address: jsalowey@cisco.com > > Date first submitted: 11/20/2003 > > Reference: > > Document: State Machine > > Comment type: 'E'ditorial > > Priority: '1' Should fix > > Section: 4.x > > Rationale/Explanation of issue: > > > > 1. portEnabled > > > > portEnabled seems very .1x/PPP specific. EAP is being used > in cases > > such as IKE and PANA where this concept may a bit more abstract. > > Perhaps we can change the name of the variable and/or expand its > > definition to include other cases. > > > > Suggestion: > > Perhaps "indicates that a lower layer communcation channel has been > > established". > > > > 2. EAPTunneled > > > > The behavior inside tunnels needs to be defined by the > tunnel as there > > are severl ways you can handle EAP within a tunnel. I think we > > decided to remove this variable at the meeting, but I want to mae > > sure we track > > it. In PEAPv2 we started out with a behavior similar to what is > > described in the state machine, but in order to make sure > > the policy on > > the peer and authenticator stayed in sync we introduced itermediate > > result indicators which I think change the state machine a little. > > > > Suggestion: > > Remove variable. We could explore this in an apppendix or > a separate > > document. > > > > 3. Interface to method > > > > The interface to the method seems too complicated. > > > > First I don't think that intCheck should be a different process. > > Integrity checking is done as part of the method processing. Also > > methods aren't required to ingore packets, some methods with ignore > > some problems and return errors on others. I think this behavior > > should be incorporated into m.process. > > > > On a separate but related note it seems that the method state and > > decision is very complex. I don't really see the need for the > > independent methodState and decision variables. M.process() should > > return one of serverl possible results: IGNORE, CONTINUE, > > COND_SUCCESS, SUCCESS, FAILURE. MethodState should be able > to take on > > CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. I don't think a separate > > decision variable is necessary. > > > > Suggestion > > > > In method: > > > > methodResult = m.process(eapRespData) > > If (methodResult != IGNORE) > > { > > methodState = methodResult > > allowNotifications = TRUE|FALSE > > eapRespData = m.buildResponse(reqID) > > if (methodState == SUCCESS || methodState == COND_SUCCESS) > > { > > eapKeyData = NONE|m.getKey() > > } > > } > > > > Transition to discard: (methodResult == IGNORE) > > Combine methodState and decision transition conditions > > > > 4. Idle timer > > > > It seems that there is a problem with the idle timer. It would be > > possible for the peer to never time out if it keeps on receiving > > packets that it discards. This is not so good. > > > > Suggestion: > > > > Perhaps the client timeout should be set outside the IDLE > state in the > > INITIALIZE state and in the METHOD or SEND_RESPONSE state. > > > > 5. rxSuccess and rxFailure > > > > Shouldn't rxSuccess and rxFailure check to see if (reqId == > > lastReqID)? > > > > > > _______________________________________________ > > eap mailing list > > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 02:23:33 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02726 for ; Tue, 16 Dec 2003 02:23:17 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 3D8A0580008; Tue, 16 Dec 2003 01:23:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DDB55580014; Tue, 16 Dec 2003 01:23:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5A44580014 for ; Tue, 16 Dec 2003 01:22:20 -0600 (CST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id B1B41580008 for ; Tue, 16 Dec 2003 01:22:18 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 08:22:17 +0100 Received: from francetelecom.com ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 08:22:15 +0100 Message-ID: <3FDEB282.1020602@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: henry.haverinen@nokia.com Cc: eap@frascone.com Subject: [eap] EAP-SIM v12 review References: <2D08426B7EAC7745B0AC1B0BD037944F0A56EA@trebe003.europe.nokia.com> In-Reply-To: <2D08426B7EAC7745B0AC1B0BD037944F0A56EA@trebe003.europe.nokia.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2003 07:22:15.0781 (UTC) FILETIME=[54E4D950:01C3C3A5] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 08:21:38 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Henry,

I've just gone through the latest version of EAP-SIM (v12) - congratulations for such a clear and exhaustive document that definitely sets a high-quality standard for EAP method designers! - and I have a few comments/questions: please see below.

Of course, apologies in advance for any irrelevant, stupid, wrong or deja-vu comment/question... which may unfortunately happen though I tried my best not to make any ;-)

Regards,
Florent

Editorial:
  • Section 1, page 3: Replace "The 3rd Generation Partnership Project (3GPP) has specified an enhanced Authentication and Key Exchange (AKA) architecture for the Universal Mobile Telecommunications System (UMTS). " with The 3rd Generation Partnership Project (3GPP) has specified an enhanced Authentication and Key *Agreement* (AKA) architecture for the Universal Mobile Telecommunications System (UMTS). "
  • Section 7.2, page 42: Precise: "The MAC algorithm is HMAC-SHA1-128 [RFC 2104] keyed hash value. (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to 16 bytes." by saying how effectively the truncation is realized (leftmost, rightmost bits in big or little endian representation...).
  • Section 7.3, page 43: Replace "The value field of the AT_ENCR_DATA attribute consists of two reserved bytes followed by cipher text bytes encrypted using the Advanced Encryption Standard (AES) [AES] in the Cipher Block Chaining (CBC) mode of operation using the initialization vector from the AT_IV attribute." with "The value field of the AT_ENCR_DATA attribute consists of two reserved bytes followed by cipher text bytes encrypted using the Advanced Encryption Standard (AES) [AES] *using a 128 bit key* in the Cipher Block Chaining (CBC) mode of operation using the initialization vector from the AT_IV attribute." Indeed, although it is obvious when you read the draft that AES is used with a 128 bit key, since the standard allows for 128, 192 and 256 bit keys, a little precision would do no harm IMHO.
  • Would it be possible to list the attributes in alphabetical order? This would improve the readability of the document, don't you think?
  • Annex B, page 71: is involution the appropriate term for "^"? I'd say exponentiation but I ain't no native English speaker ;-)
Technical:
  • Nonces and Random values: as stated in a previous post to the list (on EAP-Archie), I feel quite uncomfortable with the IMHO confusing language regarding nonces and random values. It is to me all the more important to clarify these issues that some cryptographic results hold only for random values. Therefore I would recommend rechecking the document to see in each case if the nonces are allowed to be only nonces or have to be random values. Here's my quick try at it - further study is of course needed: Nonce_MT should be random,  AT_IV should be random, Nonce_S should be random.  The only "nonce" that I see is the AT_Counter ;-). Of course, we have a terminology collision with the GSM RANDs, still I would rather have the Nonces relabeled Random when appropriate.
  • Limiting the number of Nonce-MTs: if the client chooses to send a new NONCE-MT in each of his EAP-Response/SIM/Start, this might be either risky if he has not implemented a good (pseudo)random generation source of costly if on the contrary he has. However, I have the feeling that you allow a peer to change the NONCE_MT he includes in his EAP-Response/SIM/Start (see page 32) . If so, could you please give a rationale. I personally do think it is not a good idea from a security and performance point of view. I'd also suggest a change to section 4.2.2, page 16, add: "The peer MUST NOT respond to more than three EAP-Request/SIM/Start within an EAP session" and something like "He MUST verify that the sequence of EAP-Request/SIM/Start he receives querying his identity comply to the sequencing rules defined in this document" (this last point is already more or less stated like the first one but I guess I'd like to have it a little bit clarified - why not a SIM Identity request state machine?)
  • Identity protection and Re-authentication: though I understand why these functionalities are implemented, I tend to think like Greg Rose that the pain they cost to implement hardly balances their benefits - except in the EAP-SIM case for re-authentication because obtaining GSM triplets can be costly even for the Home-AAA and re-authentication could be done by the Visited-AAA in some cases. Anyway, after reading the draft, it is not clear at all to me how the next pseudonym or the next-reauth-id (I understood that even if the counter does not require it, a new reauth-id can be sent by the AAA for the next reauths) are managed in tricky situations. For instance, an attacker (or a network malfunction) can cause on one hand, the peer to divulgate his next pseudonym or next reauth-id, and this divulgated next-id can be used on the other hand to start an EAP-SIM exchange with the network: this exchange may proceed without any problem until the network sends the encrypted next-id (pseudonym or reauth). What happens then? Which identity does the network keeps apart from the permanent one: the last one it has exchanged during a successful EAP authentication or the new one it sent during the authentication that aborted half-way through? If I am right - in my difficulties to understand the draft, this could be clarified by explicitly stating when and how the AAA and peer temporary-id state should be updated.
  • Re-authentication: I feel a little bit dizzy with the cryptographic mechanism involved (though confident since Kaisa reviewed it ;-)). Indeed, building on Greg Rose's comments, why is the AT_counter encrypted? Wouldn't its integrity protection with AT_MAC suffice? Similarly would it be possible to explain why Nonce_S is encrypted? I also noticed that the network is the only side to choose the "randomness" or "freshness" to be included in the reauth (AT_Counter and AT_Nonce_s). Although, I do not currently think of any attack based on this point, I think it should be mentioned that an attacker is able to impersonate the network leading to a successful EAP authentication and that this impersonation will only be detected during what is referred to as the "unicast secure association" (phase 2a). This comes more from my personal paranoia than from a rational justification but I think this should be explicitly stated (an attacker seem to be able to "replay" the network's frame without the peer detecting that it isn't fresh :-( - unless we get the re-auth id management point clearer (see my point above)
  • Provisioning next_pseudonym: you state in section 9.1 that the first exchange with the EAP server will have to send the permanent identity in clear but I do not think this is mandatory since the first pseudonym may have been provisioned by out-of-band mechanisms (e.g. provided by a mobile operator on the new SIM it gives to its client for WLAN access).
  • Downgrading attacks: this might well more be of an EAP issue than a method specific issue (I will try to clarify it in another post) but I feel like there's an "egg and chicken" problem here. The most reasonable attitude in version negotiation as stated in the draft is IMHO a static policy decision: both ends should refuse to use versions below a pre-determined version. However, there are some cases where version negotiation is useful. This usefulness either comes from new functionalities or security concerns. If we are in the former case, protecting the version negotiation is not that important. If we are in the latter, it might be vital (although static policy should always be there to save the game): however I'd like to see more of a separation between the pieces that should remain whatever the version (that typically include version negotiation) and the pieces that can be modified without much trouble. To explain my point better: let's take a protocol A that includes version negotiation mixed with its other features. If A gets broken after a devastating cryptanalytic attack, it might be difficult to patch A by releasing a new version since the version negotiation features could share some pieces with the other features that are broken. On the contrary, let's take protocol B that consists of two distinct parts: first a conservative handshake protocol that includes version negotiation (say with public-key cryptography and DSS) and then different versions of record protocols (say the first one with RC4-40 bit, the next one with DES-56 bit and the last one with AES-128 bit). Then, in case AES is deprecated, there shouldn't be any problem in releasing a new record protocol (for instance with MARS-128 bit). Of course if the handshake protocol is deprecated (in my example DSS), then it is obvious that a new (handshake) protocol has to be developed, which shouldn't allow handshake version negotiation but only as its predecessor record negotiation. Do you get my point? To go back to EAP-SIM, my impression is that I don't really know if we are in the A or B case :-( If we are in the B case, then perhaps we could try to give it a more modular aspect to facilitate the comprehension and and relief the implementors that won't fear to have to re-implement everything in case of bad news (but only the "record" protocol). I'll try and clarify my point and propose hints of solution in the general case if you think this is a valid point.
  • Interconnexion with the AuC/GSM network: would it possible to add to the security sections a paragraph about the severe issues this might raise. Indeed, to give a trivial example, with a supplicant flooding an AuC through an AAA through an AP seems to be quite possible (we have implemented one issuing EAPoL-starts and then replying with valid EAP-SIM identities - with or without @MAC spoofing - that could exert a pretty heavy load on an AuC, which has not been designed and dimensioned to handle the new requests due to EAP-SIM WLAN access - indeed the GSM authentication traffic is quite under the operator's control whereas this is not the case for WLANs). We could also imagine more sophisticated attacks that would aim at taking some control on the HLR via the AAA. I guess this issue should be addressed within 3GPP (I'll try and check whether this has yet been treated there or not) but it seems to me worth mentioning it in the draft as you mention other issues related to GSM/GPRS.

_______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 02:30:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02801 for ; Tue, 16 Dec 2003 02:30:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4B8B3580008; Tue, 16 Dec 2003 01:30:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E92F1580016; Tue, 16 Dec 2003 01:30:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 17007580016 for ; Tue, 16 Dec 2003 01:29:05 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 63C40580008 for ; Tue, 16 Dec 2003 01:29:03 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hBG7Ssed017741; Tue, 16 Dec 2003 02:28:55 -0500 (EST) From: Nick Petroni To: Joseph Salowey Cc: , Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine In-Reply-To: <004901c3c38a$80fd4150$0200000a@amer.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 02:28:54 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hi Joe, > > - Item 5: it might check (reqId != lastReqId) (not "=="), > > but I don't think this is necessary, since Success/Failure > > are never retransmitted. > > [Joe] I've lost the context to this, but I thought that EAP-Success and > EAP-Failure had the same ID as the previous request and response. From > 2284bis Section 4.2: > > "Identifier > > The Identifier field is one octet and aids in matching replies to > Responses. The Identifier field MUST match the Identifier field > of the Response packet that it is sent in response to." Sorry, I lead us down the wrong path. I misunderstood how this works. I am still confused why it works this way, but either way you are correct -- the Success should match the last Request/Response ID. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 02:42:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03125 for ; Tue, 16 Dec 2003 02:42:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6625F580008; Tue, 16 Dec 2003 01:42:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id E835C580023; Tue, 16 Dec 2003 01:42:02 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 50472580023 for ; Tue, 16 Dec 2003 01:41:32 -0600 (CST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 7FB6B580008 for ; Tue, 16 Dec 2003 01:41:30 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 08:41:29 +0100 Received: from francetelecom.com ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 08:41:27 +0100 Message-ID: <3FDEB702.2020002@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: uri@bell-labs.com Cc: eap@frascone.com Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2003 07:41:27.0406 (UTC) FILETIME=[0350E0E0:01C3C3A8] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 179: proposed resolution reject Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 08:40:50 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Hi Uri,

Browsing through the list of open issues on the EAP Keying Framework, I came across yours about the proposed AES-based EAP PRF.

Taking into account the discussions on the IPsec (see http://www.sandelman.ottawa.on.ca/ipsec/2003/03/msg00294.html for the beginning of the thread) and the CFRG mailing list (see http://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00161.html for the beginning of the thread) where renowned cryptographers (Hugo Krawczyk and Dave Wagner) made some good points IMO, I suggest this issue be rejected for two reasons:
  • First, it is not for now IMHO within the scope of the EAP Keying Framework to define such a mechanism ("Algorithms for key derivation or mechanisms for key transport are not specified in this document." as of version 02b);
  • Second, as stated above, your proposal did not (yet ;-)) reach consensus within the cryptographic community.
Regards,
Florent

P.S: I absolutely do not mean that such a proposal is not interesting: on the contrary, I think it very valuable to suggest secure key derivation functions (or PRNGs) based on frequent primitives (such as AES)... Indeed, I am currently working on a survey/further analysis of the existing schemes. If you want to follow this discussion off-line or on the CFRG (I do not think it belongs to the EAP mailing list), you are most welcome!
_______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 03:10:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03895 for ; Tue, 16 Dec 2003 03:10:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8562A580016; Tue, 16 Dec 2003 02:10:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B2DE058002B; Tue, 16 Dec 2003 02:10:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 2F45B58002B for ; Tue, 16 Dec 2003 02:09:26 -0600 (CST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 1D25A580016 for ; Tue, 16 Dec 2003 02:09:24 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 09:09:23 +0100 Received: from francetelecom.com ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 09:09:22 +0100 Message-ID: <3FDEBD8D.2040703@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: [eap] Issue with the draft EAP Key Management framework: No name for the "top EAP keying material" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2003 08:09:22.0402 (UTC) FILETIME=[E9B0FC20:01C3C3AB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 09:08:45 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Description of issue: No name for the "top EAP keying material" Submitter name: Florent Bersani Submitter email address: florent.bersani@francetelecom.com Date first submitted: 12/16/2003 Document: Document Requiring change: Keying Framework Comment type: 'E' Priority: '2' Section: 2.2 Rationale/Explanation of issue: Although the EAP hierarchy is very clearly described in section 2.2, I experienced some difficulties to present it to colleagues for a trivial reason: the top EAP key (i.e. the one that is somehow involved in the MK derivation e.g Ki in the EAP-SIM method, the private keys associated to the digital certificates used within EAP-TLS) does not appear to have a name. Things would become easier if there was standard terminology. Requested change: Proposed changes to the document. Add to section 2.2 at the beginning of the different key types enumerations: EAP Permanent Key (PK): To perform authentication and key exchange, an EAP method uses a permanent secret. This secret MAY belong either to the symmetric cryptography or asymmetric cryptography category. Add to Figure 2: "(PK)" near the text "EAP method" in the top left corner of the figure "(MK)" in the box labeled "EAP Method Key Derivation" Add to Figure 3: "PK," before "(MSK,TEKs)" Add to Figure 4: "PK," before "(MSK,TEKs)" Add to appendix B: "Pre-master secret": created or exchanged thanks to the PK which are digital certificates in the case of TLS [This wording "created or exchanged" wants to encompass all the TLS possibilities: RSA, DH,...] [In general, I don't like very much my wording but issue submitters have to propose solutions to their issues, don't they ;-)?] _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 04:34:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05855 for ; Tue, 16 Dec 2003 04:34:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9E0DC580008; Tue, 16 Dec 2003 03:34:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 27535580014; Tue, 16 Dec 2003 03:34:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8D25A580014 for ; Tue, 16 Dec 2003 03:33:17 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 54D4A580008 for ; Tue, 16 Dec 2003 03:33:15 -0600 (CST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBG9XEH06200 for ; Tue, 16 Dec 2003 11:33:14 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 11:33:14 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 11:33:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122342@esebe023.ntc.nokia.com> Thread-Topic: [eap] [Issue 203] Comments on EAP-Peer state machine Thread-Index: AcPDiobNdiVqPcuiTOOMrtDq4oE8AwAKh+7A From: To: , X-OriginalArrivalTime: 16 Dec 2003 09:33:14.0298 (UTC) FILETIME=[A0EF61A0:01C3C3B7] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 11:33:13 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Hi Joe! And thanks for your comments. See my replies inline. > > - Item 3 is a bit more complicated.=20 > >=20 > > Integrity check is currently a separate procedure to show that=20 > > when a packet is silently discarded, methodState and decision=20 > > (and other state) remain unchanged. You're right in that a=20 > > method can produce an error for invalid packets instead... > > Maybe it would be better if we rename m.integrityCheck() to=20 > > m.check() and "intCheck" to "discard"? (and change transition=20 > > "!intCheck" to "discard") > > =20 > > Combining methodState and decision to a single variable is=20 > > certainly possible, but four different states (plus one=20 > > indication for IGNORE) are not enough: there are seven different > > combinations. The reason we originally split it was to make the=20 > > transitions to SUCCESS and FAILURE states a bit more compact=20 > > (they're quite complex anyway, but become totally unreadable=20 > > if the variables are combined...).=20 > >=20 >=20 > [Joe] I think integrity check is internal to the mechanism and=20 > should not be exposed outside the mechanism. I think there should=20 > be a single call into the method that results in one of n possible=20 > results. In looking at the state machine I counted 5: IGNORE,=20 > CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. What are the additional=20 > values? Of the 3*3 combinations for (methodState,decision), the only ones=20 that are not allowed are (CONT,COND_SUCC) and (CONT,UNCOND_SUCC). So we have seven combinations left. No two of them result in exactly=20 same transitions in all circumstances (I actually checked this :-),=20 so they can't be combined without changing the behavior of the=20 state machine. We could, of course, change the behavior as well if you have some=20 suggestions on what to change...? > > - Item 5: it might check (reqId !=3D lastReqId) (not "=3D=3D"),=20 > > but I don't think this is necessary, since Success/Failure=20 > > are never retransmitted. >=20 > [Joe] I've lost the context to this, but I thought that=20 > EAP-Success and EAP-Failure had the same ID as the previous=20 > request and response. From 2284bis Section 4.2: >=20 > "Identifier >=20 > The Identifier field is one octet and aids in matching replies to > Responses. The Identifier field MUST match the Identifier field > of the Response packet that it is sent in response to." Hmm, you're right... (I had thought that each EAP packet sent by the authenticator gets a new identifier value). This requires some changes to the authenticator state=20 machine as well. (BTW, do you have any idea whether current implementations=20 actually do this? At least the EAP-SIM test vectors in=20 draft -12 have a new identifier value for EAP Success :-) Best regards, Pasi _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 06:57:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12369 for ; Tue, 16 Dec 2003 06:57:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6948B580008; Tue, 16 Dec 2003 05:57:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C3AE6580014; Tue, 16 Dec 2003 05:57:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0A299580014 for ; Tue, 16 Dec 2003 05:56:58 -0600 (CST) Received: from ringding.cs.umd.edu (ringding.cs.umd.edu [128.8.129.2]) by mail.frascone.com (Postfix) with ESMTP id 3B531580008 for ; Tue, 16 Dec 2003 05:56:56 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by ringding.cs.umd.edu (8.12.10/8.12.5) with ESMTP id hBGBuled022529; Tue, 16 Dec 2003 06:56:47 -0500 (EST) From: Nick Petroni To: Cc: , Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122342@esebe023.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 06:56:47 -0500 (EST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Hey Pasi, > Hmm, you're right... (I had thought that each EAP packet > sent by the authenticator gets a new identifier value). > This requires some changes to the authenticator state > machine as well. I was so sure of this too (wrongly)- so I checked and was surprised. > (BTW, do you have any idea whether current implementations > actually do this? At least the EAP-SIM test vectors in > draft -12 have a new identifier value for EAP Success :-) In FreeRadius it is as Joe described, at least for TLS. They have a pretty generic method for sending success though so I assume it's the same for other methods there. I haven't tested anything else. Regards, nick _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 10:48:53 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19957 for ; Tue, 16 Dec 2003 10:48:24 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id F38EB58002A; Tue, 16 Dec 2003 09:48:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 26A85580016; Tue, 16 Dec 2003 09:48:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C742B580016 for ; Tue, 16 Dec 2003 09:47:02 -0600 (CST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.frascone.com (Postfix) with ESMTP id 85F1D580008 for ; Tue, 16 Dec 2003 09:47:00 -0600 (CST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBGFkw726732 for ; Tue, 16 Dec 2003 17:46:58 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 16 Dec 2003 17:46:58 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:46:57 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:46:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [eap] EAP-SIM v12 review Message-ID: Thread-Topic: [eap] EAP-SIM v12 review Thread-Index: AcPDpX6arjJydCHKQN6+7c5j8yyobgAFTH1wAAv1UHA= From: To: , X-OriginalArrivalTime: 16 Dec 2003 15:46:57.0863 (UTC) FILETIME=[D66BDD70:01C3C3EB] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:46:57 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable I'm resending this as text only so it won't hit the size restriction. -----Original Message----- From: Haverinen Henry (NES/Jyvaskyla)=20 Sent: 16 December, 2003 14:20 To: 'ext Florent Bersani' Cc: eap@frascone.com Subject: RE: [eap] EAP-SIM v12 review Hello Florent, Many thanks for reviewing EAP-SIM and for your insightful comments!=20 Please see below for my comments. > -----Original Message----- > From: ext Florent Bersani [mailto:florent.bersani@francetelecom.com] > =20 > Editorial:=20 Thanks for these editorials. I'll incorporate them in the next version. I'll try to find a logical order for the attributes, and alphabetical = could work for most of them, except that I'd like to discuss AT_ENCR_DATA, AT_IV and = AT_PADDING together. I also wonder what the correct term for "^" is. Maybe we could simply say x^y denotes x to the power of y? ` > Technical: > Nonces and Random values: as stated in a previous post to the list (on = EAP-Archie),=20 > I feel quite uncomfortable with the IMHO confusing language regarding = nonces and=20 > random values. It is to me all the more important to clarify these = issues that=20 > some cryptographic results hold only for random values. Therefore I = would recommend=20 > rechecking the document to see in each case if the nonces are allowed = to be only nonces=20 > or have to be random values. Here's my quick try at it - further study = is of course=20 > needed: Nonce_MT should be random, AT_IV should be random, Nonce_S = should be random. > The only "nonce" that I see is the AT_Counter ;-). Of course, we have = a terminology=20 > collision with the GSM RANDs, still I would rather have the Nonces = relabeled Random=20 > when appropriate. =20 I agree with your quick try :-).=20 At least we should avoid using the term nonce and refer to these values = as random numbers. But I wonder if we should keep the labels Nonce_MT and Nonce_S so we = wouldn't confuse people=20 who are familiar with the current language, or should we relabel = Nonce_MT to Random_MT and=20 Nonce_S to Random_S... > Limiting the number of Nonce-MTs: if the client chooses to send a new = NONCE-MT=20 > in each of his EAP-Response/SIM/Start, this might be either risky if = he has not implemented=20 > a good (pseudo)random generation source of costly if on the contrary = he has. However,=20 > I have the feeling that you allow a peer to change the NONCE_MT he = includes in his=20 > EAP-Response/SIM/Start (see page 32) . If so, could you please give a = rationale.=20 > I personally do think it is not a good idea from a security and = performance point of view. > I'd also suggest a change to section 4.2.2, page 16, add: "The peer = MUST NOT respond=20 > to more than three EAP-Request/SIM/Start within an EAP session" and = something like=20 > "He MUST verify that the sequence of EAP-Request/SIM/Start he receives = querying his=20 > identity comply to the sequencing rules defined in this document" = (this last point is=20 > already more or less stated like the first one but I guess I'd like to = have it a little=20 > bit clarified - why not a SIM Identity request state machine?) =20 Section 7.6 reads: "The peer MUST choose the NONCE_MT value freshly for = each EAP-SIM authentication exchange. If an EAP-SIM exchange includes several = EAP/SIM/Start rounds, then the=20 peer MAY use the same NONCE_MT value in all EAP-Response/SIM/Start = packets."=20 So it is true that the draft allows both changing the NONCE_MT value=20 and re-using it in this case. The peer and the server both ignore the = first NONCE_MT,=20 so there should be no interoperability problems in either = implementation. We also recommend that the peer should use a good random number = generator.=20 I think we have used MAY rather than MUST or SHOULD mainly because we = didn't see any big problems=20 in doing this either way. Do you think changing the keyword to "SHOULD" = would address your concern? About the second issue (section 4.2.2.) I agree with your proposed = addition. That's a good clarification, thanks! > Identity protection and Re-authentication: though I understand why = these=20 > functionalities are implemented, I tend to think like Greg Rose that = the pain=20 > they cost to implement hardly balances their benefits - except in the = EAP-SIM=20 > case for re-authentication because obtaining GSM triplets can be = costly even=20 > for the Home-AAA and re-authentication could be done by the = Visited-AAA in=20 > some cases. Anyway, after reading the draft, it is not clear at all to = me how=20 > the next pseudonym or the next-reauth-id (I understood that even if = the counter does=20 > not require it, a new reauth-id can be sent by the AAA for the next = reauths) are managed=20 > in tricky situations. For instance, an attacker (or a network = malfunction) can=20 > cause on one hand, the peer to divulgate his next pseudonym or next = reauth-id, and=20 > this divulgated next-id can be used on the other hand to start an = EAP-SIM exchange with=20 > the network: this exchange may proceed without any problem until the = network sends=20 > the encrypted next-id (pseudonym or reauth). What happens then? Which = identity=20 > does the network keeps apart from the permanent one: the last one it = has exchanged=20 > during a successful EAP authentication or the new one it sent during = the authentication=20 > that aborted half-way through? If I am right - in my difficulties to = understand=20 > the draft, this could be clarified by explicitly stating when and how = the AAA and peer=20 > temporary-id state should be updated. =20 Yes, it's very good to clarify this. I don't think there are any = problems in practice, at least in the 3GPP architecture, because pseudonyms and re-authentication id's are generated = cryptographically so that the server will be able to map very many previous id's to the permanent identity. The server = will map these identities to the permanent identity by decrypting the embedded permanent identity. In my opinion, the basic rule is to update the identities upon = successful authentication. I agree there are corner cases, for example the server might think the exchange was = successful while the peer lost the connectivity before receiving EAP Success. Therefore we should recommend the server = to also maintain some old=20 pseodonyms. I think we currently recommend the server to maintain one = pseudonym in addition to the most recently issued. But as discussed above, the 3GPP implementation should = maintain practically all the old pseudonyms. The document requires that the peer must not re-use a re-authentication = id.=20 A re-authentication id can only be used once. Do you think we should add = a clarifying statement=20 about the corner cases. For example, we could further require that: "If the peer uses a re-authentication identity in an EAP exchange, then = the peer MUST discard=20 the re-authentication state information and not re-use the = re-authentication identity in=20 the next authentication attempt, even if the authentication exchange was = not completed." If there is a mismatch in the storage of the re-authentication state = information, then the parties=20 will fall back to full authentication. I'm inclined to think both peer = and server should=20 only maintain one instance of the re-authentication state information, = and let the fall-back=20 procedure take care of mismatches.=20 > Re-authentication: I feel a little bit dizzy with the cryptographic = mechanism involved=20 > (though confident since Kaisa reviewed it ;-)). Indeed, building on = Greg Rose's comments,=20 > why is the AT_counter encrypted? Wouldn't its integrity protection = with AT_MAC suffice?=20 > Similarly would it be possible to explain why Nonce_S is encrypted? I = also noticed=20 > that the network is the only side to choose the "randomness" or = "freshness" to be included=20 > in the reauth (AT_Counter and AT_Nonce_s). Although, I do not = currently think of any attack=20 > based on this point, I think it should be mentioned that an attacker = is able to impersonate=20 > the network leading to a successful EAP authentication and that this = impersonation will only=20 > be detected during what is referred to as the "unicast secure = association" (phase 2a).=20 > This comes more from my personal paranoia than from a rational = justification but I think=20 > this should be explicitly stated (an attacker seem to be able to = "replay" the network's=20 > frame without the peer detecting that it isn't fresh :-( - unless we = get the re-auth id=20 > management point clearer (see my point above) =20 There is no cryptographic need to encrypt the counter or the nonce_S = value, and the protocol would work=20 fine even though these two attributes were transmitted in the clear. We = simply decided to put all attributes of these messages within the AT_ENCR_DATA because = that was a simple thing to do. There is a (weak) anonymity-related rationale for doing this in = cases when very many re-authentications=20 are used between full authentication exchanges. Here the counter could = enable an adversary to link=20 the re-authentication exchanges together. The re-authentication exchange is quite similar to the UMTS AKA = exchange. The counter corresponds to the UMTS AKA sequence number, Nonce_S corresponds to RAND, and AT_MAC in = EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in EAP-Response/SIM/Re-authentication = corresponds to RES, AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the = counter corresponds to the usage of the Anonymity Key. Also the generation of random or fresh material is similar to UMTS AKA = -- the server generates these values, and the peer only verifies that the counter value is = fresh. The peer is required to check that the counter value is big enough. When you say an attacker could impersonate the network and perform a = successful EAP authentication,=20 are you referring to cases when an attacker is replaying an EAP request = from an interrupted re-authentication=20 exchange? I suppose this is not possible if the peer _never_ re-uses a = re-authentication id.=20 Does the same problem apply to UMTS authentication in general, and the = full authentication=20 exchange of EAP AKA? It's probably sufficient to document this problem, = rather than try to solve it. > Provisioning next_pseudonym: you state in section 9.1 that the first = exchange with=20 > the EAP server will have to send the permanent identity in clear but I = do not think=20 > this is mandatory since the first pseudonym may have been provisioned = by out-of-band=20 > mechanisms (e.g. provided by a mobile operator on the new SIM it gives = to its client for WLAN access). =20 OK, we can try to change the language so that it doesn't exclude such = operation. > Downgrading attacks: this might well more be of an EAP issue than a = method specific=20 > issue (I will try to clarify it in another post) but I feel like = there's an "egg and chicken"=20 > problem here. The most reasonable attitude in version negotiation as = stated in the draft=20 > is IMHO a static policy decision: both ends should refuse to use = versions below a=20 > pre-determined version. However, there are some cases where version = negotiation is useful. > This usefulness either comes from new functionalities or security = concerns.=20 > If we are in the former case, protecting the version negotiation is = not that important.=20 > If we are in the latter, it might be vital (although static policy = should always be there=20 > to save the game): however I'd like to see more of a separation = between the pieces that should=20 > remain whatever the version (that typically include version = negotiation) and the pieces that can=20 > be modified without much trouble. To explain my point better: let's = take a protocol A that=20 > includes version negotiation mixed with its other features. If A gets = broken after a devastating=20 > cryptanalytic attack, it might be difficult to patch A by releasing a = new version since=20 > the version negotiation features could share some pieces with the = other features that are broken. > On the contrary, let's take protocol B that consists of two distinct = parts: first a conservative=20 > handshake protocol that includes version negotiation (say with = public-key cryptography and DSS) > and then different versions of record protocols (say the first one = with RC4-40 bit, > the next one with DES-56 bit and the last one with AES-128 bit). Then, = in case AES is deprecated, > there shouldn't be any problem in releasing a new record protocol (for = instance with=20 > MARS-128 bit). Of course if the handshake protocol is deprecated (in = my example DSS), then=20 > it is obvious that a new (handshake) protocol has to be developed, = which shouldn't allow handshake=20 > version negotiation but only as its predecessor record negotiation. Do = you get my point?=20 > To go back to EAP-SIM, my impression is that I don't really know if we = are in the A or B case :-(=20 > If we are in the B case, then perhaps we could try to give it a more = modular aspect to facilitate=20 > the comprehension and and relief the implementors that won't fear to = have to re-implement everything=20 > in case of bad news (but only the "record" protocol). I'll try and = clarify my point and propose hints=20 > of solution in the general case if you think this is a valid point.=20 The version negotiation in EAP-SIM is protected (later during the = exchange)=20 by the mechanisms specified in the selected version. A new EAP-SIM = version can re-define=20 key derivation, PRF, AT_MAC, AT_ENCR_DATA etc, so we can address the = compromize of these=20 primitives by specifying a new version. We don't have any separate more = conservative portion to protect the version negotiation. If key derivation and AT_MAC (or whatever the version uses to protect = version negotiation)=20 are very badly compromized in some version, then it might be possible = for a man-in-the-middle attacker to circumvent the protection and downgrade the security to the = weakest version.=20 The protection of version negotiation in version 1 will be sufficient if = the man-in-the-middle is not able to fake the server's very first AT_MAC, even if other parts = of version 1=20 were compromized. I don't think that protected version negotiation is relevant to cases = that involve a rogue peer=20 or a rogue server, because the rogue party can claim support for the = weakest version only.=20 I wonder if man-in-the-middle attacks (between valid EAP-SIM peer and = valid EAP-SIM server) are in fact the most relevant attacks against EAP-SIM? At this point, I'd welcome any improvements the future-proofness of the = version negotiation=20 that do not break compatibility. However, I'd like to avoid any = incompatible changes to the protocol, unless there is a really good reason. > Interconnexion with the AuC/GSM network: would it possible to add to = the security sections=20 > a paragraph about the severe issues this might raise. Indeed, to give = a trivial example, > with a supplicant flooding an AuC through an AAA through an AP seems = to be quite possible=20 > (we have implemented one issuing EAPoL-starts and then replying with = valid EAP-SIM identities -=20 > with or without @MAC spoofing - that could exert a pretty heavy load = on an AuC, which has not=20 > been designed and dimensioned to handle the new requests due to = EAP-SIM WLAN access - indeed=20 > the GSM authentication traffic is quite under the operator's control = whereas this is not the=20 > case for WLANs). We could also imagine more sophisticated attacks that = would aim at taking some=20 > control on the HLR via the AAA. I guess this issue should be addressed = within 3GPP (I'll try and=20 > check whether this has yet been treated there or not) but it seems to = me worth mentioning it=20 > in the draft as you mention other issues related to GSM/GPRS. =20 This is an important concern, and I agree it's a good idea to mention = that the server=20 implementation should take this into account and should take steps to = prevent flooding the AuC. However I think this issue is probably not exactly in the scope of = EAP-SIM, because it is related=20 to the protocol between the EAP server and the AuC, so we probably don't = need to go into very much detail in this. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 11:56:19 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23252 for ; Tue, 16 Dec 2003 11:56:12 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1DF8758002B; Tue, 16 Dec 2003 10:56:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D9DEE580023; Tue, 16 Dec 2003 10:56:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 14F73580023 for ; Tue, 16 Dec 2003 10:55:22 -0600 (CST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id B954A580016 for ; Tue, 16 Dec 2003 10:55:19 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:55:18 +0100 Received: from francetelecom.com ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Tue, 16 Dec 2003 17:55:15 +0100 Message-ID: <3FDF38CD.7060307@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] EAP-SIM v12 review References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Dec 2003 16:55:15.0929 (UTC) FILETIME=[610F1C90:01C3C3F5] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 17:54:37 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Henry, Thanks for such a quick and detailed response and sorry for the html encoding (I hope I fixed the problem with my mail client and that it will be plain text this time)! A few more comments in-line., essentially regarding identity protection and reauthentication Regards, Florent henry.haverinen@nokia.com wrote: > > > > > -----Original Message----- > *From:* ext Florent Bersani [mailto:florent.bersani@francetelecom.com] > > > Editorial: > > > > > > I also wonder what the correct term for "^" is. Maybe > we could simply say x^y denotes x to the power of y? This is OK for me though a quick search tends to confirm that exponentiation should be appropriate (http://answermath.com/exp.htm). > ` > > Technical: > > * Nonces and Random values: as stated in a previous post to > the list (on EAP-Archie), I feel quite uncomfortable with > the IMHO confusing language regarding nonces and random > values. It is to me all the more important to clarify these > issues that some cryptographic results hold only for random > values. Therefore I would recommend rechecking the document > to see in each case if the nonces are allowed to be only > nonces or have to be random values. Here's my quick try at > it - further study is of course needed: Nonce_MT should be > random, AT_IV should be random, Nonce_S should be random. > The only "nonce" that I see is the AT_Counter ;-). Of > course, we have a terminology collision with the GSM RANDs, > still I would rather have the Nonces relabeled Random when > appropriate. > > > > I agree with your quick try :-). > > At least we should avoid using the term nonce and refer to these > values as random numbers. > > But I wonder if we should keep the labels Nonce_MT and Nonce_S so we > wouldn't confuse people > who are familiar with the current language, or should we relabel > Nonce_MT to Random_MT and > Nonce_S to Random_S... Well, I'd rather have the relabeling to Random_MT and Random_S since what matters to me is the future (the RFC and the people that will read it and download it for years ;-)) and not the present (the draft and the early adopters, that should have the technical level to adapt to terminology changes ;-)), but that's my opinion. With Random_MT, there will be no excuse for the implementor that has implemented a counter whereas with NONCE_MT, he has to read the draft/RFC in detail to understand that it is a random nonce. > > > * Limiting the number of Nonce-MTs: if the client chooses to > send a new NONCE-MT in each of his EAP-Response/SIM/Start, > this might be either risky if he has not implemented a good > (pseudo)random generation source of costly if on the > contrary he has. However, I have the feeling that you allow > a peer to change the NONCE_MT he includes in his > EAP-Response/SIM/Start (see page 32) . If so, could you > please give a rationale. I personally do think it is not a > good idea from a security and performance point of view. I'd > also suggest a change to section 4.2.2, page 16, add: "The > peer MUST NOT respond to more than three > EAP-Request/SIM/Start within an EAP session" and something > like "He MUST verify that the sequence of > EAP-Request/SIM/Start he receives querying his identity > comply to the sequencing rules defined in this document" > (this last point is already more or less stated like the > first one but I guess I'd like to have it a little bit > clarified - why not a SIM Identity request state machine?) > > Section 7.6 reads: "The peer MUST choose the NONCE_MT value freshly > for each EAP-SIM > authentication exchange. If an EAP-SIM exchange includes several > EAP/SIM/Start rounds, then the > peer MAY use the same NONCE_MT value in all EAP-Response/SIM/Start > packets." > > So it is true that the draft allows both changing the NONCE_MT value > and re-using it in this case. > The peer and the server both ignore the first NONCE_MT, so there > should be no interoperability > problems in either implementation. > We also recommend that the peer should use a good random number > generator. > > I think we have used MAY rather than MUST or SHOULD mainly because we > didn't see any big problems > in doing this either way. Do you think changing the keyword to > "SHOULD" would address your > concern? Yes, definitely. My concern was either unnecessary performance consumption on the client side (although 3*16 bytes of pseudorandom data should not be too difficult to generate) or pseudorandom generation fingerprinting i.e. a way for an attacker to try and guess how the pseudorandom data is generated in poor implementations (although there again 3*16 bytes shouldn't help much as a fingerprint). > > About the second issue (section 4.2.2.) I agree with your proposed > addition. That's a good clarification, thanks! > > > * Identity protection and Re-authentication: though I > understand why these functionalities are implemented, I tend > to think like Greg Rose that the pain they cost to implement > hardly balances their benefits - except in the EAP-SIM case > for re-authentication because obtaining GSM triplets can be > costly even for the Home-AAA and re-authentication could be > done by the Visited-AAA in some cases. Anyway, after reading > the draft, it is not clear at all to me how the next > pseudonym or the next-reauth-id (I understood that even if > the counter does not require it, a new reauth-id can be sent > by the AAA for the next reauths) are managed in tricky > situations. For instance, an attacker (or a network > malfunction) can cause on one hand, the peer to divulgate > his next pseudonym or next reauth-id, and this divulgated > next-id can be used on the other hand to start an EAP-SIM > exchange with the network: this exchange may proceed without > any problem until the network sends the encrypted next-id > (pseudonym or reauth). What happens then? Which identity > does the network keeps apart from the permanent one: the > last one it has exchanged during a successful EAP > authentication or the new one it sent during the > authentication that aborted half-way through? If I am right > - in my difficulties to understand the draft, this could be > clarified by explicitly stating when and how the AAA and > peer temporary-id state should be updated. > > > Yes, it's very good to clarify this. I don't think there are any > problems in practice, at least in the 3GPP architecture, > because pseudonyms and re-authentication id's are generated > cryptographically so that the server will be able > to map very many previous id's to the permanent identity. The server > will map these identities to the permanent > identity by decrypting the embedded permanent identity. I assume you are referring to section 6.4.1 of 3GPP TS 33.234 > > In my opinion, the basic rule is to update the identities upon > successful authentication. I agree there are > corner cases, for example the server might think the exchange was > successful while the peer lost the connectivity > before receiving EAP Success. Indeed > Therefore we should recommend the server to also maintain some old > pseodonyms.I think we currently recommend the server to maintain one > pseudonym in addition to the most > recently issued. I am not sure but have nothing better to propose: I guess we should use a probabilistic model to choose our tradeoff between state maintenance load and fallback to permanent id ;-)... > But as discussed above, the 3GPP implementation should maintain > practically all the old > pseudonyms. > > The document requires that the peer must not re-use a > re-authentication id. A re-authentication id can only > be used once. I guess you are referring to section 4.3.3, page 26 "Re-authentication identities are one-time identities.". Therefore I'll have two more comments: First, I do not see any recommendation stating that the server MUST provide a fresh new re-auth identity for each re-authentication. It seems to me that if the AAA server wanted to resend each time the same reauth id, he could do so (thus I recommend to add to Section 4.3.3, page 26: after, "Re-authentication identities are one-time identities": "The server MUST provide a fresh new re-authentication identity to the peer different from the previous ones used within a same reauthentication sequence"). Moreover, I tend to think that, as it is written, the document authorizes the server to accept an old re-authentication identity since it says "If the server recognizes the re-authentication identity and agrees on using re-authentication". Perhaps, a little guidance on the potential threats of a laxist behavior of the server, could help. Second, this misinterpretation is somehow confirmed IMHO by the conjugate use of the AT_COUNTER and NONCE_S. Indeed, if I am right, the three main goals of the AT_COUNTER are first to limit the number of successive reauths without full_auth (2^16 in our case), second to provide new keying material (it is included in the key derivation via the XKEY') and third to protect the peer from replays. The main goal of NONCE_S is to challenge the peer to authenticate itself. However, one could naively and erroneously think that the counter is here to limit the reauths with the same identity :-( Hence, why not include clarification like: Section 7.14, page 49: "AT_COUNTER has three goals : 1) limit the number of successive reauthentication without full-authentication 2) help in providing new keying material 3) protect the peer from replays" - the third point is stated section 4.3.1, page 24 but I do not see a consolidated statement about AT_COUNTER. Moreover, I think the wording of section 4.3.1 leads to believe that the peer chooses the counter - which is not the case: something like "Both the peer and the AAA server maintain a counter to track the number of successive reauthentication without full reauthentication. The AAA server sends its counter value to the peer. The peer's counter value MUST be less or equal than the value sent by the AAA server to protect from replay attacks" Anyway, after thinking a little bit about the matter, I came to the conclusion that identity protection and reauthentication are orthogonal matters. Reauthentication can easily be implemented without identity protection, what do you think? Since there seems to be no consensus on the necessity of identity protection whereas there should be one on reauthentication, why not try to provide a simple solution for reauthentication, a separate solution for identity protection and authorize the mixture of both solutions. The client could use a flag or whatever mechanism (decoration of his identity) to indicate that he wishes a reauth and not a full auth. Before proposing more changes, I'd appreciate having your view on the idea of separating reauthentication from identity protection. > Do you think we should add a clarifying statement about the corner > cases. For example, > we could further require that: > > "If the peer uses a re-authentication identity in an EAP > exchange, then the peer MUST discard > the re-authentication state information and not re-use the > re-authentication identity in > the next authentication attempt, even if the authentication > exchange was not completed." This sounds good to me.I > > If there is a mismatch in the storage of the re-authentication state > information, then the parties > will fall back to full authentication. I'm inclined to think both peer > and server should only maintain one instance > of the re-authentication state information, and let the fall-back > procedure take care of mismatches. > > > * Re-authentication: I feel a little bit dizzy with the > cryptographic mechanism involved (though confident since > Kaisa reviewed it ;-)). Indeed, building on Greg Rose's > comments, why is the AT_counter encrypted? Wouldn't its > integrity protection with AT_MAC suffice? Similarly would it > be possible to explain why Nonce_S is encrypted? I also > noticed that the network is the only side to choose the > "randomness" or "freshness" to be included in the reauth > (AT_Counter and AT_Nonce_s). Although, I do not currently > think of any attack based on this point, I think it should > be mentioned that an attacker is able to impersonate the > network leading to a successful EAP authentication and that > this impersonation will only be detected during what is > referred to as the "unicast secure association" (phase 2a). > This comes more from my personal paranoia than from a > rational justification but I think this should be explicitly > stated (an attacker seem to be able to "replay" the > network's frame without the peer detecting that it isn't > fresh :-( - unless we get the re-auth id management point > clearer (see my point above) > > > > There is no cryptographic need to encrypt the counter or the nonce_S > value, and the protocol would work > fine even though these two attributes were transmitted in the clear. > We simply decided to > put all attributes of these messages within the AT_ENCR_DATA because > that was a simple thing > to do. There is a (weak) anonymity-related rationale for doing this in > cases when very many re-authentications > are used between full authentication exchanges. Here the counter > could enable an adversary to link > the re-authentication exchanges together. Since the incrementation of the counter does not seem to be mandated/specified at each reauthentication (except it must become strictly greater) and that you provide different reauthentication identities at each reauthentication, the anonymity rationale seems to me indeed weak. Furthermore, why do we get into so much trouble : the client probably won't spoof his MAC address. Thus, he will be easy to track by an attacker. Therefore, I tend to think that identity protection is much ado about nothing, but again it is my opinion and I guess, I'll have to see if the folks in 3GPP or GSMA thinks the same. > > The re-authentication exchange is quite similar to the UMTS AKA > exchange. The counter corresponds to > the UMTS AKA sequence number, Nonce_S corresponds to RAND, and AT_MAC > in EAP-Request/SIM/Re-authentication > corresponds to AUTN, the AT_MAC in EAP-Response/SIM/Re-authentication > corresponds to > RES, AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the > counter corresponds > to the usage of the Anonymity Key. > Also the generation of random or fresh material is similar to UMTS AKA > -- the server generates > these values, and the peer only verifies that the counter value is > fresh. The peer is required > to check that the counter value is big enough. > > When you say an attacker could impersonate the network and perform a > successful EAP authentication, > are you referring to cases when an attacker is replaying an EAP > request from an interrupted re-authentication > exchange? I suppose this is not possible if the peer _never_ re-uses > a re-authentication id. Correct > Does the same problem apply to UMTS authentication in general, and the > full authentication > exchange of EAP AKA? It's probably sufficient to document this > problem, rather than try to solve it. I agree > > > * Interconnexion with the AuC/GSM network: would it possible > to add to the security sections a paragraph about the severe > issues this might raise. Indeed, to give a trivial example, > with a supplicant flooding an AuC through an AAA through an > AP seems to be quite possible (we have implemented one > issuing EAPoL-starts and then replying with valid EAP-SIM > identities - with or without @MAC spoofing - that could > exert a pretty heavy load on an AuC, which has not been > designed and dimensioned to handle the new requests due to > EAP-SIM WLAN access - indeed the GSM authentication traffic > is quite under the operator's control whereas this is not > the case for WLANs). We could also imagine more > sophisticated attacks that would aim at taking some control > on the HLR via the AAA. I guess this issue should be > addressed within 3GPP (I'll try and check whether this has > yet been treated there or not) but it seems to me worth > mentioning it in the draft as you mention other issues > related to GSM/GPRS. > > > This is an important concern, and I agree it's a good idea to mention > that the server > implementation should take this into account and should take steps to > prevent flooding the AuC. OK > However I think this issue is probably not exactly in the scope of > EAP-SIM, because it is related > to the protocol between the EAP server and the AuC, so we probably > don't need to go into very much > detail in this. > I totally agree: just a little mention of the possible problem will do just fine > > Best regards, > Henry > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 12:00:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23424 for ; Tue, 16 Dec 2003 12:00:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6288B580008; Tue, 16 Dec 2003 11:00:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 88D74580027; Tue, 16 Dec 2003 11:00:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 510F5580008 for ; Tue, 16 Dec 2003 10:59:28 -0600 (CST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by mail.frascone.com (Postfix) with ESMTP id 47030580027 for ; Tue, 16 Dec 2003 10:59:26 -0600 (CST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id hBGGwSY9005818; Wed, 17 Dec 2003 01:58:28 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id hBGGwRDt027142; Wed, 17 Dec 2003 01:58:27 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA27140 ; Wed, 17 Dec 2003 01:58:27 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA15464; Wed, 17 Dec 2003 01:58:27 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA14242; Wed, 17 Dec 2003 01:58:26 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id hBGGwQwT002046; Wed, 17 Dec 2003 01:58:26 +0900 (JST) Received: from steelhead ([159.119.168.172]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HPZ008WBZ5CC6@tsbpo1.po.toshiba.co.jp>; Wed, 17 Dec 2003 01:58:25 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AWIVo-0003nL-00; Tue, 16 Dec 2003 08:57:32 -0800 From: Yoshihiro Ohba Subject: Re: [eap] [Issue 203] Comments on EAP-Peer state machine In-reply-to: <052E0C61B69C3741AFA5FE88ACC775A6122342@esebe023.ntc.nokia.com> To: Pasi.Eronen@nokia.com Cc: jsalowey@cisco.com, eap@frascone.com Message-id: <20031216165731.GA14258@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i References: <052E0C61B69C3741AFA5FE88ACC775A6122342@esebe023.ntc.nokia.com> X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 08:57:31 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) On Tue, Dec 16, 2003 at 11:33:13AM +0200, Pasi.Eronen@nokia.com wrote: > > "Identifier > > > > The Identifier field is one octet and aids in matching replies to > > Responses. The Identifier field MUST match the Identifier field > > of the Response packet that it is sent in response to." > > Hmm, you're right... (I had thought that each EAP packet > sent by the authenticator gets a new identifier value). > This requires some changes to the authenticator state > machine as well. > > (BTW, do you have any idea whether current implementations > actually do this? At least the EAP-SIM test vectors in > draft -12 have a new identifier value for EAP Success :-) EAP implementation in Open Diameter actually does this, because it is what the specification says. On the other hand, its peer implementation does not check whether the Identifier field in the received Success message matches the one contained in the latest Response message, because the specification does not exactly specify what to do when the mismatch is found. Yoshihiro Ohba > > Best regards, > Pasi > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 12:53:09 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25381 for ; Tue, 16 Dec 2003 12:53:08 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5A52658002B; Tue, 16 Dec 2003 11:53:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D062F580023; Tue, 16 Dec 2003 11:53:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DE0D7580016 for ; Tue, 16 Dec 2003 11:52:44 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id BC8D1580008 for ; Tue, 16 Dec 2003 11:52:42 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBGIAIe20773 for ; Tue, 16 Dec 2003 10:10:18 -0800 From: Bernard Aboba To: eap@frascone.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] [Issue]: IESG DISCUSS comments on RFC 2284bis Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 10:10:17 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Find below Russ Housley's DISCUSS comments on RFC 2284bis. My recommendation is that the proposed changes be accepted, with one exception. Comments? -----Original Message----- From: iesg-admin@ietf.org On Behalf Of ext Russ Housley Sent: Tuesday, December 16, 2003 12:10 PM To: iesg@ietf.org Subject: DISCUSS: draft-ietf-eap-rfc2284bis-06 draft-ietf-eap-rfc2284bis-06.txt Extensible Authentication Protocol (EAP) (Proposed Standard) DISCUSS 1. In section 4.3, paragraph [a], the document says: "These MUST be pseudo-random, generated by a PRNG seeded as per [RFC1750]." While I like RFC 1750 very much, I do not think that a MUST statement ought to reference it. An informative reference is better in this case than a normative reference. [BA] OK. Suggest rewording to: "These MUST be pseudo-random. For discussion of pseudo-random number generation, see [RFC1750]." Also, move the reference to informative. 2. In section 7.2.1, the definition of 'key strength' is not correct. In a perfect symmetric cipher, the brute force attack is the best possible attack. That is, the attacker must attempt to decrypt with each possible key value until the correct one is found. On average, half of the key values need to be tried to locate the correct one to decrypt a particular ciphertext. So, on average, 2^(N-1) operations are needed to attack a key with N bits of effective strength. [BA] OK. COMMENT 1. Please pick one spelling and use it throughout the document: - either 'passthrough' or 'pass-through' - either 'ad-hoc' or 'ad-hoc' or 'ad hoc' [BA] Suggest "pass-through" and "ad-hoc". 2. In section 1.2, please add the definition of supplicant and slightly revise the definition of EMSK as follows: supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet. [BA] OK. 3. In section 1.3, I find the last sentence of the 4th paragraph awkward. I propose the following rewording: As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) between the client and authenticator in order to run over EAP. [BA] OK. 4. In section 2.4, 1st paragraph, last sentence, the term 'authenticatees' is introduced. I think that 'peers' should be used instead. This leads to a problem because 'peers' is used elsewhere in the sentence. Proposal: Both ends of the link may act as authenticators and peers at the same time. [BA] OK. 5. In section 3.2, 1st paragraph, 1st sentence: s/must/MUST/ [BA] This sentence refers to PPP, and making the statement normative would in effect be a change to RFC 1661. This seems inappropriate to me. 6. In section 4.2, 7th paragraph at the top of page 25, 1st sentence, I cannot figure out what the sentence means: A mutually authenticating method (such as EAP-TLS [RFC2716]) that provides authorization error messages provides protected result indications for the purpose of this specification. [BA] I think this means that in TLS, the server indicates to the client that it will provide access when it sends a FINISHED message, without having previously sent a TLS alert to indicate that the client is unauthorized. The client indicates that it will accept the access by indicating that it has authenticated the server certificate and continuing the conversation to its conclusion. So both sides have knowledge of their own decision as well as the decision of the other side. 7. In section 7.11, 2nd paragraph, last sentence: s/recommended/RECOMMENDED/ [BA] OK. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 12:54:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25411 for ; Tue, 16 Dec 2003 12:54:08 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DD6A7580016; Tue, 16 Dec 2003 11:54:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5885958002A; Tue, 16 Dec 2003 11:54:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5758580023 for ; Tue, 16 Dec 2003 11:53:10 -0600 (CST) Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.frascone.com (Postfix) with ESMTP id A75FE580008 for ; Tue, 16 Dec 2003 11:53:02 -0600 (CST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Dec 2003 09:56:02 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBGHqxZ0018265; Tue, 16 Dec 2003 09:52:59 -0800 (PST) Received: from jsaloweyw2k01 ([10.21.97.62]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Dec 2003 09:58:22 -0800 From: "Joseph Salowey" To: , Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine Message-ID: <003601c3c3fd$712a84e0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122342@esebe023.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 16 Dec 2003 17:58:22.0955 (UTC) FILETIME=[324D6BB0:01C3C3FE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 09:52:58 -0800 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Tuesday, December 16, 2003 1:33 AM > To: jsalowey@cisco.com; eap@frascone.com > Subject: RE: [eap] [Issue 203] Comments on EAP-Peer state machine > > > Hi Joe! > > And thanks for your comments. See my replies inline. > > > > - Item 3 is a bit more complicated. > > > > > > Integrity check is currently a separate procedure to show that > > > when a packet is silently discarded, methodState and decision > > > (and other state) remain unchanged. You're right in that a > > > method can produce an error for invalid packets instead... > > > Maybe it would be better if we rename m.integrityCheck() to > > > m.check() and "intCheck" to "discard"? (and change transition > > > "!intCheck" to "discard") > > > > > > Combining methodState and decision to a single variable is > > > certainly possible, but four different states (plus one > > > indication for IGNORE) are not enough: there are seven different > > > combinations. The reason we originally split it was to make the > > > transitions to SUCCESS and FAILURE states a bit more compact > > > (they're quite complex anyway, but become totally unreadable > > > if the variables are combined...). > > > > > > > [Joe] I think integrity check is internal to the mechanism and > > should not be exposed outside the mechanism. I think there should > > be a single call into the method that results in one of n possible > > results. In looking at the state machine I counted 5: IGNORE, > > CONTINUE, COND_SUCCESS, SUCCESS, FAILURE. What are the additional > > values? > > Of the 3*3 combinations for (methodState,decision), the only ones > that are not allowed are (CONT,COND_SUCC) and > (CONT,UNCOND_SUCC). So we have seven combinations left. No > two of them result in exactly > same transitions in all circumstances (I actually checked this :-), > so they can't be combined without changing the behavior of the > state machine. > > We could, of course, change the behavior as well if you have some > suggestions on what to change...? > [Joe] Hmmm... I have the suspicion that you are right. I'll have a look though, I feel that there should be a way to simplify it. > > > > > - Item 5: it might check (reqId != lastReqId) (not "=="), > > > but I don't think this is necessary, since Success/Failure > > > are never retransmitted. > > > > [Joe] I've lost the context to this, but I thought that > > EAP-Success and EAP-Failure had the same ID as the previous > > request and response. From 2284bis Section 4.2: > > > > "Identifier > > > > The Identifier field is one octet and aids in matching replies to > > Responses. The Identifier field MUST match the Identifier field of > > the Response packet that it is sent in response to." > > Hmm, you're right... (I had thought that each EAP packet > sent by the authenticator gets a new identifier value). > This requires some changes to the authenticator state > machine as well. > > (BTW, do you have any idea whether current implementations > actually do this? At least the EAP-SIM test vectors in > draft -12 have a new identifier value for EAP Success :-) > [Joe] Yes I remember seeing that in the test vectors but forgot to comment on it. Most of the implementations I have worked with use the same ID for the EAP-Success. > Best regards, > Pasi > _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 16:30:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08235 for ; Tue, 16 Dec 2003 16:30:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D182C580008; Tue, 16 Dec 2003 15:30:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C7A98580016; Tue, 16 Dec 2003 15:30:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1127E580016 for ; Tue, 16 Dec 2003 15:29:34 -0600 (CST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by mail.frascone.com (Postfix) with ESMTP id 8A8DD580008 for ; Tue, 16 Dec 2003 15:29:32 -0600 (CST) Received: from piuha.net (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 93DFA6A905; Tue, 16 Dec 2003 23:29:30 +0200 (EET) Message-ID: <3FDF7909.2090508@piuha.net> From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] [Issue]: IESG DISCUSS comments on RFC 2284bis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 23:28:41 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Find below Russ Housley's DISCUSS comments on RFC 2284bis. My > recommendation is that the proposed changes be accepted, with one > exception. Comments? Agreed. It appears that there are a couple of items where we still need a text proposal. --Jari _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Tue Dec 16 16:49:13 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09762 for ; Tue, 16 Dec 2003 16:49:13 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 41278580008; Tue, 16 Dec 2003 15:49:14 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C5A8D580016; Tue, 16 Dec 2003 15:49:06 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id A69BA580016 for ; Tue, 16 Dec 2003 15:48:47 -0600 (CST) Received: from chardonnay.levkowetz.com (h195n1fls311o871.telia.com [213.64.174.195]) by mail.frascone.com (Postfix) with ESMTP id 8837A580008 for ; Tue, 16 Dec 2003 15:48:41 -0600 (CST) Received: from chardonnay ([127.0.0.1] helo=chardonnay.levkowetz.com) by chardonnay.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1AWN3V-0000FQ-00; Tue, 16 Dec 2003 22:48:37 +0100 From: Henrik Levkowetz To: Bernard Aboba Cc: eap@frascone.com Subject: Re: [eap] [Issue]: IESG DISCUSS comments on RFC 2284bis Message-Id: <20031216224832.609d23b2.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Tue, 16 Dec 2003 22:48:32 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Tuesday 16 December 2003, Bernard Aboba wrote: > Find below Russ Housley's DISCUSS comments on RFC 2284bis. My > recommendation is that the proposed changes be accepted, with one > exception. Comments? [...] > 1. Please pick one spelling and use it throughout the document: > - either 'passthrough' or 'pass-through' > - either 'adhoc' or 'ad-hoc' or 'ad hoc' > > [BA] Suggest "pass-through" and "ad-hoc". It seems the IEEE 802.11 spec. uses "ad hoc"? Henrik _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 17 10:04:12 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10689 for ; Wed, 17 Dec 2003 10:04:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1626458002C; Wed, 17 Dec 2003 09:04:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 375F1580023; Wed, 17 Dec 2003 09:04:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B1567580023 for ; Wed, 17 Dec 2003 09:03:54 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id 8F83B580008 for ; Wed, 17 Dec 2003 09:03:52 -0600 (CST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBHF3oI17556 for ; Wed, 17 Dec 2003 17:03:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 17 Dec 2003 17:03:50 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 17:03:50 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 17:03:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: FW: [eap] EAP-SIM v12 review Message-ID: Thread-Topic: [eap] EAP-SIM v12 review Thread-Index: AcPD8ikjSAD4P9Q8QeelCRb60qVYuQAsCszAAAMlQOA= From: To: X-OriginalArrivalTime: 17 Dec 2003 15:03:50.0130 (UTC) FILETIME=[FA6CE520:01C3C4AE] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 17:03:49 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: quoted-printable Florent, Many thanks for your response. Please see my comments in line. > This is OK for me though a quick search tends to confirm that=20 > exponentiation should be appropriate (http://answermath.com/exp.htm). OK, thanks! > Well, I'd rather have the relabeling to Random_MT and Random_S since=20 > what matters to me is the future (the RFC and the people that=20 > will read=20 > it and download it for years ;-))=20 > [..] Pasi Eronen reminded me that the term "nonce" is quite widely used to denote a random number. Perhaps "nonce" does not have any commonly recognized clear meaning, but different documents use it to denote different things. For example the IKEv2 terminology is similar to ours. So I'm inclined=20 to think we can keep these terms Nonce_MT and Nonce_S, especially=20 if we make sure they are referred to as random nonces, and the attribute = specifications clearly require choosing them randomly.=20 I don't think that would leave any excuses for an implementation that=20 uses a counter value as the Nonce_MT. :-) > > [..] I don't think there are any=20 > > problems in practice, at least in the 3GPP architecture, > > because pseudonyms and re-authentication id's are generated=20 > > cryptographically so that the server will be able > > to map very many previous id's to the permanent identity.=20 > The server=20 > > will map these identities to the permanent > > identity by decrypting the embedded permanent identity. >=20 > I assume you are referring to section 6.4.1 of 3GPP TS 33.234 >=20 Yes > > Therefore we should recommend the server to also maintain some old > > pseodonyms.I think we currently recommend the server to=20 > maintain one=20 > > pseudonym in addition to the most >=20 > > recently issued. >=20 > I am not sure but have nothing better to propose: I guess we=20 > should use=20 > a probabilistic model to choose our tradeoff between state=20 > maintenance=20 > load and fallback to permanent id ;-)... >=20 In the light of the above-mentioned 3GPP TS, I think it is sufficient just to point out that the server should take this into account and be prepared to map at least one or preferably a couple of old pseudonyms in addition to the most=20 recently issued. Perhaps there could be a reference to TS 33.234 too. I'm not saying probabilistic modelling wouldn't be nice... :-) > First, I do not see any recommendation stating that the server MUST=20 > provide a fresh new re-auth identity for each re-authentication. It=20 > seems to me that if the AAA server wanted to resend each time=20 > the same=20 > reauth id, he could do so (thus I recommend to add to Section 4.3.3,=20 > page 26: after, "Re-authentication identities are one-time=20 > identities":=20 > "The server MUST provide a fresh new re-authentication=20 > identity to the=20 > peer different from the previous ones used within a same=20 > reauthentication sequence").=20 I suppose this depends on how seriously we want to take=20 the potential replay of EAP-Request/SIM/Reauthentication. As we noted before, the same problem is always present in=20 UMTS AKA too.=20 Anyway, I agree with your proposal. In this case there shouldn't be=20 any problems in adding such a statement, but using fresh identities=20 only seems to bring advantages. Could the keyword be SHOULD instead of MUST? > Moreover, I tend to think that, as it is=20 > written, the document authorizes the server to accept an old=20 > re-authentication identity since it says "If the server=20 > recognizes the=20 > re-authentication identity and agrees on using re-authentication".=20 > Perhaps, a little guidance on the potential threats of a=20 > laxist behavior=20 > of the server, could help. I agree we should explicitly require the server to only accept=20 the most recently issued re-authentication ID. I don't think the quoted sentence authorizes the server to accept an old re-authentication identity, but it only aims at describing the operation in case the peer uses a valid re-authentication identity.=20 > Second, this misinterpretation is somehow confirmed IMHO by the=20 > conjugate use of the AT_COUNTER and NONCE_S. Indeed, if I am=20 > right, the=20 > three main goals of the AT_COUNTER are first to limit the number of=20 > successive reauths without full_auth (2^16 in our case), second to=20 > provide new keying material (it is included in the key derivation via=20 > the XKEY') and third to protect the peer from replays. The=20 > main goal of=20 > NONCE_S is to challenge the peer to authenticate itself.=20 Yes. > However, one=20 > could naively and erroneously think that the counter is here to limit=20 > the reauths with the same identity :-( Hence, why not include=20 > clarification like: > Section 7.14, page 49: "AT_COUNTER has three goals : > 1) limit the number of successive reauthentication without=20 > full-authentication > 2) help in providing new keying material > 3) protect the peer from replays"=20 OK > Moreover, I think the wording of section 4.3.1 leads to=20 > believe that the peer chooses the counter - which is not the case:=20 > something like "Both the peer and the AAA server maintain a=20 > counter to=20 > track the number of successive reauthentication without full=20 > reauthentication. The AAA server sends its counter value to the peer.=20 > The peer's counter value MUST be less or equal than the value sent by=20 > the AAA server to protect from replay attacks" Thanks, this is a useful clarification. > Anyway, after thinking a little bit about the matter, I came to the=20 > conclusion that identity protection and reauthentication are=20 > orthogonal=20 > matters. Reauthentication can easily be implemented without identity=20 > protection, what do you think? I agree, and the draft even doesn't require you to implement pseudonym support if you only want to support re-authentication. > Since there seems to be no consensus on the necessity of identity=20 > protection whereas there should be one on reauthentication,=20 I think there is demand for both features. TS 33.234 also includes identity privacy. Perhaps not everyone wants to use both features, but I wouldn't call that lack of consensus. Both features are optional and=20 they can be disabled if they are not considered necessary.=20 So I don't see any problems in having both features included in=20 the protocol as optional features. > why not try=20 > to provide a simple solution for reauthentication, a separate=20 > solution=20 > for identity protection and authorize the mixture of both solutions. Originally the reasons for having a separate re-authentication=20 identity were 1. peer can choose a suitable identity to indicate it wants to use = re-authentication 2. server doesn't need to manage all temporary identities as "carefully" = but it can be "sloppier" with re-auth ids than pseudonyms. 3. single-use re-auth id's may also improve the security of the very = short two-message re-auth procedure. 4. separate identities would allow an intermediate box, located closer = to=20 the access network, to implement fast re-authentication. The AAA server could delegate re-authentications to an intermediate proxy. (I suppose this reason is not relevant currently.) The server can generate re-authentication id's for example by = concatenating the IMSI and a random number, which would work as a flag to request for re-authentication, so the overhead associated with identity privacy=20 management can be avoided. (The server needs to maintain some = re-authentication state information in any case if it wants to support re-authentication.) In my opinion, the current design works fine. I suppose there aren't any big problems that we must solve. We should avoid making incompatible changes if they are not absolutely necessary. > Since the incrementation of the counter does not seem to be=20 > mandated/specified at each reauthentication (except it must become=20 > strictly greater) and that you provide different reauthentication=20 > identities at each reauthentication, the anonymity rationale=20 > [to encrypt AT_COUNTER] seems to me indeed weak. I agree. And as discussed, we simply decided to put everything within AT_ENCR_DATA just because we could and the cost is negligible. There is no harm done in sending these values encrypted. > Furthermore, why do we get into so much trouble : the client probably=20 > won't spoof his MAC address. Thus, he will be easy to track=20 > by an attacker. I know the MAC address is currently a more serious identity problem than the AAA identity, not to mention the counter.=20 I personally think MAC address privacy should be fixed too, and random addresses should be used, but let's not get into that discussion... The fact that something else is broken is not an excuse to make the same mistake elsewhere. Best regards, Henry _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 17 10:52:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16243 for ; Wed, 17 Dec 2003 10:52:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 6FE6958002C; Wed, 17 Dec 2003 09:52:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id DC5FD580023; Wed, 17 Dec 2003 09:52:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 518E3580023 for ; Wed, 17 Dec 2003 09:51:43 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 517C2580008 for ; Wed, 17 Dec 2003 09:51:37 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHG8rn01849; Wed, 17 Dec 2003 08:09:04 -0800 From: Bernard Aboba To: eap@frascone.com Cc: housley@vigilsec.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Proposed resolution to Issue 207: IESG comments on RFC 2284bis-07 Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 08:08:53 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) The text of Issue 207 is enclosed below. The proposed resolution is as follows: Change "passthrough" to "pass-through" throughout the document. Change "ad-hoc" to "ad hoc" throughout the document. In Section 2.1, add the following definition: Supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer. Change the definition of the EMSK to the following: "Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet." In Section 1.3, change the 4th paragraph from: " EAP authentication is initiated by the authenticator, whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an algorithm to add 0.5 - 1 additional roundtrips between the client and authenticator in order to run over EAP." To: " EAP authentication is initiated by the authenticator, whereas many authentication protocols are initiated by the client (peer). As a result, it may be necessary for an algorithm to add one or two additional messages (at most one roundtrip) between the peer and server in order to run over EAP." In Section 2.4, first paragraph, change: "Both peers may act as authenticators and authenticatees at the same time, in which case it is necessary for both peers to implement EAP authenticator and peer layers." To: "Both ends of the link may act as authenticators and peers at the same time. In this case it is necessary for both ends to implement EAP authenticator and peer layers." In Section 3.2, 1st paragraph, change: " In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase." To: " In order to establish communications over a point-to-point link, each end of the PPP link first sends LCP packets to configure the data link during Link Establishment phase." In Section 4.3, paragraph [a], change: "These MUST be pseudo-random, generated by a PRNG seeded as per [RFC1750]." To: "These MUST be pseudo-random. For a discussion of pseudo-random number generation, see [RFC1750]." Change the reference to [RFC1750] to Informative. In Section 7.2.1, change: "The effective key strength SHOULD be stated as number of bits, defined as follows: If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) require an effort comparable to 2^N operations of a typical block cipher." To: "The effective key strength SHOULD be stated as number of bits, defined as follows: If the effective key strength is N bits, the best currently known methods to recover the key (with non-negligible probability) requires on average an effort comparable to 2^(N-1) operations of a typical block cipher." In section 7.11, change 2nd paragraph from: " As a result, as noted in Section 3.1, where EAP is used over a physically insecure lower layer, per-packet authentication, integrity and replay protection SHOULD be used, and per-packet confidentiality is also recommended." To: " As a result, as noted in Section 3.1, where EAP is used over a physically insecure lower layer, per-packet authentication, integrity and replay protection SHOULD be used, and per-packet confidentiality is RECOMMENDED." In Section 4.2, 7th paragraph, change: " A mutually authenticating method (such as EAP-TLS [RFC2716]) that provides authorization error messages provides protected result indications for the purpose of this specification. Within EAP-TLS, the peer always authenticates the authenticator, and may send a TLS-alert message in the event of an authentication failure. An authenticator may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the authenticator decided not to proceed. If a method provides authorization error messages, the authenticator SHOULD use them so as to ensure consistency with the final access decision and avoid lengthy timeouts." To: "If a mutually authenticating method supports error messages, then the peer and server SHOULD use them to provide protected result indications. This ensures that the peer and server are aware of each other's final access decision, and prevents lengthy timeouts. For example, within EAP-TLS [RFC2716], the peer always authenticates the server, and sends a TLS alert message in the event of an authentication or authorization failure. If the server does not receive a TLS alert message from the peer and the peer continues the conversation to completion, then the server can assume that the peer will accept access if granted it by the server. Similarly, the peer can assume that the server will grant access if it does not receive a TLS alert message from the server, and the server carries the conversation to completion. A server may use the "access denied" TLS alert after successfully authenticating the peer to indicate that a valid certificate was received from the peer, but when access control was applied, the server decided not to proceed." ------------------------------------------------------------------------ Issue 207: IESG comments on RFC2284bis-07 Submitter name: Russ Housley Submitter email address: housley@vigilsec.com Date first submitted: 12/15/2003 Reference: http://mail.frascone.com/pipermail/public/eap/2003-December/002003.html Document: RFC 2284bis-07 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: DISCUSS 1. In section 4.3, paragraph [a], the document says: "These MUST be pseudo-random, generated by a PRNG seeded as per [RFC1750]." While I like RFC 1750 very much, I do not think that a MUST statement ought to reference it. An informative reference is better in this case than a normative reference. 2. In section 7.2.1, the definition of 'key strength' is not correct. In a perfect symmetric cipher, the brute force attack is the best possible attack. That is, the attacker must attempt to decrypt with each possible key value until the correct one is found. On average, half of the key values need to be tried to locate the correct one to decrypt a particular ciphertext. So, on average, 2^(N-1) operations are needed to attack a key with N bits of effective strength. COMMENT 1. Please pick one spelling and use it throughout the document: - either 'passthrough' or 'pass-through' - either 'ad-hoc' or 'ad-hoc' or 'ad hoc' 2. In section 1.2, please add the definition of supplicant and slightly revise the definition of EMSK as follows: supplicant The end of the link that responds to the authenticator in [IEEE-802.1X]. In this document, this end of the link is called the peer. Extended Master Session Key (EMSK) Additional keying material derived between the EAP client and server that is exported by the EAP method. The EMSK is at least 64 octets in length. The EMSK is not shared with the authenticator or any other third party. The EMSK is reserved for future uses that are not defined yet. 3. In section 1.3, I find the last sentence of the 4th paragraph awkward. I propose the following rewording: As a result, it may be necessary for an authentication algorithm to add one or two additional messages (at most one roundtrip) between the client and authenticator in order to run over EAP. 4. In section 2.4, 1st paragraph, last sentence, the term 'authenticatees' is introduced. I think that 'peers' should be used instead. This leads to a problem because 'peers' is used elsewhere in the sentence. Proposal: Both ends of the link may act as authenticators and peers at the same time. 5. In section 3.2, 1st paragraph, 1st sentence: s/must/MUST/ [BA] This sentence refers to PPP, and making the statement normative would in effect be a change to RFC 1661. This seems inappropriate to me. 6. In section 4.2, 7th paragraph at the top of page 25, 1st sentence, I cannot figure out what the sentence means: A mutually authenticating method (such as EAP-TLS [RFC2716]) that provides authorization error messages provides protected result indications for the purpose of this specification. 7. In section 7.11, 2nd paragraph, last sentence: s/recommended/RECOMMENDED/ _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 17 12:27:18 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21450 for ; Wed, 17 Dec 2003 12:27:15 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id C01EA580008; Wed, 17 Dec 2003 11:27:08 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 22FA6580017; Wed, 17 Dec 2003 11:27:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 06F84580017 for ; Wed, 17 Dec 2003 11:26:59 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 38409580008 for ; Wed, 17 Dec 2003 11:26:57 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBHHiMa07390; Wed, 17 Dec 2003 09:44:22 -0800 From: Bernard Aboba To: Henrik Levkowetz Cc: Jari Arkko , eap@frascone.com Subject: Re: [eap] Proposed resolution to Issue 207: IESG comments on RFC 2284bis-07 In-Reply-To: <20031217173048.4bad9e33.henrik@levkowetz.com> Message-ID: References: <20031217173048.4bad9e33.henrik@levkowetz.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 09:44:21 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) > Hi Bernard, > > Just verifying: > > > In Section 1.3, change the 4th paragraph from: > > > > " EAP authentication is initiated by the authenticator, whereas many > > authentication protocols are initiated by the client (peer). As a > > result, it may be necessary for an algorithm to add 0.5 - 1 > > additional roundtrips between the client and authenticator in order > > to run over EAP." > > > > To: > > > > " EAP authentication is initiated by the authenticator, whereas many > > authentication protocols are initiated by the client (peer). As a > > result, it may be necessary for an algorithm to add one or two > > additional messages (at most one roundtrip) between the peer and > > server in order to run over EAP." > > Was it your intention here to change "neccesary for an authentication > algorithm" in Russ' replacement text to "neccesary for an algorithm"? Thanks for catching this. I think we we want "necessary for an authentication algorithm." > [...] > > > In Section 7.2.1, change: > > > > "The effective key strength SHOULD be stated as number of bits, > > defined as follows: If the effective key strength is N bits, the > > best currently known methods to recover the key (with > > non-negligible probability) require an effort comparable to 2^N > > operations of a typical block cipher." > > > > To: > > > > "The effective key strength SHOULD be stated as number of bits, > > defined as follows: If the effective key strength is N bits, the > > best currently known methods to recover the key (with > > non-negligible probability) requires on average an effort > > comparable to 2^(N-1) operations of a typical block cipher." > > I think "...methods...requires on average" should be > "...methods...require on average"? Yes. _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Wed Dec 17 14:49:36 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28241 for ; Wed, 17 Dec 2003 14:49:19 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 1983D580008; Wed, 17 Dec 2003 13:49:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 60A22580017; Wed, 17 Dec 2003 13:49:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8048F58002A for ; Wed, 17 Dec 2003 13:48:50 -0600 (CST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by mail.frascone.com (Postfix) with ESMTP id 94DFE580008 for ; Wed, 17 Dec 2003 13:48:37 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 20:48:34 +0100 Received: from francetelecom.com ([139.100.161.82]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Wed, 17 Dec 2003 20:48:32 +0100 Message-ID: <3FE0B2E7.20602@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] EAP-SIM v12 review References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Dec 2003 19:48:32.0951 (UTC) FILETIME=[C0948470:01C3C4D6] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Wed, 17 Dec 2003 20:47:51 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Henry, Thanks for taking the time to consider my contents :-) and happy/sorry that your answer triggers some more ;-) Please see in-line. Florent henry.haverinen@nokia.com wrote: >Florent, > > > >>Well, I'd rather have the relabeling to Random_MT and Random_S since >>what matters to me is the future (the RFC and the people that >>will read >>it and download it for years ;-)) >>[..] >> >> > >Pasi Eronen reminded me that the term "nonce" is quite widely >used to denote a random number. Perhaps "nonce" does not have >any commonly recognized clear meaning, but different documents >use it to denote different things. > > If I wouldn't fear that my humor be misunderstood, I'd quote you as per your last e-mail: "The fact that something else is broken is not an excuse to make the same mistake elsewhere." ;-) I agree that nonce is sometimes (often :-( ) misused and that its meaning (and translation, for instance I don't know any appropriate in French) may seem quite obscure. I also understand your reluctance to relabel your random nonces. However, although you probably do know, let me point out, to be more concrete, a precise cryptographic result which holds when the nonces are random and doesn't when they aren't (i.e. when the nonces are implemented as a counter): the theorem 4.4 of "Entity Authentication and Key Distribution" by Mihir Bellare and Phillip Rogaway, abridged version published at Crypto'93, full version available on Mihir's homepage (http://www-cse.ucsd.edu/users/mihir/papers/key-distribution.html). This theorem does not hold, as discussed immediately after it being stated in the paper, if the nonce are predictable (not random). Therefore my fear on the confusion between ordinary nonces and random values :-( >For example the IKEv2 terminology is similar to ours. So I'm inclined >to think we can keep these terms Nonce_MT and Nonce_S, especially >if we make sure they are referred to as random nonces, and the attribute >specifications clearly require choosing them randomly. >I don't think that would leave any excuses for an implementation that >uses a counter value as the Nonce_MT. :-) > > To be constructive, if you really don't feel like relabeling the NONCES, may I then suggest to add to the clear statement in the attribute saying that NONCE X must be a random value, that you suggest and that is more or less already there, a paragraph to section 2 defining Nonce and warning the reader to check if the nonce must be random or not. Here's my proposed text: "Nonce: a value that is used at most once [or that is never repeated] within the same cryptographic context. A nonce can be predictable (e.g. a counter) or unpredictable (e.g. a random value). Since some cryptographic properties may depend on the randomness of the nonce, attention should be paid to whether a nonce is required to be random or not." >>First, I do not see any recommendation stating that the server MUST >>provide a fresh new re-auth identity for each re-authentication. It >>seems to me that if the AAA server wanted to resend each time >>the same >>reauth id, he could do so (thus I recommend to add to Section 4.3.3, >>page 26: after, "Re-authentication identities are one-time >>identities": >>"The server MUST provide a fresh new re-authentication >>identity to the >>peer different from the previous ones used within a same >>reauthentication sequence"). >> >> > >I suppose this depends on how seriously we want to take >the potential replay of EAP-Request/SIM/Reauthentication. >As we noted before, the same problem is always present in >UMTS AKA too. > >Anyway, I agree with your proposal. In this case there shouldn't be >any problems in adding such a statement, but using fresh identities >only seems to bring advantages. >Could the keyword be SHOULD instead of MUST? > > Yes indeed, I think so: see below > > >>Moreover, I tend to think that, as it is >>written, the document authorizes the server to accept an old >>re-authentication identity since it says "If the server >>recognizes the >>re-authentication identity and agrees on using re-authentication". >>Perhaps, a little guidance on the potential threats of a >>laxist behavior >>of the server, could help. >> >> > >I agree we should explicitly require the server to only accept >the most recently issued re-authentication ID. > >I don't think the quoted sentence authorizes the server >to accept an old re-authentication identity, but it only aims >at describing the operation in case the peer uses a valid >re-authentication identity. > > > OK, I was thinking of something like "If the re-authentication identity presented by the peer matches a valid re-authentication identity for the server" instead of "recognizes, but if I am the only one to feel like changing your wording, I won't be stubborn :-) >>Anyway, after thinking a little bit about the matter, I came to the >>conclusion that identity protection and reauthentication are >>orthogonal >>matters. Reauthentication can easily be implemented without identity >>protection, what do you think? >> >> > >I agree, and the draft even doesn't require you to implement >pseudonym support if you only want to support re-authentication. > > Hmmm, I think you got my point (this impression is confirmed later on in your reply) but a little bit partially perhaps: let me try and clarify it: I agree that in you current draft wording you can implement re-authentication without identity protection. However, you still implement identity protection within your re-authentication scheme because your require a fresh new re-authentication id [we are also discussing this point in this thread, but I'll assume this is our current position] to be used after each re-authentication, the re-auth id that you send encrypted. Hence, while wishing to implement only re-authentication, you still have to go in the trouble of managing different identities, which reminds me very strongly of the identity protection hassle ;-) I therefore meant, why not use as a reauth-id always the same one: the permanent id (or the pseudonym if is implemented) flagged in a way (it could be something like IMSI.reauth@jjj.nnn or decoration of the username, NAI we want) or even the ordinary id but with a flag included elsewhere in the EAP method packet saying "hey I want to fast reconnect" By the way, I think to avoid terminology conflicts we should swap from "re-authentication" to "fast reconnect" or "fast re-authentication" because "re-authentication" may very well mean full re-authentication... > > >>Since there seems to be no consensus on the necessity of identity >>protection whereas there should be one on reauthentication, >> >> > >I think there is demand for both features. TS 33.234 also includes >identity privacy. Perhaps not everyone wants to use both features, but >I wouldn't call that lack of consensus. Both features are optional and >they can be disabled if they are not considered necessary. >So I don't see any problems in having both features included in >the protocol as optional features. > > As said above, I do think you oblige someone wanting to implement only fast reconnect to also implement much of the identity protection mechanisms... > > >>why not try >>to provide a simple solution for reauthentication, a separate >>solution >>for identity protection and authorize the mixture of both solutions. >> >> > >Originally the reasons for having a separate re-authentication >identity were >1. peer can choose a suitable identity to indicate it wants to use re-authentication > > OK but also why not a flag elsewhere in the EAP packet? >2. server doesn't need to manage all temporary identities as "carefully" but >it can be "sloppier" with re-auth ids than pseudonyms. > > I am afraid I don't quite understand >3. single-use re-auth id's may also improve the security of the very short >two-message re-auth procedure. > > Could you please be more precise? >4. separate identities would allow an intermediate box, located closer to >the access network, to implement fast re-authentication. The AAA server >could delegate re-authentications to an intermediate proxy. >(I suppose this reason is not relevant currently.) > > OK, incidentally I am working on this also right now. I'll try and send a separate post on fast reconnect. >The server can generate re-authentication id's for example by concatenating >the IMSI and a random number, which would work as a flag to request for >re-authentication, so the overhead associated with identity privacy >management can be avoided. (The server needs to maintain some re-authentication >state information in any case if it wants to support re-authentication.) > > Why complicate things with this random number concatenation? My point: make it simpler, a constant flag or whatever... unless you have good reasons to want such a heavy mechanisms (not talking about the potential overhead but rather the real pain to stay synchronized) >In my opinion, the current design works fine. I suppose >there aren't any big problems that we must solve. We should avoid >making incompatible changes if they are not absolutely necessary. > > I understand. I'll try and get some feedback from our (some?) testers to see how they found identity protection and fast reconnect in their field trials. However, I see a compatible way to have the draft comply to my changes: allow the server to always use the same fast-reconnect id for a peer, allow even the peer to derive his fast-reconnect id on his own [i.e define a constant flagging of the permanent and pseudonym identity] (and allow a server not to resend this fast-reconnect id at each peer's fast reconnect if you care about unnecessary bandwidth consumption) What do you think of this ? _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Dec 18 03:07:11 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10361 for ; Thu, 18 Dec 2003 03:07:11 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 66A42580008; Thu, 18 Dec 2003 02:07:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id B7FC8580017; Thu, 18 Dec 2003 02:07:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4D903580017 for ; Thu, 18 Dec 2003 02:06:58 -0600 (CST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 67F46580008 for ; Thu, 18 Dec 2003 02:06:56 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 09:06:55 +0100 Received: from francetelecom.com ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 09:06:52 +0100 Message-ID: <3FE15FF1.40705@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: uri@bell-labs.com Cc: eap@frascone.com Subject: Re: [eap] Issue 179: proposed resolution reject References: <3FDEB702.2020002@francetelecom.com> In-Reply-To: <3FDEB702.2020002@francetelecom.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2003 08:06:52.0757 (UTC) FILETIME=[E5527850:01C3C53D] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Dec 2003 09:06:09 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit Resending it in plain text.
Apologies for the Html

Florent

BERSANI Florent FTRD/DTL wrote:
Hi Uri,

Browsing through the list of open issues on the EAP Keying Framework, I came across yours about the proposed AES-based EAP PRF.

Taking into account the discussions on the IPsec (see http://www.sandelman.ottawa.on.ca/ipsec/2003/03/msg00294.html for the beginning of the thread) and the CFRG mailing list (see http://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00161.html for the beginning of the thread) where renowned cryptographers (Hugo Krawczyk and Dave Wagner) made some good points IMO, I suggest this issue be rejected for two reasons:
  • First, it is not for now IMHO within the scope of the EAP Keying Framework to define such a mechanism ("Algorithms for key derivation or mechanisms for key transport are not specified in this document." as of version 02b);
  • Second, as stated above, your proposal did not (yet ;-)) reach consensus within the cryptographic community.
Regards,
Florent

P.S: I absolutely do not mean that such a proposal is not interesting: on the contrary, I think it very valuable to suggest secure key derivation functions (or PRNGs) based on frequent primitives (such as AES)... Indeed, I am currently working on a survey/further analysis of the existing schemes. If you want to follow this discussion off-line or on the CFRG (I do not think it belongs to the EAP mailing list), you are most welcome!
_______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Dec 18 03:11:10 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10508 for ; Thu, 18 Dec 2003 03:11:09 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 0592A58002F; Thu, 18 Dec 2003 02:11:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 4FA11580023; Thu, 18 Dec 2003 02:11:03 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id D006B580018 for ; Thu, 18 Dec 2003 02:10:42 -0600 (CST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by mail.frascone.com (Postfix) with ESMTP id 57812580023 for ; Thu, 18 Dec 2003 02:10:41 -0600 (CST) Received: from parmhs4.rd.francetelecom.fr ([10.193.117.63]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 09:10:40 +0100 Received: from francetelecom.com ([10.193.167.66]) by parmhs4.rd.francetelecom.fr with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 09:10:38 +0100 Message-ID: <3FE160D4.6080500@francetelecom.com> From: Florent Bersani User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: eap@frascone.com Subject: Re: [eap] Issue 179: proposed resolution reject References: <3FDEB702.2020002@francetelecom.com> <3FE15FF1.40705@francetelecom.com> In-Reply-To: <3FE15FF1.40705@francetelecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Dec 2003 08:10:38.0732 (UTC) FILETIME=[6C0384C0:01C3C53E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Dec 2003 09:09:56 +0100 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Content-Transfer-Encoding: 7bit BERSANI Florent FTRD/DTL wrote: > Resending it in plain text. > Apologies for the Html > > Florent > > BERSANI Florent FTRD/DTL wrote: > >> Hi Uri, >> >> Browsing through the list of open issues on the EAP Keying Framework, >> I came across yours about the proposed AES-based EAP PRF. >> >> Taking into account the discussions on the IPsec (see >> http://www.sandelman.ottawa.on.ca/ipsec/2003/03/msg00294.html for the >> beginning of the thread) and the CFRG mailing list (see >> http://www1.ietf.org/mail-archive/working-groups/cfrg/current/msg00161.html >> for the beginning of the thread) where renowned cryptographers (Hugo >> Krawczyk and Dave Wagner) made some good points IMO, I suggest this >> issue be rejected for two reasons: >> >> * First, it is not for now IMHO within the scope of the EAP >> Keying Framework to define such a mechanism ("Algorithms for >> key derivation or mechanisms for key transport are not >> specified in this document." as of version 02b); >> * Second, as stated above, your proposal did not (yet ;-)) reach >> consensus within the cryptographic community. >> >> Regards, >> Florent >> >> P.S: I absolutely do not mean that such a proposal is not >> interesting: on the contrary, I think it very valuable to suggest >> secure key derivation functions (or PRNGs) based on frequent >> primitives (such as AES)... Indeed, I am currently working on a >> survey/further analysis of the existing schemes. If you want to >> follow this discussion off-line or on the CFRG (I do not think it >> belongs to the EAP mailing list), you are most welcome! >> _______________________________________________ eap mailing list >> eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap > > _______________________________________________ eap mailing list > eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Dec 18 03:12:15 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10642 for ; Thu, 18 Dec 2003 03:12:10 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 84755580034; Thu, 18 Dec 2003 02:12:09 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5C28658002A; Thu, 18 Dec 2003 02:12:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 8A8B458002A for ; Thu, 18 Dec 2003 02:11:50 -0600 (CST) Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by mail.frascone.com (Postfix) with ESMTP id 07CA2580018 for ; Thu, 18 Dec 2003 02:11:48 -0600 (CST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id hBI8TEk26999; Thu, 18 Dec 2003 00:29:14 -0800 From: Bernard Aboba To: eap@frascone.com Cc: smb@research.att.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Subject: [eap] Issue 208: Physical Security Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Dec 2003 00:29:14 -0800 (PST) X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Issue 208: Physical Security Submitter name: Steve Bellovin Submitter email address: smb@research.att.com Date first submitted: 12/17/2003 Reference: Document: RFC 2284bis-07 Comment type: E Priority: S Section: Various Rationale/Explanation of issue: I'm not at all happy with the stress on "physical security" of links. The concept isn't defined in terms of properties, nor is the threat model clear. Many wired Ethernets, even switched ones, are not secure enough to meet what I believe to be the requirements here. [BA] It would appear that the term "physical security" adds little value to the document. What if we eliminated use of the term entirely? The option of cryptographic "security" as an alternative is very hard -- you can't do crypto without at least one end authenticating itself first. When I'm sitting in my favorite 802.11 hotspot, how do I know if I'm authenticating (at the pre-EAP level) to the hotspot or to the laptop on the table next to me? The implications here are that the requirements need to be spelled out much more carefully. 5.1 says that identity messages are "not protected". Again, what are the precise security requirements for the lower layers? [BA] It would appear that the term "not protected" is used synonymously with "cleartext" here. 5.2: there are no numeric codes, which creates internationalization problems. [BA] Not sure what is meant here; the Text-Data field uses UTF-8 encoding. [BA] Here are the proposed fixes: In Section 3.1, change: " [3] Lower layer security. EAP assumes that lower layers either provide physical security (e.g., wired PPP or IEEE 802 links) or support per-packet authentication, integrity and replay protection. EAP SHOULD NOT be used on physically insecure links (e.g., wireless or the Internet) where subsequent data is not protected by per-packet authentication, integrity and replay protection." To: " [3] Lower layer security. Lower layer support for per-packet authentication, integrity and replay protection and confidentiality for data traffic is RECOMMENDED. Where this is available, EAP methods supporting Key Derivation (see Section 7.2.1) can be used to provide dynamic keying material. This makes it possible to protect against the security threats such as data modification and spoofing (see Section 7.1 for a detailed threat model)." In Section 3.4, change: " After EAP authentication is complete, the peer will typically transmit data to the network via the authenticator. In order to provide assurance that the peer transmitting data is the same entity that successfully completed EAP authentication, the lower layer needs to bind per-packet integrity, authentication and replay protection to the original EAP authentication, using keys derived during EAP authentication. Alternatively, the lower layer needs to be physically secure. Otherwise it is possible for subsequent data traffic to be hijacked or replayed. As a result of these considerations, EAP SHOULD be used only when lower layers provide physical security for data (e.g., wired PPP or IEEE 802 links), or for insecure links, where per-packet authentication, integrity and replay protection is provided." To: " After EAP authentication is complete, the peer will typically transmit data to the network via the authenticator. In order to provide assurance that the peer transmitting data is the same entity that successfully completed EAP authentication, the lower layer needs to bind per-packet integrity, authentication and replay protection to the original EAP authentication, using keys derived during EAP authentication. Otherwise it is possible for subsequent data traffic to be hijacked or replayed." In Section 5.1, change: "Identity Requests and Responses are not protected, so from a privacy perspective it is preferable for an EAP method to include its own protected identity exchange." To: "Identity Requests and Responses are sent in cleartext, so from a privacy perspective it is preferable for an EAP method to include an identity exchange that supports authentication, integrity and replay protection and confidentiality." Change Section 7 to: "7. Security Considerations This section defines the threat model and security terms and describes the security claims section required in EAP method specifications. We then discuss threat mitigation." In Section 7.1, change: "On physically insecure networks, it is possible for an attacker to gain access to the physical medium. This enables a range of attacks, including the following:" To: "EAP was developed for use with dialup PPP [RFC1661] and was later adapted for use in wired IEEE 802 networks [IEEE-802] in [IEEE-802.1X]. Subsequently EAP has been proposed for use on wireless LAN networks, and over the Internet. In all these situations it is possible for an attacker to gain access to the link. For example, attacks on telephone infrastructure are documented in [DECEPTION]. An attacker with access to the link may carry out a number of attacks, including:" In Section 7.1, change: " Where EAP is used over wired networks, an attacker typically requires access to the physical infrastructure in order to carry out these attacks. However, where EAP is used over wireless networks, EAP packets may be forwarded by authenticators (e.g., pre-authentication) so that the attacker need not be within the coverage area of an authenticator in order to carry out an attack on it or its peers. Where EAP is used over the Internet, attacks may be carried out at an even greater distance." To: "Depending on the lower layer, these attacks may be carried out without requiring physical proximity. where EAP is used over wireless networks, EAP packets may be forwarded by authenticators (e.g., pre-authentication) so that the attacker need not be within the coverage area of an authenticator in order to carry out an attack on it or its peers. Where EAP is used over the Internet, attacks may be carried out at an even greater distance." In Section 7.2, delete: " [a] Intended use. This includes a statement of whether the method is intended for use over a physically secure or insecure network, as well as a statement of the applicable lower layers." In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use claim. In Section 7.5, change: " In the case of PPP and IEEE 802 wired links, it is assumed that such attacks are restricted to attackers who can gain access to the physical link. However, where EAP is run over physically insecure lower layers such as wireless (802.11 or cellular) or the Internet (such as within protocols supporting PPP, EAP or Ethernet Tunneling), this assumption is no longer valid and the vulnerability to attack is greater. To protect EAP messages sent over physically insecure lower layers, methods providing mutual authentication and key derivation, as well as per-packet origin authentication, integrity and replay protection SHOULD be used." To: " To protect EAP messages against modification or spoofing, methods providing mutual authentication and key derivation, as well as per-packet origin authentication, integrity and replay protection SHOULD be used." In Section 7.6, change: " In order to protect against dictionary attacks, an authentication algorithm resistant to dictionary attack (as defined in Section 7.2) SHOULD be used where EAP runs over lower layers which are not physically secure." To: "In order to protect against dictionary attacks, an authentication algorithm resistant to dictionary attack (as defined in Section 7.2) SHOULD be used." In Section 7.7, change: "With EAP methods supporting one-way authentication, such as EAP-MD5, the peer does not authenticate the authenticator. Where the lower layer is not physically secure (such as where EAP runs over wireless media or the Internet), the peer is vulnerable to a rogue authenticator. As a result, where the lower layer is not physically secure, a method supporting mutual authentication is RECOMMENDED." To: " With EAP methods supporting one-way authentication, such as EAP-MD5, the peer does not authenticate the authenticator, making the, peer is vulnerable to a rogue authenticator. To address this vulnerability, a method supporting mutual authentication is RECOMMENDED." In Section 7.11, change: " As a result, as noted in Section 3.1, where EAP is used over a physically insecure lower layer, per-packet authentication, integrity and replay protection SHOULD be used, and per-packet confidentiality is also recommended." To: " As a result, per-packet authentication, integrity and replay protection SHOULD be provided for data traffic, and per-packet confidentiality is RECOMMENDED." Change Section 7.12 to: "There exist a number of reliability and security issues with link layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs: [a] PPP. In PPP, link layer indications such as LCP-Terminate (a link failure indication) and NCP (a link success indication) are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the link. [b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are not authenticated or integrity protected. They can therefore be spoofed by an attacker with access to the link. [c] IEEE 802.11. In IEEE 802.11, link layer indications include Disassociate and Deauthenticate frames (link failure indications), and the first message of the 4-way handshake (link success indication). These messages are not authenticated or integrity protected, and although they are not forwardable, they are spoofable by an attacker within range. In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3 unicast data frames, and are therefore forwardable. This implies that while EAPOL-Start and EAPOL-Logoff messages may be authenticated and integrity protected, they can be spoofed by an authenticated attacker far from the target when "pre-authentication" is enabled. In IEEE 802.11 a "link down" indication is an unreliable indication of link failure, since wireless signal strength can come and go and may be influenced by radio frequency interference generated by an attacker. To avoid unnecessary resets, it is advisable to damp these indications, rather than passing them directly to the EAP. Since EAP supports retransmission, it is robust against transient connectivity losses." In Section 7.13, change: " [c] Where EAP is used over lower layers which are not physically secure, after completion of the EAP conversation, a secure association protocol SHOULD be run between the peer and authenticator in order to provide mutual authentication; guarantee liveness of the TSKs; provide protected ciphersuite and capabilities negotiation; synchronize key usage." To: " [c] After completion of the EAP conversation, a secure association protocol SHOULD be run between the peer and authenticator in order to provide mutual authentication; guarantee liveness of the TSKs; provide protected ciphersuite and capabilities negotiation; synchronize key usage." _______________________________________________ eap mailing list eap@frascone.com http://mail.frascone.com/mailman/listinfo/eap From eap-admin@frascone.com Thu Dec 18 03:15:45 2003 Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10783 for ; Thu, 18 Dec 2003 03:15:19 -0500 (EST) Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 9C42D580018; Thu, 18 Dec 2003 02:15:10 -0600 (CST) Received: from wolverine (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 5D32A580023; Thu, 18 Dec 2003 02:15:04 -0600 (CST) Delivered-To: eap@frascone.com Received: from localhost (wolverine [127.0.0.1]) by mail.frascone.com (Postfix) with ESMTP id 62C41580023 for ; Thu, 18 Dec 2003 02:14:23 -0600 (CST) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by mail.frascone.com (Postfix) with ESMTP id EFA9F580018 for ; Thu, 18 Dec 2003 02:14:20 -0600 (CST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8EEI15446 for ; Thu, 18 Dec 2003 10:14:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 10:14:13 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:14:12 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:14:12 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:14:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C53E.EA17E01C" Subject: RE: [eap] EAP-SIM v12 review Message-ID: Thread-Topic: [eap] EAP-SIM v12 review Thread-Index: AcPE1q1fPc4bdD/tRz+I7d8Fz5LtUAAYy4/Q From: To: Cc: X-OriginalArrivalTime: 18 Dec 2003 08:14:11.0611 (UTC) FILETIME=[EAE646B0:01C3C53E] X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) Sender: eap-admin@frascone.com Errors-To: eap-admin@frascone.com X-BeenThere: eap@frascone.com X-Mailman-Version: 2.0.13 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for EAP List-Unsubscribe: , List-Archive: Date: Thu, 18 Dec 2003 10:14:10 +0200 X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com) This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C53E.EA17E01C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Florent, =20 Thanks for your note. I'll be mainly out of office until Dec 29th,=20 so it may take me some time before I can reply in detail. =20 I like your proposal about the definition on nonce. Maybe we could = already state in the definition that in this protocol, all nonces are required = to be=20 random. =20 Best regards, Henry =20 -----Original Message----- From: ext Florent Bersani [mailto:florent.bersani@francetelecom.com] Sent: 17 December, 2003 21:47 To: Haverinen Henry (NES/Jyvaskyla) Cc: eap@frasone.com Subject: Re: [eap] EAP-SIM v12 review Henry, Thanks for taking the time to consider my contents :-) and happy/sorry = that your answer triggers some more ;-) Please see in-line. Florent henry.haverinen@nokia.com wrote: Florent, =20 Well, I'd rather have the relabeling to Random_MT and Random_S since=20 what matters to me is the future (the RFC and the people that=20 will read=20 it and download it for years ;-))=20 [..] =20 Pasi Eronen reminded me that the term "nonce" is quite widely used to denote a random number. Perhaps "nonce" does not have any commonly recognized clear meaning, but different documents use it to denote different things. =20 If I wouldn't fear that my humor be misunderstood, I'd quote you as per = your last e-mail: "The fact that something else is broken is not an excuse to make the = same mistake elsewhere." ;-) I agree that nonce is sometimes (often :-( ) misused and that its = meaning (and translation, for instance I don't know any appropriate in = French) may seem quite obscure. I also understand your reluctance to = relabel your random nonces. However, although you probably do know, let me point out, to be more = concrete, a precise cryptographic result which holds when the nonces are = random and doesn't when they aren't (i.e. when the nonces are = implemented as a counter): the theorem 4.4 of "Entity Authentication and = Key Distribution" by Mihir Bellare and Phillip Rogaway, abridged version = published at Crypto'93, full version available on Mihir's homepage ( = http://www-cse.ucsd.edu/users/mihir/papers/key-distribution.html). This = theorem does not hold, as discussed immediately after it being stated in = the paper, if the nonce are predictable (not random). Therefore my fear on the confusion between ordinary nonces and random = values :-( For example the IKEv2 terminology is similar to ours. So I'm inclined=20 to think we can keep these terms Nonce_MT and Nonce_S, especially=20 if we make sure they are referred to as random nonces, and the attribute = specifications clearly require choosing them randomly.=20 I don't think that would leave any excuses for an implementation that=20 uses a counter value as the Nonce_MT. :-) =20 To be constructive, if you really don't feel like relabeling the NONCES, = may I then suggest to add to the clear statement in the attribute saying = that NONCE X must be a random value, that you suggest and that is more = or less already there, a paragraph to section 2 defining Nonce and = warning the reader to check if the nonce must be random or not. Here's my proposed text: "Nonce: a value that is used at most once [or that is never repeated] = within the same cryptographic context. A nonce can be predictable (e.g. = a counter) or unpredictable (e.g. a random value). Since some = cryptographic properties may depend on the randomness of the nonce, = attention should be paid to whether a nonce is required to be random or = not." First, I do not see any recommendation stating that the server MUST=20 provide a fresh new re-auth identity for each re-authentication. It=20 seems to me that if the AAA server wanted to resend each time=20 the same=20 reauth id, he could do so (thus I recommend to add to Section 4.3.3,=20 page 26: after, "Re-authentication identities are one-time=20 identities":=20 "The server MUST provide a fresh new re-authentication=20 identity to the=20 peer different from the previous ones used within a same=20 reauthentication sequence").=20 =20 I suppose this depends on how seriously we want to take=20 the potential replay of EAP-Request/SIM/Reauthentication. As we noted before, the same problem is always present in=20 UMTS AKA too.=20 Anyway, I agree with your proposal. In this case there shouldn't be=20 any problems in adding such a statement, but using fresh identities=20 only seems to bring advantages. Could the keyword be SHOULD instead of MUST? =20 Yes indeed, I think so: see below =20 Moreover, I tend to think that, as it is=20 written, the document authorizes the server to accept an old=20 re-authentication identity since it says "If the server=20 recognizes the=20 re-authentication identity and agrees on using re-authentication".=20 Perhaps, a little guidance on the potential threats of a=20 laxist behavior=20 of the server, could help. =20 I agree we should explicitly require the server to only accept=20 the most recently issued re-authentication ID. I don't think the quoted sentence authorizes the server to accept an old re-authentication identity, but it only aims at describing the operation in case the peer uses a valid re-authentication identity.=20 =20 OK, I was thinking of something like "If the re-authentication identity = presented by the peer matches a valid re-authentication identity for the = server" instead of "recognizes, but if I am the only one to feel like = changing your wording, I won't be stubborn :-) Anyway, after thinking a little bit about the matter, I came to the=20 conclusion that identity protection and reauthentication are=20 orthogonal=20 matters. Reauthentication can easily be implemented without identity=20 protection, what do you think? =20 I agree, and the draft even doesn't require you to implement pseudonym support if you only want to support re-authentication. =20 Hmmm, I think you got my point (this impression is confirmed later on in = your reply) but a little bit partially perhaps: let me try and clarify = it: I agree that in you current draft wording you can implement = re-authentication without identity protection.=20 However, you still implement identity protection within your = re-authentication scheme because your require a fresh new = re-authentication id [we are also discussing this point in this thread, = but I'll assume this is our current position] to be used after each = re-authentication, the re-auth id that you send encrypted. Hence, while wishing to implement only re-authentication, you still have = to go in the trouble of managing different identities, which reminds me = very strongly of the identity protection hassle ;-) I therefore meant, why not use as a reauth-id always the same one: the = permanent id (or the pseudonym if is implemented) flagged in a way (it = could be something like IMSI.reauth@jjj.nnn or decoration of the = username, NAI we want) or even the ordinary id but with a flag included = elsewhere in the EAP method packet saying "hey I want to fast reconnect" By the way, I think to avoid terminology conflicts we should swap from = "re-authentication" to "fast reconnect" or "fast re-authentication" = because "re-authentication" may very well mean full re-authentication... =20 Since there seems to be no consensus on the necessity of identity=20 protection whereas there should be one on reauthentication,=20 =20 I think there is demand for both features. TS 33.234 also includes identity privacy. Perhaps not everyone wants to use both features, but I wouldn't call that lack of consensus. Both features are optional and=20 they can be disabled if they are not considered necessary.=20 So I don't see any problems in having both features included in=20 the protocol as optional features. =20 As said above, I do think you oblige someone wanting to implement only = fast reconnect to also implement much of the identity protection = mechanisms... =20 why not try=20 to provide a simple solution for reauthentication, a separate=20 solution=20 for identity protection and authorize the mixture of both solutions. =20 Originally the reasons for having a separate re-authentication=20 identity were 1. peer can choose a suitable identity to indicate it wants to use = re-authentication =20 OK but also why not a flag elsewhere in the EAP packet? 2. server doesn't need to manage all temporary identities as "carefully" = but it can be "sloppier" with re-auth ids than pseudonyms. =20 I am afraid I don't quite understand 3. single-use re-auth id's may also improve the security of the very = short two-message re-auth procedure. =20 Could you please be more precise? 4. separate identities would allow an intermediate box, located closer = to=20 the access network, to implement fast re-authentication. The AAA server could delegate re-authentications to an intermediate proxy. (I suppose this reason is not relevant currently.) =20 OK, incidentally I am working on this also right now. I'll try and send = a separate post on fast reconnect. The server can generate re-authentication id's for example by = concatenating the IMSI and a random number, which would work as a flag to request for re-authentication, so the overhead associated with identity privacy=20 management can be avoided. (The server needs to maintain some = re-authentication state information in any case if it wants to support re-authentication.) =20 Why complicate things with this random number concatenation? My point: make it simpler, a constant flag or whatever... unless you = have good reasons to want such a heavy mechanisms (not talking about the = potential overhead but rather the real pain to stay synchronized) In my opinion, the current design works fine. I suppose there aren't any big problems that we must solve. We should avoid making incompatible changes if they are not absolutely necessary. =20 I understand. I'll try and get some feedback from our (some?) testers to = see how they found identity protection and fast reconnect in their field = trials. However, I see a compatible way to have the draft comply to my changes: = allow the server to always use the same fast-reconnect id for a peer, = allow even the peer to derive his fast-reconnect id on his own [i.e = define a constant flagging of the permanent and pseudonym identity] (and = allow a server not to resend this fast-reconnect id at each peer's fast = reconnect if you care about unnecessary bandwidth consumption) What do you think of this ? ------_=_NextPart_001_01C3C53E.EA17E01C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Florent,
 
Thanks=20 for your note. I'll be mainly out of office until Dec 29th,=20
so=20 it may take me some time before I can reply in = detail.
 
I like=20 your proposal about the definition on nonce. Maybe we could=20 already
state=20 in the definition that in this protocol, all nonces are required to be=20
random.
 
Best=20 regards,
Henry
 
-----Original Message-----
From: ext Florent = Bersani=20 [mailto:florent.bersani@francetelecom.com]
Sent: 17 = December, 2003=20 21:47
To: Haverinen Henry (NES/Jyvaskyla)
Cc:=20 eap@frasone.com
Subject: Re: [eap] EAP-SIM v12=20 review

Henry,

Thanks for taking the time to = consider my contents :-) and happy/sorry that your answer triggers = some more=20 ;-)

Please see in-line.

Florent

henry.haverinen@nokia.com=20 wrote:
Florent,

  
Well, I'd rather have the =
relabeling to Random_MT and Random_S since=20
what matters to me is the future (the RFC and the people that=20
will read=20
it and download it for years ;-))=20
[..]
    

Pasi Eronen reminded me that the term "nonce" is quite widely
used to denote a random number. Perhaps "nonce" does not have
any commonly recognized clear meaning, but different documents
use it to denote different things.
If I wouldn't fear that my humor be misunderstood, = I'd=20 quote you as per your last e-mail:
"The fact that something else is = broken=20 is not an excuse to make the same mistake elsewhere." ;-)

I = agree that=20 nonce is sometimes (often :-( ) misused and that its meaning (and = translation,=20 for instance I don't know any appropriate in French) may seem quite = obscure. I=20 also understand your reluctance to relabel your random = nonces.

However,=20 although you probably do know, let me point out, to be more concrete, = a=20 precise cryptographic result which holds when the nonces are random = and=20 doesn't when they aren't (i.e. when the nonces are implemented as a = counter):=20 the theorem 4.4 of "Entity Authentication and Key Distribution" by = Mihir=20 Bellare and Phillip Rogaway, abridged version published at Crypto'93, = full=20 version available on Mihir's homepage (http://www-cse.ucsd.edu/users/mihir/papers/key-distribution.html).=20 This theorem does not hold, as discussed immediately after it being = stated in=20 the paper, if the nonce are predictable (not random).

Therefore = my fear=20 on the confusion between ordinary nonces and random values :-(
For example the IKEv2 terminology is =
similar to ours. So I'm inclined=20
to think we can keep these terms Nonce_MT and Nonce_S, especially=20
if we make sure they are referred to as random nonces, and the attribute =

specifications clearly require choosing them randomly.=20
I don't think that would leave any excuses for an implementation that=20
uses a counter value as the Nonce_MT. :-)
To be constructive, if you really don't feel like=20 relabeling the NONCES, may I then suggest to add to the clear = statement in the=20 attribute saying that NONCE X must be a random value, that you suggest = and=20 that is more or less already there, a paragraph to section 2 defining = Nonce=20 and warning the reader to check if the nonce must be random or=20 not.

Here's my proposed text:
"Nonce: a value that is used = at most=20 once [or that is never repeated] within the same cryptographic = context. A=20 nonce can be predictable (e.g. a counter) or unpredictable (e.g. a = random=20 value). Since some cryptographic properties may depend on the = randomness of=20 the nonce, attention should be paid to whether a nonce is required to = be=20 random or not."
First, I do not see any =
recommendation stating that the server MUST=20
provide a fresh new re-auth identity for each re-authentication. It=20
seems to me that if the AAA server wanted to resend each time=20
the same=20
reauth id, he could do so (thus I recommend to add to Section 4.3.3,=20
page 26: after, "Re-authentication identities are one-time=20
identities":=20
"The server MUST provide a fresh new re-authentication=20
identity to the=20
peer different from the previous ones used within a same=20
reauthentication sequence").=20
    

I suppose this depends on how seriously we want to take=20
the potential replay of EAP-Request/SIM/Reauthentication.
As we noted before, the same problem is always present in=20
UMTS AKA too.=20

Anyway, I agree with your proposal. In this case there shouldn't be=20
any problems in adding such a statement, but using fresh identities=20
only seems to bring advantages.
Could the keyword be SHOULD instead of MUST?
Yes indeed, I think so: see below
  
Moreover, I tend to think =
that, as it is=20
written, the document authorizes the server to accept an old=20
re-authentication identity since it says "If the server=20
recognizes the=20
re-authentication identity and agrees on using re-authentication".=20
Perhaps, a little guidance on the potential threats of a=20
laxist behavior=20
of the server, could help.
    

I agree we should explicitly require the server to only accept=20
the most recently issued re-authentication ID.

I don't think the quoted sentence authorizes the server
to accept an old re-authentication identity, but it only aims
at describing the operation in case the peer uses a valid
re-authentication identity.=20
OK, I was thinking of something like "If the=20 re-authentication identity presented by the peer matches a valid=20 re-authentication identity for the server" instead of "recognizes, but = if I am=20 the only one to feel like changing your wording, I won't be stubborn = :-)

    
Anyway, after thinking a =
little bit about the matter, I came to the=20
conclusion that identity protection and reauthentication are=20
orthogonal=20
matters. Reauthentication can easily be implemented without identity=20
protection, what do you think?
    

I agree, and the draft even doesn't require you to implement
pseudonym support if you only want to support re-authentication.
  
Hmmm, I think you got my point (this impression is=20
  confirmed later on in your reply) but a little bit partially perhaps: =
let me=20
  try and clarify it:

I agree that in you current draft wording =
you can=20
  implement re-authentication without identity protection. =


However, you=20
  still implement identity protection within your re-authentication =
scheme=20
  because your require a fresh new re-authentication id [we are also =
discussing=20
  this point in this thread, but I'll assume this is our current =
position] to be=20
  used after each re-authentication, the re-auth id that you send=20
  encrypted.

Hence, while wishing to implement only =
re-authentication,=20
  you still have to go in the trouble of managing different identities, =
which=20
  reminds me very strongly of the identity protection hassle =
;-)

I=20
  therefore meant, why not use as a reauth-id always the same one: the =
permanent=20
  id (or the pseudonym if is implemented) flagged in a way (it could be=20
  something like IMSI.reauth@jjj.nnn or =
decoration of the=20
  username, NAI we want) or even the ordinary id but with a flag =
included=20
  elsewhere in the EAP method packet saying "hey I want to fast=20
  reconnect"

By the way, I think to avoid terminology conflicts =
we should=20
  swap from "re-authentication" to "fast reconnect" or "fast =
re-authentication"=20
  because "re-authentication" may very well mean full =
re-authentication...

  
  

    
Since there seems to be no =
consensus on the necessity of identity=20
protection whereas there should be one on reauthentication,=20
    

I think there is demand for both features. TS 33.234 also includes
identity privacy. Perhaps not everyone wants to use both features, but
I wouldn't call that lack of consensus. Both features are optional and=20
they can be disabled if they are not considered necessary.=20
So I don't see any problems in having both features included in=20
the protocol as optional features.
  
As said above, I do think you oblige someone =
wanting to=20
  implement only fast reconnect to also implement much of the identity=20
  protection mechanisms...

  
  

    
why not try=20
to provide a simple solution for reauthentication, a separate=20
solution=20
for identity protection and authorize the mixture of both solutions.
    

Originally the reasons for having a separate re-authentication=20
identity were
1. peer can choose a suitable identity to indicate it wants to use =
re-authentication
  
OK but also why not a flag elsewhere in the EAP=20
  packet?

  
2. server doesn't need to manage all =
temporary identities as "carefully" but
it can be "sloppier" with re-auth ids than pseudonyms.
  
I am afraid I don't quite understand

  
3. single-use re-auth id's may also =
improve the security of the very short
two-message re-auth procedure.
  
Could you please be more precise?

  
4. separate identities would allow an =
intermediate box, located closer to=20
the access network, to implement fast re-authentication. The AAA server
could delegate re-authentications to an intermediate proxy.
(I suppose this reason is not relevant currently.)
  
OK, incidentally I am working on this also right =
now.=20
  I'll try and send a separate post on fast reconnect.

  
The server can generate re-authentication =
id's for example by concatenating
the IMSI and a random number, which would work as a flag to request for
re-authentication, so the overhead associated with identity privacy=20
management can be avoided. (The server needs to maintain some =
re-authentication
state information in any case if it wants to support re-authentication.)
  
Why complicate things with this random number=20
  concatenation?
My point: make it simpler, a constant flag or =
whatever...=20
  unless you have good reasons to want such a heavy mechanisms (not =
talking=20
  about the potential overhead but rather the real pain to stay=20
synchronized)

  
In my opinion, the current design works =
fine. I suppose
there aren't any big problems that we must solve. We should avoid
making incompatible changes if they are not absolutely necessary.
  
I understand. I'll try and get some feedback from =
our=20
  (some?) testers to see how they found identity protection and fast =
reconnect=20
  in their field trials.

However, I see a compatible way to have =
the=20
  draft comply to my changes: allow the server to always use the same=20
  fast-reconnect id for a peer, allow even the peer to derive his =
fast-reconnect=20
  id on his own [i.e define a constant flagging of the permanent and =
pseudonym=20
  identity] (and allow  a server not to resend this fast-reconnect =
id at=20
  each peer's fast reconnect if you care about unnecessary bandwidth=20
  consumption)

What do you think of this =
?


------_=_NextPart_001_01C3C53E.EA17E01C--
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Thu Dec 18 06:35:11 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15845
	for ; Thu, 18 Dec 2003 06:35:11 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 867E9580008; Thu, 18 Dec 2003 05:35:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id A379D580017; Thu, 18 Dec 2003 05:35:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id B968E580017
	for ; Thu, 18 Dec 2003 05:34:49 -0600 (CST)
Received: from mailgw.local.ipunplugged.com (unknown [213.80.52.78])
	by mail.frascone.com (Postfix) with ESMTP id 9FFB6580008
	for ; Thu, 18 Dec 2003 05:34:47 -0600 (CST)
Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44])
	by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id hBIBYjQe012761;
	Thu, 18 Dec 2003 12:34:45 +0100
From: Henrik Levkowetz 
To: Bernard Aboba 
Cc: eap@frascone.com, Jari Arkko 
Subject: Re: [eap] Issue 208: Physical Security
Message-Id: <20031218123444.591f7ec6.henrik@levkowetz.com>
In-Reply-To: 
References: 
X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg="pgp-sha1";
 boundary="Signature=_Thu__18_Dec_2003_12_34_44_+0100_vywYlNezw33bXs/P"
X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 12:34:44 +0100
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

--Signature=_Thu__18_Dec_2003_12_34_44_+0100_vywYlNezw33bXs/P
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Editorial nits:

> In Section 3.1, change:
> 
> " [3] Lower layer security. EAP assumes that lower layers either
> provide physical security (e.g., wired PPP or IEEE 802 links) or
> support per-packet authentication, integrity and replay
> protection. EAP SHOULD NOT be used on physically insecure links
> (e.g., wireless or the Internet) where subsequent data is not
> protected by per-packet authentication, integrity and replay
> protection."
> 
> To:
> 
> " [3] Lower layer security. Lower layer support for per-packet
> authentication, integrity and replay protection
> and confidentiality for data traffic is RECOMMENDED. Where
> this is available, EAP methods supporting Key Derivation
> (see Section 7.2.1) can be used to provide dynamic keying
> material. This makes it possible to protect against the
> security threats such as data modification and spoofing
> (see Section 7.1 for a detailed threat model)."

s/protect against the/protect against/

[...]

> In Section 7.7, change:
> 
> "With EAP methods supporting one-way authentication, such as EAP-MD5,
> the peer does not authenticate the authenticator. Where the lower
> layer is not physically secure (such as where EAP runs over wireless
> media or the Internet), the peer is vulnerable to a rogue
> authenticator. As a result, where the lower layer is not physically
> secure, a method supporting mutual authentication is RECOMMENDED."
> 
> To:
> 
> " With EAP methods supporting one-way authentication, such as EAP-MD5,
> the peer does not authenticate the authenticator, making the,
> peer is vulnerable to a rogue authenticator. To address this
> vulnerability, a method supporting mutual authentication is
> RECOMMENDED."

I'd suggest ending this paragraph with "it is RECOMMENDED to use a method
supporting mutual authentication."

[...]

> Change Section 7.12 to:
> 
> "There exist a number of reliability and security issues with link
> layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:
....

I'd suggest s/There exist/There exists/


	Henrik

--Signature=_Thu__18_Dec_2003_12_34_44_+0100_vywYlNezw33bXs/P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4ZDUeVhrtTJkXCMRAtevAKCLT9SIkpsaEsKuLASSE+tDBajAiQCg0fjZ
b5zohayOY9eSW14dDTBAE+Q=
=vvar
-----END PGP SIGNATURE-----

--Signature=_Thu__18_Dec_2003_12_34_44_+0100_vywYlNezw33bXs/P--
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Thu Dec 18 09:58:12 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25100
	for ; Thu, 18 Dec 2003 09:58:11 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 6005458002A; Thu, 18 Dec 2003 08:58:11 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 0295A580017; Thu, 18 Dec 2003 08:58:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 6590B580017
	for ; Thu, 18 Dec 2003 08:57:27 -0600 (CST)
Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107])
	by mail.frascone.com (Postfix) with ESMTP id 9589E580008
	for ; Thu, 18 Dec 2003 08:57:25 -0600 (CST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id hBIFEmG19217;
	Thu, 18 Dec 2003 07:14:49 -0800
From: Bernard Aboba 
To: Henrik Levkowetz 
Cc: eap@frascone.com, Jari Arkko 
Subject: Re: [eap] Issue 208: Physical Security
In-Reply-To: <20031218123444.591f7ec6.henrik@levkowetz.com>
Message-ID: 
References: 
 <20031218123444.591f7ec6.henrik@levkowetz.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 07:14:48 -0800 (PST)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

> s/protect against the/protect against/

Sure.

> I'd suggest ending this paragraph with "it is RECOMMENDED to use a method
> supporting mutual authentication."

OK.

> I'd suggest s/There exist/There exists/

OK.
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Thu Dec 18 10:40:10 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29594
	for ; Thu, 18 Dec 2003 10:40:10 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 5518B58002E; Thu, 18 Dec 2003 09:40:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id D4902580018; Thu, 18 Dec 2003 09:40:03 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id BB594580018
	for ; Thu, 18 Dec 2003 09:39:19 -0600 (CST)
Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107])
	by mail.frascone.com (Postfix) with ESMTP id 2565F580017
	for ; Thu, 18 Dec 2003 09:39:18 -0600 (CST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id hBIFugE21706;
	Thu, 18 Dec 2003 07:56:43 -0800
From: Bernard Aboba 
To: eap@frascone.com
Cc: smb@research.att.com, housley@vigilsec.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Strawman RFC2284bis-08 document available
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 07:56:42 -0800 (PST)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

Henrik has (with remarkable speed) provided a strawman -08 document with
the proposed resolutions to Issues 207 and 208 (raised by the IESG in
their review of RFC 2284bis-07) applied:

http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-08.c.txt

This does not yet include the application of three of the proposed
changes (in sections 7.12, 7.13, and 7.14)  When that is done, the result
will be available here:

http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-08.d.txt
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Thu Dec 18 10:57:13 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00462
	for ; Thu, 18 Dec 2003 10:57:09 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 88CB158002E; Thu, 18 Dec 2003 09:57:09 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 8864D580018; Thu, 18 Dec 2003 09:57:03 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 777F0580018
	for ; Thu, 18 Dec 2003 09:56:23 -0600 (CST)
Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107])
	by mail.frascone.com (Postfix) with ESMTP id EA734580017
	for ; Thu, 18 Dec 2003 09:56:18 -0600 (CST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id hBIGDXv22699
	for ; Thu, 18 Dec 2003 08:13:37 -0800
From: Bernard Aboba 
To: eap@frascone.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Proposed Resolution to Issue 208: Physical security
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 08:13:32 -0800 (PST)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

The text of Issue 208 is enclosed below.  The proposed resolution is as
follows:

In Section 3.1, change:

" [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay
protection."

To:

" [3] Lower layer security. Lower layer support for per-packet
authentication, integrity and replay protection
and confidentiality of data traffic is RECOMMENDED. Where
this is available, EAP methods supporting Key Derivation
(see Section 7.2.1) can be used to provide dynamic keying
material. This makes it possible to protect against
security threats such as data modification and spoofing
(see Section 7.1 for details)."

In Section 3.4, change:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP or
IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided."

To:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed."

In Section 5.1, change:

"Identity Requests and Responses are not protected, so
from a privacy perspective it is preferable for an EAP method to
include its own protected identity exchange."

To:

"Identity Requests and Responses are sent in cleartext, so
from a privacy perspective it is preferable for an EAP method to
include an identity exchange that supports authentication,
integrity and replay protection and confidentiality."

Change Section 7 to:

"7. Security Considerations

This section defines the threat model and security terms and
describes the security claims section required in EAP method
specifications. We then discuss threat mitigation."

In Section 7.1, change:

"On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:"

To:

"EAP was developed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X].  Subsequently EAP has been proposed for use on wireless
LAN networks, and over the Internet.  In all these situations it is
possible for an attacker to gain access to the link.  For example,
attacks on telephone infrastructure are documented in
[DECEPTION].

An attacker with access to the link may carry out a number of attacks,
including:"

In Section 7.1, change:

" Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an
even greater distance."

To:

"Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. where EAP is used
over wireless networks, EAP packets may be forwarded by
authenticators (e.g., pre-authentication) so that the attacker
need not be within the coverage area of an authenticator in
order to carry out an attack on it or its peers. Where EAP is
used over the Internet, attacks may be carried out at an
even greater distance."

In Section 7.2, delete:

" [a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use
claim.

In Section 7.5, change:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

To:

"To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

In Section 7.6, change:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

To:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used."

In Section 7.7, change:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

To:

" With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator.  To address this
vulnerability, it is RECOMMENDED to use a method supporting mutual
authentication."

In Section 7.11, change:

" As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

"In order to address this vulnerability, lower layers providing per-packet
authentication, integrity and replay protection, as well as
confidentiality are RECOMMENDED."

Change Section 7.12 to:

"There are reliability and security issues with link
layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link.

[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames
are not authenticated or integrity protected. They can therefore
be spoofed by an attacker with access to the link.

[c] IEEE 802.11. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way
handshake (link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed by an
authenticated attacker far from the target when
"pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can
come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses."

In Section 7.13, change:

" [c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."

To:

" [c] After completion of the EAP conversation, where the
lower layer supports security services such as
per-packet authentication,  integrity and replay protection
and confidentiality, a secure association protocol
SHOULD be run between the peer and authenticator
in order to provide mutual authentication;
guarantee liveness of transient session keys;
provide protected ciphersuite and
capabilities negotiation; and synchronize key usage."

In Section 7.14, change:

"   EAP does not support cleartext password authentication.  This
   omission is intentional.  Where EAP is carried over physically
   insecure lower layers, including wireless LANs [IEEE-802.11] or the
   Internet, use of cleartext passwords would allow the password to be
   captured by an attacker with access to the lower layer.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, even where the lower layer is physically
   secure, EAP frames may be subsequently encapsulated for transport
   over the Internet where they may be captured by an attacker."

To:

"  EAP does not support cleartext password authentication.  This
   omission is intentional.  Use of cleartext passwords would allow the
   password to be captured by an attacker with access to the link.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, EAP frames may be subsequently encapsulated
   for transport over the Internet where they may be captured by an
   attacker."

-------------------------------------------------------------------------
Issue 208: Physical Security
Submitter name: Steve Bellovin
Submitter email address: smb@research.att.com
Date first submitted: 12/17/2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-December/002013.html
Document:  RFC 2284bis-07
Comment type: Editorial
Priority: S
Section: Various
Rationale/Explanation of issue:

I'm not at all happy with the stress on "physical security" of links.
The concept isn't defined in terms of properties, nor is the threat
model clear. Many wired Ethernets, even switched ones, are not secure
enough to meet what I believe to be the requirements here.

The option of cryptographic "security" as an alternative is very hard
-- you can't do crypto without at least one end authenticating itself
first. When I'm sitting in my favorite 802.11 hotspot, how do I know
if I'm authenticating (at the pre-EAP level) to the hotspot or to the
laptop on the table next to me? The implications here are that the
requirements need to be spelled out much more carefully.

5.1 says that identity messages are "not protected". Again, what are
the precise security requirements for the lower layers?

5.2: there are no numeric codes, which creates internationalization
problems.

_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Thu Dec 18 14:30:31 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10447
	for ; Thu, 18 Dec 2003 14:30:27 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 1BD4058002A; Thu, 18 Dec 2003 13:30:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 24D1C580017; Thu, 18 Dec 2003 13:30:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 1F901580017
	for ; Thu, 18 Dec 2003 13:29:19 -0600 (CST)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by mail.frascone.com (Postfix) with ESMTP id 00E92580008
	for ; Thu, 18 Dec 2003 13:29:17 -0600 (CST)
Subject: Re: [eap] Issue 208: Physical Security
From: Alper Yegin 
To: Bernard Aboba , 
Cc: 
Message-ID: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 11:30:44 -0800
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit

> I'm not at all happy with the stress on "physical security" of links.
> The concept isn't defined in terms of properties, nor is the threat
> model clear. Many wired Ethernets, even switched ones, are not secure
> enough to meet what I believe to be the requirements here.
> 
> [BA] It would appear that the term "physical security" adds little value
> to the document.  What if we eliminated use of the term entirely?

Does this mean that we are eliminating the concept of physical security in
the context of EAP, and tighten the requirements accordingly? I think this
is not the intention, but I hope the modified language change does not
suggest that... At the end, I should still be able to use EAP-MD5 over my
DSL networks or wired Ethernet and not violate the spec.

> In Section 7.5, change:
> 
> " In the case of PPP and IEEE 802 wired links, it is assumed that such
> attacks are restricted to attackers who can gain access to the
> physical link. However, where EAP is run over physically insecure
> lower layers such as wireless (802.11 or cellular) or the Internet
> (such as within protocols supporting PPP, EAP or Ethernet Tunneling),
> this assumption is no longer valid and the vulnerability to attack is
> greater.
> 
> To protect EAP messages sent over physically insecure lower layers,
> methods providing mutual authentication and key derivation, as well
> as per-packet origin authentication, integrity and replay protection
> SHOULD be used."
> 
> To:
> 
> " To protect EAP messages against modification or spoofing,
> methods providing mutual authentication and key derivation, as well
> as per-packet origin authentication, integrity and replay protection
> SHOULD be used."

...

> 
> In Section 7.6, change:
> 
> " In order to protect against dictionary attacks, an authentication
> algorithm resistant to dictionary attack (as defined in Section 7.2)
> SHOULD be used where EAP runs over lower layers which are not physically
> secure."
> 
> To:
> 
> "In order to protect against dictionary attacks, an authentication
> algorithm resistant to dictionary attack (as defined in Section 7.2)
> SHOULD be used."

...

> In Section 7.13, change:
> 
> " [c] Where EAP is used over lower layers which are not physically
> secure, after completion of the EAP conversation, a secure
> association protocol SHOULD be run between the peer and
> authenticator in order to provide mutual authentication;
> guarantee liveness of the TSKs; provide protected ciphersuite and
> capabilities negotiation; synchronize key usage."
> 
> To:
> 
> " [c] After completion of the EAP conversation, a secure
> association protocol SHOULD be run between the peer and
> authenticator in order to provide mutual authentication;
> guarantee liveness of the TSKs; provide protected ciphersuite and
> capabilities negotiation; synchronize key usage."

The current text in the above segments suggest one does not have to obey the
requirement if EAP is run over physically secured links. The new text is
removing this condition. But I don't think the situation is any different,
right? It's just that we don't have a text saying that now...

I think working out the details of what physical security means and keeping
the term in the draft is a better approach.

Alper




_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Thu Dec 18 21:42:11 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07384
	for ; Thu, 18 Dec 2003 21:42:09 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id A6A12580008; Thu, 18 Dec 2003 20:42:09 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 8443C58002A; Thu, 18 Dec 2003 20:42:03 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 3F5BB58002A
	for ; Thu, 18 Dec 2003 20:41:12 -0600 (CST)
Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107])
	by mail.frascone.com (Postfix) with ESMTP id 03C5D580008
	for ; Thu, 18 Dec 2003 20:41:10 -0600 (CST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id hBJ2wTq28080;
	Thu, 18 Dec 2003 18:58:29 -0800
From: Bernard Aboba 
To: Alper Yegin 
Cc: eap@frascone.com
Subject: Re: [eap] Issue 208: Physical Security
In-Reply-To: 
Message-ID: 
References: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 18:58:29 -0800 (PST)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

> The current text in the above segments suggest one does not have to obey the
> requirement if EAP is run over physically secured links. The new text is
> removing this condition. But I don't think the situation is any different,
> right? It's just that we don't have a text saying that now...
>
> I think working out the details of what physical security means and keeping
> the term in the draft is a better approach.

I believe that Steve's point (which I agree with) is that "physical
security" is a term that is very hard to define.  For example, which of
the networks below is "physically secure":

* The Ethernet network in my home, which is entirely internal and
is protected by a rather large dog who has not eaten recently because
I am working late tonite.

* The Ethernet network in my neighbor's house, which includes a tap on the
outside porch.  The neighbors are away for the weekend.

* The wireless network at work which is located in a test lab within a
Faraday cage behind a locked door.

* The wireless network in a deserted neighborhood Starbucks, which has
closed down for the night (but whose network is still up).

* The ARCNet network which was installed 15 years ago and but is still
functioning in a legacy installation in the data center, but where
the night watchman has left the door open.

In practice, the term "physically secure" is one which applies to a
particular installation and set of practices, not to a particular
networking technology, so it is difficult to use prescriptively.

In most of the changes proposed in Issue 208, the removal of the term
"physical security" does not change the meaning of the draft at all, and
so those changes seem relatively straightforward.

The changes that are somewhat trickier is where the term is used as the
basis for some guidance as to what kind of EAP methods should be deployed,
or whether EAP should be used at all.

As Erik Nordmark discussed at IETF 56,  there is a need for prescriptive
guidance in particular situations.  For example, at IETF 56, Erik
recommended that IEEE 802.11i provide EAP WG with a document stating the
requirements for EAP methods used with IEEE 802.11 security.  If we assume
that such documents will be produced, then it isn't clear to me that we
necessarily need this kind of prescriptive guidance within RFC 2284bis
itself.  One approach might be to remove the normative language.

For example, Section 7.5 says:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

I think what these paragraphs are trying to say is that if you're
worried about an attacker gaining access to the link, then use an
EAP method that protects against that.  One way to get at this point
might be to say the following:

"To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
can be used."

Section 7.6 says:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

Again, I think the message is that if you're worried about dictionary
attacks, use an algorithm that deals with that.  One way to get at that
might be to say:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
can be used."

Section 7.7 says:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

In this particular paragraph, it strikes me that the issue is really
whether rogue authenticators are a concern or not.  If so, then
mutual authentication is important.  One way to get at this might be to
say:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator.  Where this
vulnerability is a concern, a method supporting
mutual authentication can be used."

Section 7.11 says:

"As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

Instead, we might say:

"In order to address this vulnerability, lower layers providing per-packet
confidentiality, authentication, integrity and replay protection
can be used. "
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Fri Dec 19 00:20:12 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11765
	for ; Fri, 19 Dec 2003 00:20:09 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 2C6AD58002E; Thu, 18 Dec 2003 23:20:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 3A5B058002A; Thu, 18 Dec 2003 23:20:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id C183A58002A
	for ; Thu, 18 Dec 2003 23:19:36 -0600 (CST)
Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107])
	by mail.frascone.com (Postfix) with ESMTP id 81154580008
	for ; Thu, 18 Dec 2003 23:19:34 -0600 (CST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id hBJ5arU04965;
	Thu, 18 Dec 2003 21:36:54 -0800
From: Bernard Aboba 
To: Alper Yegin 
Cc: eap@frascone.com
Subject: Re: [eap] Issue 208: Physical Security
In-Reply-To: 
Message-ID: 
References: 
 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Thu, 18 Dec 2003 21:36:53 -0800 (PST)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

How about this?

In Section 3.1, change:

" [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay
protection."

To:

" [3] Lower layer security.  EAP does not require
lower layers to provide security services such as
per-packet confidentiality, authentication, integrity and
replay protection.  However, where these security
services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic keying
material.  This makes it possible to bind the EAP authentication
to subsequent data and protect against
security threats such as data modification, spoofing, or replay
(see Section 7.1 for details)."

In Section 3.4, change:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP or
IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided."

To:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication.  Otherwise it is possible for subsequent data
traffic to be hijacked or replayed."

In Section 5.1, change:

"Identity Requests and Responses are not protected, so
from a privacy perspective it is preferable for an EAP method to
include its own protected identity exchange."

To:

"Identity Requests and Responses are sent in cleartext, so
from a privacy perspective it is preferable for an EAP method to
include an identity exchange that supports authentication,
integrity and replay protection and confidentiality."

Change Section 7 to:

"7. Security Considerations

This section defines the threat model and security terms and
describes the security claims section required in EAP method
specifications. We then discuss threat mitigation."

In Section 7.1, change:

"On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:"

To:

"EAP was developed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X].  Subsequently EAP has been proposed for use on wireless
LAN networks, and over the Internet.  In all these situations it is
possible for an attacker to gain access to the link.  For example,
attacks on telephone infrastructure are documented in
[DECEPTION].

An attacker with access to the link may carry out a number of attacks,
including:"

In Section 7.1, change:

" Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an
even greater distance."

To:

"Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. where EAP is used
over wireless networks, EAP packets may be forwarded by
authenticators (e.g., pre-authentication) so that the attacker
need not be within the coverage area of an authenticator in
order to carry out an attack on it or its peers. Where EAP is
used over the Internet, attacks may be carried out at an
even greater distance."

In Section 7.2, delete:

" [a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use
claim.

In Section 7.5, change:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

To:

"To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
can be used."

In Section 7.6, change:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

To:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
can be used."

In Section 7.7, change:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

To:

" With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the
peer vulnerable to attack by a rogue authenticator.  To address this
vulnerability, a method supporting mutual authentication
can be used. "

In Section 7.11, change:

" As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

"In order to address this vulnerability, lower layers providing per-packet
confidentiality, authentication, integrity and replay protection
can be used. "

Change Section 7.12 to:

"There are reliability and security issues with link
layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link.

[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames
are not authenticated or integrity protected. They can therefore
be spoofed by an attacker with access to the link.

[c] IEEE 802.11. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way
handshake (link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed by an
authenticated attacker far from the target when
"pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can
come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses."

In Section 7.13, change:

" [c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."

To:

"[c] After completion of the EAP conversation, where the
lower layer supports security services such as
per-packet confidentiality, authentication, integrity and replay
protection, a secure association protocol SHOULD be run between
the peer and authenticator in order to provide mutual authentication;
guarantee liveness of transient session keys;
provide protected ciphersuite and capabilities negotiation; and
synchronize key usage."

In Section 7.14, change:

"   EAP does not support cleartext password authentication.  This
   omission is intentional.  Where EAP is carried over physically
   insecure lower layers, including wireless LANs [IEEE-802.11] or the
   Internet, use of cleartext passwords would allow the password to be
   captured by an attacker with access to the lower layer.

   Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
   provide confidentiality, even where the lower layer is physically
   secure, EAP frames may be subsequently encapsulated for transport
   over the Internet where they may be captured by an attacker."

To:

"EAP does not support cleartext password authentication.  This
omission is intentional.  Use of cleartext passwords would allow the
password to be captured by an attacker with access to the link.

Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, EAP frames may be subsequently encapsulated
for transport over the Internet where they may be captured by an attacker."
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From rqkinfo@mail.com  Fri Dec 19 09:59:52 2003
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11078
	for ; Fri, 19 Dec 2003 09:59:51 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AXM6a-0005ZF-00
	for eap-archive@ietf.org; Fri, 19 Dec 2003 09:59:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AXM6Y-0005Z7-00
	for eap-archive@ietf.org; Fri, 19 Dec 2003 09:59:52 -0500
Received: from adsl-67-119-66-84.dsl.sntc01.pacbell.net
	([67.119.66.84] helo=ietf.org ident=MitreZzZ)
	by ietf-mx with smtp (Exim 4.12)
	id 1AXM64-0005W9-00; Fri, 19 Dec 2003 09:59:30 -0500
From: "Temas Patrulhados" 
To: drums-archive@ietf.org
Subject: Lindenberg: Emprego rural versus assentamentos                         ref.: zgj
X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
MIME-Version: 1.0
Content-Type: text/html
Message-Id: 
Date: Fri, 19 Dec 2003 09:59:30 -0500
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: Yes, hits=9.3 required=5.0 tests=FORGED_MUA_EUDORA,HTML_40_50,
	HTML_FONT_BIG,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,
	MAILTO_TO_REMOVE,MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,
	MIME_HTML_ONLY,MSGID_FROM_MTA_SHORT,REMOVE_REMOVAL_2WORD,
	SUBJ_HAS_SPACES autolearn=no version=2.60
X-Spam-Report: 
	*  1.0 SUBJ_HAS_SPACES Subject contains lots of white space
	*  0.5 REMOVE_REMOVAL_2WORD BODY: List removal information
	*  0.5 HTML_40_50 BODY: Message is 40% to 50% HTML
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.1 HTML_FONT_BIG BODY: HTML has a big font
	*  0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED
	*  0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
	*  0.1 LINES_OF_YELLING_2 BODY: 2 WHOLE LINES OF YELLING DETECTED
	*  0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset
	*  1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email
	*  0.0 MAILTO_TO_REMOVE URI: Includes a 'remove' email address
	*  3.3 MSGID_FROM_MTA_SHORT Message-Id was added by a relay
	*  1.9 FORGED_MUA_EUDORA Forged mail pretending to be from Eudora










rbi ConstruNews deseja a todos um feliz Natal!
 EnEspañol - InEnglish - Subscrever - Remover 

Série Temas Patrulhados 


Lindenberg: Emprego rural versus assentamentos


"Por que os agrorreformistas só falam em assentamentos e nunca na criação de empregos na área rural?"


* Patrulhamento


Adolpho Lindenberg é autor do livro "Os católicos e a economia de mercado", onde denuncia uma política com viés esquerdista que visa censurar, marginalizar ou encobrir com um manto de silêncio, notícias, opiniões e livros "politicamente incorretos", não afinados com as assim denominadas "causas sociais": os meios de comunicação, e a própria sociedade brasileira, estão sendo "patrulhados".


* Agrorreformistas


Em artigo "Emprego rural versus assentamentos", da Série Temas Patrulhados, Lindenberg pergunta:


- Por que os agrorreformistas só falam em assentamentos e nunca na criação de empregos na área rural? 


- Por que não reivindicam financiamentos ou outros estímulos à agroindústria ou a empresas rurais que empregam grande número de trabalhadores? 


- Por que não propõem modificações na legislação trabalhista para o campo de modo a permitir que os fazendeiros reconstruam as antigas colônias com casas razoáveis e terrenos destinados ao plantio de hortaliças, criação de porcos e galinhas etc.?


* Viés socialista


A resposta do autor é simples:


- Trata-se do velho viés marxista, a mentalidade socialista, denominador comum a todos os agrorreformistas! Na mentalidade marxista, o patrão é sempre visto como um explorador e o empregado como um semiescravo, humilhado e indefeso! Para pessoas de mentalidade esquerdista, o contraste entre o casario pobre de uma colônia e o casarão senhorial do fazendeiro, lembra feudalismo, desigualdade social gritante, injustiças de toda espécie. Xico Graziano, ex-presidente do Incra, confirma essa obsessão niveladora ao atribuir o desinteresse dos agrorreformistas pela qualidade e pelo custo da política de assentamentos "a uma razão de fundo ideológico, pois o pensamento agrarista tradicional sempre se interessou em penalizar o latifúndio, desapropriando-o". 


* Sonho aliciante


Haverá um sonho mais aliciante e semelhante ao velho utopismo socialista, do que um país onde todos têm sua terra para plantar, financiamentos com juros subsidiados, onde não existem patrões ou fiscais de qualquer espécie?, pergunta Lindenberg em seu artigo. E responde: Diante desse sonho utópico, o único recurso que nos resta é o apelo constante ao bom senso e à experiência acumulada durante séculos. De um modo muito empírico, quase a título exemplificativo, poder-se-ia alinhar algumas considerações atinentes à problemática:


- A condição empregatícia de si não tem absolutamente nada de humilhante ou de exploratório. As mais altas autoridades do país - o presidente, os ministros, magistrados do Supremo - são empregados. São igualmente empregados os professores, os oficiais superiores, os altos executivos que governam os grandes conglomerados econômicos e as multinacionais. 


- O importante para o trabalhador rural não é ser o dono da terra, como também para o morador de uma casa não é ser dono do imóvel. O importante é ganhar bem, poder progredir, sentir-se seguro no emprego, estar em condições de formar um pecúlio. Dono de um capital, o empregado pode decidir se compra a terra ou a casa, ou se investe num negócio ou se compra ações. Ele se tornou um minicapitalista. 


- Aliás, diga-se de passagem, o Brasil só terá se tornado um país verdadeiramente capitalista na medida em que boa parte de sua população seja proprietária de minicapitais. A esse respeito convém lembrar o exemplo dado pelos imigrantes japoneses. Considerados os agricultores mais bem sucedidos que já aportaram em nossas terras, eles sempre preferiram arrendar a comprar as várzeas nas quais plantaram suas hortas e isso com um sucesso absoluto.


- Que haja uma significativa diminuição do desemprego e do êxodo rural constitui um anseio nacional. Que os homens do campo, pequenos proprietários, assentados, bóias-frias consigam elevar seus padrões de vida a níveis aceitáveis constitui, igualmente uma meta a ser atingida. Esses objetivos não são, por conseguinte um monopólio dos agrorreformistas e, muito menos, um apanágio das esquerdas. No modo de solucionar essas carências é que se situam as diferenças.


* Outros temas


Outros temas abordados no artigo: Monteiro Lobato, a saúva e o sítio; condições para o éxito das pequenas propriedades; causas do enfraquecimento dos "liames feudais" entre fazendeiros e empregados; os descontentes e o "canto de sereia" dos agrorreformistas; o crescimento espetacular dos Tigres Asiáticos; os dois paradigmas básicos para o Brasil rural; e como evitar, no Brasil, o triunfo da utopia e da revolução social. Para receber gratuitamente o texto completo deste artigo, clique em: Lindenberg:DesejoReceberGratuitamenteEsteArtigo


LINKS DE OPINIÃO:


Entre aqueles que enviarem sua valiosa opinião a respeito do texto acima, até 31 de dezembro, usando qualquer um dos links seguintes, serão sorteados 10 exemplares impressos do livro "Os católicos e a economia de mercado". Os favorecidos serão comunicados por e-mail e deverão enviar o endereço postal para receberem os exemplares do livro, por Correio).


Lindenberg:Concordo (pode simplesmente enviar seu voto virtual, e acrescentar seu comentário caso desejar)


Lindenberg:Discordo (idem)


Lindenberg:MinhaOpinião (para enviar sua valiosa opinião, assim como sugerir a Lindenberg temas relacionados com a temática apresentada, a serem abordados em seus próximos artigos)


LINKS PARA ADQUIRIR O LIVRO


Lindenberg:DesejoAdquirirE-Book (para adquirir o livro, em formato Word, que será enviado por e-mail; clicando neste link receberá número de conta bancária para efetuar transferência; preço promocional do e-book, até 31 de dezembro: R$ 5,50)


Lindenberg:DesejoAdquirirLivroEmPortugal (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora em Portugal; preço: E 19,45)


Lindenberg:DesejoAdquirirLivroNoBrasil (receberá por e-mail o link para adquirir o livro impresso, diretamente da Editora no Brasil, com cartão de crédito ou boleto bancário; preço: R$ 30,00 mais Correio)


LINKS PARA RECEBER ARTIGOS GRATUITOS:


PaginasGratuitas (para receber gratuitamente, por e-mail, Índice e Introdução à edição brasileira do livro de Lindenberg)


GratuitamenteArtigosAnteriores


GratuitamenteProximosArtigos


GratuitamenteTodosOsArtigos


LINK DE REMOÇÃO


ConstruNews:Remover


LINK PARA TOMAR CONTATO COM LINDENBERG


Lindenberg:TomarContato (também pode ligar diretamente, se desejar, ao 11- 92527873, em São Paulo)


A difusão e o conteúdo desta mensagem são de exclusiva responsabilidade da ConstruNews






From eap-admin@frascone.com  Fri Dec 19 14:16:27 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20508
	for ; Fri, 19 Dec 2003 14:16:26 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id D18E858002E; Fri, 19 Dec 2003 13:14:09 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id AE05858002A; Fri, 19 Dec 2003 13:14:03 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id C461A580008
	for ; Fri, 19 Dec 2003 13:13:05 -0600 (CST)
Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214])
	by mail.frascone.com (Postfix) with ESMTP id 13A2A58002A
	for ; Fri, 19 Dec 2003 13:13:03 -0600 (CST)
Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190])
	by atlrel9.hp.com (Postfix) with ESMTP
	id 65C611C025C4; Fri, 19 Dec 2003 14:13:02 -0500 (EST)
Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186])
	by xatlrelay1.atl.hp.com (Postfix) with ESMTP
	id 596041C00A13; Fri, 19 Dec 2003 14:13:02 -0500 (EST)
Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2657.72)
	id ; Fri, 19 Dec 2003 14:13:02 -0500
Message-ID: 
From: "CONGDON,PAUL (HP-Roseville,ex1)" 
To: stds-802-1@ieee.org, eap@frascone.com
Cc: Jim Burns , Tony Jeffree 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] New EAP/802.1X interface variable proposal
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Fri, 19 Dec 2003 14:12:54 -0500
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)


A proposed resolution to the 802.1X/EAP interface issue 
related to discussions on EAP issues 204/205 and 
802.1X/D7.1 Ballot comment 15 was developed Dec 5th in a 
phone conference with EAP team members Bernard Aboba, Jari 
Arkko, Nick Petroni and 802.1X team members Jim Burns, Paul 
Congdon and Bob Moskowitz.  This memo attempts to document 
the proposal and solicit discussion that will lead to 
closure of this remaining issue for two nearly completed 
documents; 802.1X/D8 and RFC2284bis.

Background - The problem

The resolution of comment 15 on 802.1X/D7.1 uncovered an 
issue with rfc2284bis and the EAP state machine draft.  
Namely, the higher layer(EAP/AAA) is unable to inform the 
lower layer (1X) that its policy has been fully satisfied 
after only one role's state machine has run.  This also 
means that it is unable to inform the lower layer that its 
policy will only be satisfied if the other role's state 
machine is run.  

In addition, it was discovered that a pass-thru 
authenticator has no way of knowing if a peer has accepted 
a successful mutual authentication exchange since it is 
unaware of any protected indications returned by that peer.  
In contrast a standalone authenticator can be made aware of 
this because the EAP session is terminated locally.  
Consequently pass-thru and standalone configurations behave 
differently and this is not allowed or appropriate.

The ability of the higher layer to inform the lower layer 
when its policy is satisfied can be used to eliminate the 
need for a subsequent authentication exchange in the 
opposite direction.  Running two authentications in 
opposite directions of one another is often very difficult 
and not sufficient as pointed out by RFC 2284bis in section 
2.4. 

The fix for communicating the satisfaction of policy 
between the higher layer and lower layer is a new interface 
signal.  

The fix to ensure that the pass-thru authenticator does not 
behave differently than the standalone authenticator is a 
new RADIUS attribute.  The new RADIUS attribute is under 
development and will be documented in a forthcoming RFC.

The new interface signal is communicated across the AAA 
boundary to the EAP.  The signal indicates to the layer 
below that the policy of the higher layer is satisfied or 
not.

The RADIUS attribute is used by the authentication server 
to inform a pass-thru authenticator of policy satisfaction 
so it may drive this signal.  A standalone authenticator 
could drive this signal based upon local information.

The new interface signal is also made available at the 
802.1X interface and could be used to eliminate the need to 
initiate a second authentication in the opposite direction.  
Essentially this signal could be used to either force 
authorize the alternate role, or activate the Supplicant 
Access Control With Authenticator variable if it were not 
already activated.  As RFC 2284bis points out in 2.4 it is 
often neither desirable nor possible to initiate a second 
authentication in the opposite direction, nor is it 
necessary if the 1st authentication resulted in mutual 
authentication with protected indications (essentially what 
the new interface signal asserts).

It is important to note that the EAP layer, EAP methods and 
AAA layer run over transports other than 802.1X and this 
interface signal will be important for those transports as 
well.  This new signal will also need to be a consideration 
for future 802.1af work.

The Proposal

The EAP state machine draft will be updated to discuss this 
new indication.  Annex F of 802.1X documents the interface 
between the higher layers (EAP, EAP Methods, AAA Layer) and 
802.1X.  Annex F must include a definition of all signals 
that cross this interface.  This new signal should be 
included in this discussion.  

Additionally a short description of how this signal might 
be used to disable reverse authentications in the special 
case where both authenticator and supplicant are configured 
and active on a port.  It should reference section 2.4 of 
RFC 2284bis where this type of configuration is discussed 
for peer-to-peer scenarios.  A short discussion of this may 
also be needed in clause 6.7.

Proposed Changes to 802.1X/D8  (subject to the editor's 
judgment on wording and style):

Add clause F.2.8

F.2.8  eapRemoteSuccess

The higher layer will give this signal a value after 
eapSuccess is set.  This signal is ignored by the lower 
layer if eapFail is set.  If this signal is set following 
eapSuccess then the policy of the higher layer is 
completely satisfied and there is no need to carry out 
further authentication (no need to run the 1X authenticator 
machine).  If this signal is reset following setting of 
eapSuccess then the policy of the higher layer requires 
that another authentication (initiated by the 1X 
authenticator) must occur to satisfy the policy.  

This variable allows the higher layer to avoid initiating a 
second authentication session where the system would now 
act as authenticator and require the coupling of two 
independent authentications as described in 6.7.

If eapRemoteSuccess is set then Supplicants with this 
indication may choose to set the AuthControlledPortControl 
management variable to ForceAuthorize in order to avoid 
initiating the subsequent authentication.  If 
AuthControlledPortControl is set to ForceAuthorize, it must 
be set back to its original state if the supplicant state 
machine exits the authenticated state.

If eapRemoteSuccess is reset then Supplicants with this 
indication may choose to set the AuthControlledPortControl 
management variable to Auto to ensure the authenticator 
machine initiates the subsequent authentication.  

Note - Section 2.4 of RFC 2284bis describes several 
situations where coupling two authentications may be needed 
but is difficult to achieve.

Add clause F.3.10

F.3.10 eapRemoteSuccess 

The higher layer will give this signal a value after 
eapSuccess is set.  This signal is ignored by the lower 
layer if eapFail is set.  If this signal is set following 
eapSuccess then the policy of the higher layer is 
completely satisfied and there is no need to carry out 
further authentication (no need to run the 1X supplicant 
machine). If this signal is reset following setting of 
eapSuccess then the policy of the higher layer requires 
that another authentication (initiated by the 1X 
supplicant) must occur to satisfy the policy.  

This variable allows the higher layer to avoid or require a 
second authentication session where the system would now 
act as supplicant and require the coupling of two 
independent authentications as described in 6.7.

If eapRemoteSuccess is set then Authenticators with this 
indication may choose to set the SuppControlledPortControl 
management variable to ForceAuthorize or alternatively 
activate the Supplicant Access Control With Authenticator 
management control.  This will avoid initiating the 
subsequent authentication.    If either variable is set, it 
must be set back to its original state if the authenticator 
state machine exits the authenticated state. 

If eapRemoteSuccess is reset then Authenticators with this 
indication may choose to set the SuppControlledPortControl 
management variable to Auto or alternatively deactivate the 
Supplicant Access Control With Authenticator management 
control. This will cause the supplicant state machine to 
initiate the subsequent authentication.    

Note - Section 2.4 of RFC 2284bis describes several 
situations where coupling two authentications may be needed 
but is difficult to achieve.

Comments welcome,

Paul Congdon & Jim Burns
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Fri Dec 19 15:24:12 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24813
	for ; Fri, 19 Dec 2003 15:24:10 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 2ED96580008; Fri, 19 Dec 2003 14:24:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 2E98C58002A; Fri, 19 Dec 2003 14:24:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 1B0C258002A
	for ; Fri, 19 Dec 2003 14:23:19 -0600 (CST)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by mail.frascone.com (Postfix) with ESMTP id 2CA57580008
	for ; Fri, 19 Dec 2003 14:23:17 -0600 (CST)
Subject: Re: [eap] Issue 208: Physical Security
From: Alper Yegin 
To: Bernard Aboba 
Cc: 
Message-ID: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Fri, 19 Dec 2003 12:24:45 -0800
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit

> I believe that Steve's point (which I agree with) is that "physical
> security" is a term that is very hard to define.  For example, which of
> the networks below is "physically secure":
> 
> * The Ethernet network in my home, which is entirely internal and
> is protected by a rather large dog who has not eaten recently because
> I am working late tonite.
> 
> * The Ethernet network in my neighbor's house, which includes a tap on the
> outside porch.  The neighbors are away for the weekend.
> 
> * The wireless network at work which is located in a test lab within a
> Faraday cage behind a locked door.
> 
> * The wireless network in a deserted neighborhood Starbucks, which has
> closed down for the night (but whose network is still up).
> 
> * The ARCNet network which was installed 15 years ago and but is still
> functioning in a legacy installation in the data center, but where
> the night watchman has left the door open.
> 
> In practice, the term "physically secure" is one which applies to a
> particular installation and set of practices, not to a particular
> networking technology, so it is difficult to use prescriptively.

I think we could define "physically secure link" as a "link that is not
accessible by unintended hosts for transmitting and receiving any data
packets". The methods (not always based on technologies) to achieve this,
and its implementations, would vary. Just like they vary for
cryptographically secure links.

Of course, as in some of your examples above, there would be inappropriate
implementations or deployments of this as well. Just like there are for
crypto. security. 

> 
> In most of the changes proposed in Issue 208, the removal of the term
> "physical security" does not change the meaning of the draft at all, and
> so those changes seem relatively straightforward.

I was worried about the unintentional side effects.

> The changes that are somewhat trickier is where the term is used as the
> basis for some guidance as to what kind of EAP methods should be deployed,
> or whether EAP should be used at all.
> 
> As Erik Nordmark discussed at IETF 56,  there is a need for prescriptive
> guidance in particular situations.  For example, at IETF 56, Erik
> recommended that IEEE 802.11i provide EAP WG with a document stating the
> requirements for EAP methods used with IEEE 802.11 security.  If we assume
> that such documents will be produced, then it isn't clear to me that we
> necessarily need this kind of prescriptive guidance within RFC 2284bis
> itself.  One approach might be to remove the normative language.

I agree with that. The point we need to make in RFC 2284bis is that, the
choice of EAP method has to be based on the network environment. When
per-packet authentication, encryption, etc. is required an appropriate EAP
method must be chosen. We should not have to elaborate on where "per-packet
auth., encryption" is required. That shall be dealt separately.

It might very well be the case that I'm using a supposedly physically secure
network, but I'm hiring the security guards on the cheap side who are likely
to snooze once in a while, hence I might still prefer using an EAP method
that derives keys as additional protection.

> 
> For example, Section 7.5 says:
> 
> " In the case of PPP and IEEE 802 wired links, it is assumed that such
> attacks are restricted to attackers who can gain access to the
> physical link. However, where EAP is run over physically insecure
> lower layers such as wireless (802.11 or cellular) or the Internet
> (such as within protocols supporting PPP, EAP or Ethernet Tunneling),
> this assumption is no longer valid and the vulnerability to attack is
> greater.
> 
> To protect EAP messages sent over physically insecure lower layers,
> methods providing mutual authentication and key derivation, as well
> as per-packet origin authentication, integrity and replay protection
> SHOULD be used."
> 
> I think what these paragraphs are trying to say is that if you're
> worried about an attacker gaining access to the link, then use an
> EAP method that protects against that.  One way to get at this point
> might be to say the following:
> 
> "To protect EAP messages against modification or spoofing,
> methods providing mutual authentication and key derivation, as well
> as per-packet origin authentication, integrity and replay protection
> can be used."
> 
> Section 7.6 says:
> 
> "In order to protect against dictionary attacks, an authentication
> algorithm resistant to dictionary attack (as defined in Section 7.2)
> SHOULD be used where EAP runs over lower layers which are not physically
> secure."
> 
> Again, I think the message is that if you're worried about dictionary
> attacks, use an algorithm that deals with that.  One way to get at that
> might be to say:
> 
> "In order to protect against dictionary attacks, an authentication
> algorithm resistant to dictionary attack (as defined in Section 7.2)
> can be used."
> 
> Section 7.7 says:
> 
> "With EAP methods supporting one-way authentication, such as EAP-MD5,
> the peer does not authenticate the authenticator. Where the lower
> layer is not physically secure (such as where EAP runs over wireless
> media or the Internet), the peer is vulnerable to a rogue
> authenticator. As a result, where the lower layer is not physically
> secure, a method supporting mutual authentication is RECOMMENDED."
> 
> In this particular paragraph, it strikes me that the issue is really
> whether rogue authenticators are a concern or not.  If so, then
> mutual authentication is important.  One way to get at this might be to
> say:
> 
> "With EAP methods supporting one-way authentication, such as EAP-MD5,
> the peer does not authenticate the authenticator, making the
> peer vulnerable to attack by a rogue authenticator.  Where this
> vulnerability is a concern, a method supporting
> mutual authentication can be used."
> 
> Section 7.11 says:
> 
> "As a result, as noted in Section 3.1, where EAP is used over a
> physically insecure lower layer, per-packet authentication, integrity
> and replay protection SHOULD be used, and per-packet confidentiality
> is also recommended."
> 
> Instead, we might say:
> 
> "In order to address this vulnerability, lower layers providing per-packet
> confidentiality, authentication, integrity and replay protection
> can be used. "

OK, these make sense to me. It'd be better if RFC 2284bis does not get into
the business of guiding people about EAP method selection.

Alper
P.S: I'll be taking off soon for vacation. I might not be able to follow up
the thread for a while..... But I think we are in agreement anyways..


_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Fri Dec 19 15:33:12 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25113
	for ; Fri, 19 Dec 2003 15:33:11 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 8843558002F; Fri, 19 Dec 2003 14:33:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 419A258002A; Fri, 19 Dec 2003 14:33:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id CC59458002A
	for ; Fri, 19 Dec 2003 14:32:15 -0600 (CST)
Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225])
	by mail.frascone.com (Postfix) with ESMTP id 374C6580008
	for ; Fri, 19 Dec 2003 14:32:14 -0600 (CST)
Subject: Re: [eap] Issue 208: Physical Security
From: Alper Yegin 
To: Bernard Aboba 
Cc: 
Message-ID: 
In-Reply-To: 
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Fri, 19 Dec 2003 12:33:38 -0800
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit



> How about this?

This looks good, except at couple of points below.

> In Section 3.4, change:
> 
> " After EAP authentication is complete, the peer will typically
> transmit data to the network via the authenticator. In order to
> provide assurance that the peer transmitting data is the same entity
> that successfully completed EAP authentication, the lower layer needs
> to bind per-packet integrity, authentication and replay protection to
> the original EAP authentication, using keys derived during EAP
> authentication. Alternatively, the lower layer needs to be
> physically secure. Otherwise it is possible for subsequent data
> traffic to be hijacked or replayed.
> 
> As a result of these considerations, EAP SHOULD be used only when
> lower layers provide physical security for data (e.g., wired PPP or
> IEEE 802 links), or for insecure links, where per-packet
> authentication, integrity and replay protection is provided."
> 
> To:
> 
> " After EAP authentication is complete, the peer will typically
> transmit data to the network via the authenticator. In order to
> provide assurance that the peer transmitting data is the same entity
> that successfully completed EAP authentication, the lower layer needs
> to bind per-packet integrity, authentication and replay protection to
> the original EAP authentication, using keys derived during EAP
> authentication.  Otherwise it is possible for subsequent data
> traffic to be hijacked or replayed."


I'd drop the "using keys derived during EAP authentication." part. I can
rely on physical security for the binding.

> In Section 7.13, change:
> 
> " [c] Where EAP is used over lower layers which are not physically
> secure, after completion of the EAP conversation, a secure
> association protocol SHOULD be run between the peer and
> authenticator in order to provide mutual authentication;
> guarantee liveness of the TSKs; provide protected ciphersuite and
> capabilities negotiation; synchronize key usage."
> 
> To:
> 
> "[c] After completion of the EAP conversation, where the
> lower layer supports security services such as
> per-packet confidentiality, authentication, integrity and replay
> protection, a secure association protocol SHOULD be run between
> the peer and authenticator in order to provide mutual authentication;
> guarantee liveness of transient session keys;
> provide protected ciphersuite and capabilities negotiation; and
> synchronize key usage."

I think, we should either:
- change "SHOULD" to "MAY" or "can"; or
- "where the lower layer security services such as per-packet
confidentiality, authentication, integrity and replay protection will
to be enabled"

> 
> In Section 7.14, change:
> 
> "   EAP does not support cleartext password authentication.  This
>  omission is intentional.  Where EAP is carried over physically
>  insecure lower layers, including wireless LANs [IEEE-802.11] or the
>  Internet, use of cleartext passwords would allow the password to be
>  captured by an attacker with access to the lower layer.
> 
>  Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
>  provide confidentiality, even where the lower layer is physically
>  secure, EAP frames may be subsequently encapsulated for transport
>  over the Internet where they may be captured by an attacker."
> 
> To:
> 
> "EAP does not support cleartext password authentication.

I don't think this is an "EAP support" issue. This is just a matter of
defining an "EAP method". Unless we explicitly forbid design of such a
method, we should remove the above statement. I don't think this is for EAP
specification to decide. [I understand why it's a bad idea to have cleartext
passwords, but the above statement is confusing the role of EAP, EAP
methods, etc.]

> This
> omission is intentional.  Use of cleartext passwords would allow the
> password to be captured by an attacker with access to the link.
> 
> Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
> provide confidentiality, EAP frames may be subsequently encapsulated
> for transport over the Internet where they may be captured by an attacker."
> 

Thanks.

Alper

_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Fri Dec 19 16:03:13 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26341
	for ; Fri, 19 Dec 2003 16:03:11 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 895BA58002F; Fri, 19 Dec 2003 15:03:10 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 42F6D58002A; Fri, 19 Dec 2003 15:03:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id C1A3C58002A
	for ; Fri, 19 Dec 2003 15:02:28 -0600 (CST)
Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72])
	by mail.frascone.com (Postfix) with ESMTP id 0F2B0580008
	for ; Fri, 19 Dec 2003 15:02:27 -0600 (CST)
Received: from sj-core-2.cisco.com (171.71.177.254)
  by sj-iport-3.cisco.com with ESMTP; 19 Dec 2003 13:06:22 +0000
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68])
	by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBJL2LVM023070;
	Fri, 19 Dec 2003 13:02:22 -0800 (PST)
Received: from jsaloweyw2k01 ([10.21.83.210]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Fri, 19 Dec 2003 13:07:47 -0800
From: "Joseph Salowey" 
To: "'Alper Yegin'" ,
        "'Bernard Aboba'" 
Cc: 
Subject: RE: [eap] Issue 208: Physical Security
Message-ID: <004c01c3c673$65032730$0300000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: 
Importance: Normal
X-OriginalArrivalTime: 19 Dec 2003 21:07:47.0611 (UTC) FILETIME=[27678EB0:01C3C674]
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Fri, 19 Dec 2003 13:02:20 -0800
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: eap-admin@frascone.com [mailto:eap-admin@frascone.com] 
> On Behalf Of Alper Yegin
> Sent: Friday, December 19, 2003 12:34 PM
> To: Bernard Aboba
> Cc: eap@frascone.com
> Subject: Re: [eap] Issue 208: Physical Security
> 
> 
> 
> 
> > How about this?
> 
> This looks good, except at couple of points below.
> 
> > In Section 3.4, change:
> > 
> > " After EAP authentication is complete, the peer will typically 
> > transmit data to the network via the authenticator. In order to 
> > provide assurance that the peer transmitting data is the 
> same entity 
> > that successfully completed EAP authentication, the lower 
> layer needs 
> > to bind per-packet integrity, authentication and replay 
> protection to 
> > the original EAP authentication, using keys derived during EAP 
> > authentication. Alternatively, the lower layer needs to be 
> physically 
> > secure. Otherwise it is possible for subsequent data traffic to be 
> > hijacked or replayed.
> > 
> > As a result of these considerations, EAP SHOULD be used only when 
> > lower layers provide physical security for data (e.g., wired PPP or 
> > IEEE 802 links), or for insecure links, where per-packet 
> > authentication, integrity and replay protection is provided."
> > 
> > To:
> > 
> > " After EAP authentication is complete, the peer will typically 
> > transmit data to the network via the authenticator. In order to 
> > provide assurance that the peer transmitting data is the 
> same entity 
> > that successfully completed EAP authentication, the lower 
> layer needs 
> > to bind per-packet integrity, authentication and replay 
> protection to 
> > the original EAP authentication, using keys derived during EAP 
> > authentication.  Otherwise it is possible for subsequent 
> data traffic 
> > to be hijacked or replayed."
> 
> 
> I'd drop the "using keys derived during EAP authentication." 
> part. I can rely on physical security for the binding.

[Joe] I don't think this part should be removed.  You might make it
conditional, but then we must explain when it can be relaxed.  I think
there is some threat model in the document already that requires this.

> 
> > In Section 7.13, change:
> > 
> > " [c] Where EAP is used over lower layers which are not physically 
> > secure, after completion of the EAP conversation, a secure 
> association 
> > protocol SHOULD be run between the peer and authenticator 
> in order to 
> > provide mutual authentication; guarantee liveness of the 
> TSKs; provide 
> > protected ciphersuite and capabilities negotiation; synchronize key 
> > usage."
> > 
> > To:
> > 
> > "[c] After completion of the EAP conversation, where the 
> lower layer 
> > supports security services such as per-packet confidentiality, 
> > authentication, integrity and replay protection, a secure 
> association 
> > protocol SHOULD be run between the peer and authenticator 
> in order to 
> > provide mutual authentication; guarantee liveness of 
> transient session 
> > keys; provide protected ciphersuite and capabilities 
> negotiation; and
> > synchronize key usage."
> 
> I think, we should either:
> - change "SHOULD" to "MAY" or "can"; or
> - "where the lower layer security services such as per-packet 
> confidentiality, authentication, integrity and replay 
> protection will to be enabled"
> 
> > 
> > In Section 7.14, change:
> > 
> > "   EAP does not support cleartext password authentication.  This
> >  omission is intentional.  Where EAP is carried over physically  
> > insecure lower layers, including wireless LANs 
> [IEEE-802.11] or the  
> > Internet, use of cleartext passwords would allow the 
> password to be  
> > captured by an attacker with access to the lower layer.
> > 
> >  Since protocols encapsulating EAP, such as RADIUS 
> [RFC3579], may not  
> > provide confidentiality, even where the lower layer is physically  
> > secure, EAP frames may be subsequently encapsulated for transport  
> > over the Internet where they may be captured by an attacker."
> > 
> > To:
> > 
> > "EAP does not support cleartext password authentication.
> 
> I don't think this is an "EAP support" issue. This is just a 
> matter of defining an "EAP method". Unless we explicitly 
> forbid design of such a method, we should remove the above 
> statement. I don't think this is for EAP specification to 
> decide. [I understand why it's a bad idea to have cleartext 
> passwords, but the above statement is confusing the role of 
> EAP, EAP methods, etc.]
> 
> > This
> > omission is intentional.  Use of cleartext passwords would 
> allow the 
> > password to be captured by an attacker with access to the link.
> > 
> > Since protocols encapsulating EAP, such as RADIUS 
> [RFC3579], may not 
> > provide confidentiality, EAP frames may be subsequently 
> encapsulated 
> > for transport over the Internet where they may be captured by an 
> > attacker."
> > 
> 
> Thanks.
> 
> Alper
> 
> _______________________________________________
> eap mailing list
> eap@frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
> 

_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Fri Dec 19 17:24:09 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00174
	for ; Fri, 19 Dec 2003 17:24:08 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 7158D580008; Fri, 19 Dec 2003 16:24:09 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 9E46458002A; Fri, 19 Dec 2003 16:24:03 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 7393658002A
	for ; Fri, 19 Dec 2003 16:23:12 -0600 (CST)
Received: from old-n2.infonet.com (old-n2-130.infonet.com [192.157.130.138])
	by mail.frascone.com (Postfix) with ESMTP id 87008580008
	for ; Fri, 19 Dec 2003 16:23:10 -0600 (CST)
Received: from hubnotes1.infonet.com (hubnotes1 [198.137.76.56]) by old-n2.infonet.com  with ESMTP id hBJMHDY07318 for ; Fri, 19 Dec 2003 22:17:13 GMT
From: josh_mendel@infonet.com
To: eap@frascone.com
Message-ID: 
X-MIMETrack: Serialize by Router on HUBNOTES1/SVR/ISC(Release 6.0.2CF2|July 23, 2003) at
 12/19/2003 02:23:08 PM
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Josh Mendel/HQ/ISC is out of the office.
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Fri, 19 Dec 2003 14:23:05 -0800
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)





I will be out of the office starting  12/19/2003 and will not return until
01/05/2004.


_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Sun Dec 21 00:29:09 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02688
	for ; Sun, 21 Dec 2003 00:29:08 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id D8A68580008; Sat, 20 Dec 2003 23:29:09 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 5F60C580009; Sat, 20 Dec 2003 23:29:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 0E079580009
	for ; Sat, 20 Dec 2003 23:28:31 -0600 (CST)
Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107])
	by mail.frascone.com (Postfix) with ESMTP id 3E092580008
	for ; Sat, 20 Dec 2003 23:28:29 -0600 (CST)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id hBL5jep18322
	for ; Sat, 20 Dec 2003 21:45:40 -0800
From: Bernard Aboba 
To: eap@frascone.com
Message-ID: 
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Subject: [eap] Issue 209: Applicability statement
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Sat, 20 Dec 2003 21:45:40 -0800 (PST)
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)

Issue 209: Applicability statement
Submitter name: Allison MankinSubmitter
Email address: mankin@psg.com
Date first submitted: 12/18/2003
Reference:
Document:  RFC 2284bis-07
Comment type: E
Priority: S
Section: 1.3
Rationale/Explanation of issue:

I think there are many virtues to this spec, but it needs more attention
to the applicability description. The problem is epitomized by comments such
as:

   Where transport efficiency is a consideration, and IP transport is
   available, it may be preferable to expose an artificially high EAP
   MTU to EAP and allow fragmentation to take place in IP.
   Alternatively, it is possible to choose other security mechanisms
   such as TLS [RFC2246] or IKE [RFC2409] or an alternative
   authentication framework such as SASL [RFC2222] or GSS-API [RFC2743].

How could the same application use GSS-API or SASL if it intended to use
EAP

They seem to have very different domains of applicability.  It would be
good to discuss the ways that EAP is very applicable and ways in which it can
be kind of wedged into use, with results that may be only just satisfactory.
_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From eap-admin@frascone.com  Mon Dec 22 15:37:11 2003
Received: from mail.frascone.com (postfix@adsl-66-137-237-100.dsl.rcsntx.swbell.net [66.137.237.100])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06640
	for ; Mon, 22 Dec 2003 15:37:10 -0500 (EST)
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id 095B558002F; Mon, 22 Dec 2003 14:37:11 -0600 (CST)
Received: from wolverine (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP
	id BB814580016; Mon, 22 Dec 2003 14:37:04 -0600 (CST)
Delivered-To: eap@frascone.com
Received: from localhost (wolverine [127.0.0.1])
	by mail.frascone.com (Postfix) with ESMTP id 7FA53580016
	for ; Mon, 22 Dec 2003 14:36:12 -0600 (CST)
Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74])
	by mail.frascone.com (Postfix) with ESMTP id 67035580008
	for ; Mon, 22 Dec 2003 14:36:06 -0600 (CST)
Received: from user-0vvdc4s.cable.mindspring.com ([63.246.176.156] helo=wouterhp)
	by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 1AYWmW-0006cH-00
	for eap@frascone.com; Mon, 22 Dec 2003 12:36:00 -0800
From: "Wouter Habraken" 
To: 
Subject: RE: [eap] draft-urien-eap-smartcard-03.txt
Message-ID: <009401c3c8cb$ff0a7ea0$4101a8c0@raak.local>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: 
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Sender: eap-admin@frascone.com
Errors-To: eap-admin@frascone.com
X-BeenThere: eap@frascone.com
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: 
List-Post: 
List-Subscribe: ,
	
List-Id: Discussion list for EAP 
List-Unsubscribe: ,
	
List-Archive: 
Date: Mon, 22 Dec 2003 14:41:37 -0600
X-Virus-Scanned: by AMaViS 0.3.12 (frascone.com)
Content-Transfer-Encoding: 7bit

My comments below:

> Here are some questions about draft-urien-eap-smartcard-03.txt.
> 
> The subscriber profile is a service that can be used to 
> retrieve the EAP 
> types that the smart card implements, right? I suppose the 
> supplicant software can easily enumerate the all the EAP 
> methods that are available 
> beforehand. But I find it confusing that the draft talks 
> about identity selection 
> rather than EAP type selection. Shouldn't the supplicant 
> software select the active EAP method rather than an identity? 

There seems to be a misunderstanding about the role for the smart card.
With EAP-SMARTCARD the smart card holds the user identities and
credentials as well as the applets executing specific EAP methods. The
EAP "switch" is on the smart card. The identity is controlled by the
smart card and the EAP type flows from the choice of the identity and
the associated credentials. The selection of the preferred identity
establishes the authentication context for the card, but doesn't control
the identity.

> Maybe the subscriber profile could contain a short description of 
> the EAP method so that could be shown by the supplicant UI.
> 
The identity profile does already include the associated EAP method.
However it is unclear to me why this would be shown to the user.

> Have you considered EAP method negotiation in cases when
> some methods are implemented by the smart card and others by 
> supplicant software? I think this topic deserves some 
> discussion in this draft

Agreed, it is important. The focus of EAP-SMARTCARD has been on
providing a self contained EAP functionality. However, integrating the
EAP-SMARTCARD into a software EAP stack is important. Such an EAP stack
can call EAP-SMARTCARD, or can access the EAP methods directly. For
example, the software could access TLS via CAPI-CSP, SIM via EAP-SIM,
and WLAN-SIM via a WLAN-SIM compatible handler. Already there are
processes for identifying which methods are available on a card. The
WLAN smart card consortium is planning to publish a "handler"
specification to make this process easier (initially for WLAN-SIM). This
spec will also provide a default negotiation process to ensure card
interoperability.

> 
> If the supplicant first tries a software EAP method, and 
> later receives 
> an EAP request of some other type, the software could forward 
> the EAP request to the smart card. In this case, does the 
> terminal first need to cycle the identities to find the 
> correct EAP type, or can the EAP packet be directly forwarded 
> to the card?

It can be directly forwarded to the card. EAP-SMARTCARD makes the
association.

> 
> If the smart card method is not the first method to try 
> during EAP method negotiation, then there might not be an EAP 
> identity round at all, so the smart card authentication 
> should start directly with an EAP request other than 
> identity. So it should be possible to by-pass the identity 
> services. Or does the supplicant software need to fake an EAP 
> identity request and then ignore the response in order 
> to get the smart card's state initialized?

No, the process can start with any EAP request. No identity calls are
needed, and in fact would reset the smart card EAP state machine. If the
EAP Stack is handling method negotiation in this way though, it would
presumably call the EAP methods directly as described above.

- Wouter

Wouter Habraken
whabraken@raaktechnologies.com
Tel: 512 380 0765
Mob: 512 698 9341


_______________________________________________
eap mailing list
eap@frascone.com
http://mail.frascone.com/mailman/listinfo/eap


From hbepress@mail.com  Tue Dec 30 05:24:24 2003
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18348
	for ; Tue, 30 Dec 2003 05:24:19 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbH2w-0000h6-00
	for eap-archive@ietf.org; Tue, 30 Dec 2003 05:24:18 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
	id 1AbH1J-0000bL-00
	for eap-archive@ietf.org; Tue, 30 Dec 2003 05:22:39 -0500
Received: from [65.246.255.50] (helo=mx2.foretec.com)
	by ietf-mx with esmtp (Exim 4.12)
	id 1AbGzL-0000TG-00; Tue, 30 Dec 2003 05:20:35 -0500
Received: from [61.236.238.72] (helo=ietf.org)
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1AbGzJ-00068n-Ts; Tue, 30 Dec 2003 05:20:35 -0500
From: "O pequeno Lucas:" 
To: disman-request@ietf.org
Subject: Um exemplo para o Brasil                                  ref.: lot
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
MIME-Version: 1.0
Content-Type: text/html
Message-Id: 
Date: Tue, 30 Dec 2003 05:20:35 -0500
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on 
	ietf-mx.ietf.org
X-Spam-Status: Yes, hits=6.1 required=5.0 tests=AWL,FORGED_MUA_OUTLOOK,
	FORGED_OUTLOOK_HTML,HTML_20_30,HTML_FONT_BIG,HTML_MESSAGE,
	MAILTO_TO_SPAM_ADDR,MIME_HTML_NO_CHARSET,MIME_HTML_ONLY,
	SUBJ_HAS_SPACES autolearn=no version=2.60
X-Spam-Report: 
	*  1.0 SUBJ_HAS_SPACES Subject contains lots of white space
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.1 HTML_FONT_BIG BODY: HTML has a big font
	*  0.5 HTML_20_30 BODY: Message is 20% to 30% HTML
	*  0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
	*  0.7 MIME_HTML_NO_CHARSET RAW: Message text in HTML without charset
	*  1.1 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email
	*  1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only
	*  1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook
	*  0.0 AWL AWL: Auto-whitelist adjustment










sxs Feliz Ano Novo para você e família! Atenciosamente, Ferreira Passos, Atualidade Brasileira. Lucas:EnCastellano Lucas:InEnglish ProximosEnvios:SoloEnCastellano NextMessages:OnlyInEnglish 

Dez. 29, 2003: Atualidade Brasileira, Rio de Janeiro.


O pequeno Lucas: um exemplo para o Brasil


Deu seu último suspiro segurando com suas mãozinhas um Menino Jesus e uma Medalha Milagrosa, e partiu para celebrar seu primeiro Natal no Céu


Lucas da Rocha Silva nasceu em São Paulo, no bairro industrial de Itaquera, zona leste da cidade, em 28 de novembro de 1994. Foi ele crescendo normalmente, como todas as crianças de sua idade, quando, na madrugada de 1o. de novembro de 2000, próximo a completar 6 anos, acordou com fortes dores na tíbia de sua perninha esquerda. Começava a trilhar uma dolorosa e inesperada via crucis que a Providencia, em seus misteriosos desígnios, lhe tinha reservado, e que ele aceitaria de maneira exemplar, até seu falecimento em 15 de dezembro de 2003.


Um exame de raios-x indicou uma fratura no local da dor, o que levou os médicos a engessarem sua perna por um mês. Mas a dor ia aumentando. O pequeno pegava então o seu tercinho, dizendo que rezaria Ave-Marias "até a dor passar". Conseguia assim adormecer, mas, no dia seguinte, seu drama recomeçava.


Em março de 2001, uma biopsia feita no Hospital Santa Marcelina indicou um tumor na tíbia. Passou a ser atendido no Instituto de Oncologia Pediátrica, do Hospital São Paulo, onde foi submetido pouco depois a um implante de ossos, para tentar deter o avanço do tumor; mas este se expandiu para o joelho, e depois para o fêmur, obrigando a mais duas cirurgias, a última das quais, em abril de 2003, lhe amputou a perninha esquerda.


O pequeno Lucas foi aceitando todos esses sofrimentos com admirável espírito cristão, como vindos da vontade de Deus, sem jamais se deixar abater, nem reclamar pelas dores ou pelo seu infortúnio. Disto são testemunhas seu pai, Carlos Alberto Gil da Silva, 39; sua mãe, da. Maria Aparecida da Rocha Silva, 36; seu irmão Klayton, 14; seu melhor amiguinho, Luizinho; seus familiares; médicos; professores; coleguinhas; vizinhos, e todos quantos o conheceram.


Desde a primeira cirurgia, precisou acordar três vezes por semana às 5.30 hs. da manhã, para ir ao Hospital e ser examinado pela sua médica, além de submeter-se a sessões de quimioterapia, radioterapia, e outros exames. Lá, enquanto aguardava o atendimento, costumava, com sua conversa alegre e animada, e participando de jogos, estimular outras crianças com doenças similares, que compreensivelmente se encontravam abatidas e tristes. Ainda com sua perninha amputada, ele deu um jeito de continuar a jogar bola e andar de bicicleta. Às vezes, quando o atendimento atrasava e o relógio estava perto do meio-dia, procurava sua médica e lhe dizia: "Por favor, me chama logo, tia, que preciso ir à escola". Seu senso do dever fez com que, até o final, continuasse a ir à escola, onde obteve sempre notas acima de 8.


O esforço de seus médicos, e as cirurgias, não impediram que, a partir de abril de 2003, o implacável tumor se alastrasse por seu debilitado organismo, passando do fêmur aos pulmões, e daí, ao maxilar e ao pescoço; o que foi multiplicando seus sofrimentos, pois agora sentia dificuldades para falar, se alimentar e mesmo respirar.


Em setembro de 2003, enquanto Lucas aguardava para efetuar um dos intermináveis exames e tratamentos, uma alma caridosa lhe deu de presente uma Medalha de Nossa Senhora das Graças, a Medalha Milagrosa, que passou a usar continuamente, com piedade sincera, até os últimos instantes de sua breve vida terrena, que já se aproximavam. Também ganhou um livrinho com a historia de Nossa Senhora de Fátima e dos três pastorinhos videntes, e ficou assim sabendo que um deles, Jacinta, falecera sendo ainda uma criança. Todas as noites, o pequeno Lucas pedia à sua mãe para ler algumas páginas desse livrinho; depois, rezava a Oração ao Anjo da Guarda e adormecia.


Algumas semanas antes do Natal, Lucas ganhou também um pequeno Menino Jesus na manjedoura, que recebeu com devoção e alegria, dizendo serenamente a seus pais que este Natal ele o passaria no Céu junto com seu avô paterno, que falecera alguns meses antes. De fato, seu corpo já não mais agüentava a quimioterapia e a radioterapia, que foram suspensas em novembro de 2003. Então seus pais convocaram os familiares e amigos para, na igreja de Dom Bosco, perto de seu lar, anunciar-lhes que os médicos já nada mais podiam fazer: seu filho agora estava inteiramente nas mãos de Deus e de Nossa Senhora. O menino, perto do altar, ouviu tudo com o rosto sereno, ao mesmo tempo decidido e resignado, com a mesma cristã serenidade e resignação que tivera desde o começo de sua doença, sem jamais reclamar de sua situação ou de suas enormes dores.


Na noite de 13 de dezembro, Lucas teve um agravamento de seus problemas respiratórios, devendo ser levado com urgência ao Instituto de Oncologia Pediátrica. Em sua escrivaninha, ele deixava, em perfeita ordem, "santinhos" de Maria Auxiliadora, Dom Bosco, Santa Madre Paulina, Beato Frei Galvão, Sta. Rita de Cássia, São Benedito, Santo Expedito e a Novena de Nossa Senhora das Graças, sua devoção preferida.


Só levou consigo ao Hospital, como seus mais valiosos tesouros, a Medalha Milagrosa e o pequeno Menino Jesus. Em 14 de dezembro, domingo, recebeu de mãos de seu Pároco a Unção dos Enfermos. No dia seguinte, de manhã, cada vez com maiores dificuldades para respirar, entrou em agonia. Sempre lúcido, continuava segurando com suas mãozinhas a Medalha Milagrosa e o Menino Jesus. Percebendo que as forças o abandonavam, conseguiu sussurrar com dificuldade: "Mãe, me ajude a segurar o Menino Jesus..." Pouco depois, dava seu último suspiro. 


O Menino Jesus, sem dúvida, retribuiu o afeto dessa alma inocente, levando-o consigo para passar o primeiro Natal no Céu. 


Para Deus não existem heróis anônimos; mais ainda, Ele muitas vezes nos dá a possibilidade de conhecer essas vidas, para nossa edificação, e para nos ajudar, com seus exemplos, a enfrentar as enormes dificuldades do dia-a-dia. O pequeno Lucas foi um herói, apesar de ter só 9 anos: por sua fé, e pela inteira aceitação do misterioso e luminoso caminho da dor que a Providencia lhe preparou, trilhando os passos do Divino Mestre. O pequeno Lucas é, neste sentido, um grande exemplo para o Brasil. 


Gonçalo Guimarães, autor deste artigo, é jornalista.


LINKS:


Para enviar uma mensagem aos pais e irmão do pequeno Lucas, clique em:


FamiliaDoLucas:MinhaMensagem


Para enviar ao autor do artigo sua valiosa opinião, clique aqui: ArtigoSobreLucas:MinhaOpiniao


Para receber gratuitamente, por e-mail, duas fotos de Lucas (uma com 6 anos, e outra, com 9, poucos dias antes de falecer), clique aqui:


DesejoReceberFotosDeLucas


Para ser retirado de nosso Address Book, clique em:


RetirarDoAddresBook


Nota: este artigo pode ser reproduzido parcial ou totalmente, de preferência, citando a fonte: Atualidade Brasileira.