From owner-ietf-ppp@merit.edu Mon Oct 1 07:05:23 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10938 for ; Mon, 1 Oct 2001 07:05:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE22491245; Mon, 1 Oct 2001 07:05:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DE6D91247; Mon, 1 Oct 2001 07:05:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D3A891245 for ; Mon, 1 Oct 2001 07:05:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E9F75DDA0; Mon, 1 Oct 2001 07:05:44 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id BFFE75DD8C for ; Mon, 1 Oct 2001 07:05:43 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10893; Mon, 1 Oct 2001 07:04:40 -0400 (EDT) Message-Id: <200110011104.HAA10893@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-josefsson-pppext-eap-tls-eap-01.txt Date: Mon, 01 Oct 2001 07:04:40 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Protected Extensible Authentication Protocol (PEAP) Author(s) : H. Andersson, S. Josefsson, G. Zorn, B. Aboba Filename : draft-josefsson-pppext-eap-tls-eap-01.txt Pages : 11 Date : 28-Sep-01 This document specifies an Extensible Authentication Protocol (EAP) mechanism for mutual authentication and session key generation in a roaming environment. The server authentication and the negotiation of the session key is done using the PPP EAP Transport Layer Security (TLS) Authentication Protocol. The user authenticates using a PPP EAP mechanism, integrity and privacy protected by TLS. In essence, a wrapping of EAP inside TLS inside EAP is specified. An important application discussed in this document is to provide authentication of access points and stations within an IEEE 802.11 Wireless Local Area Network (WLAN), but other applications such as LAN access over Bluetooth might also be considered in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-01.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-josefsson-pppext-eap-tls-eap-01.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-josefsson-pppext-eap-tls-eap-01.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: <20010928122612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-josefsson-pppext-eap-tls-eap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-josefsson-pppext-eap-tls-eap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010928122612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Mon Oct 1 08:00:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12399 for ; Mon, 1 Oct 2001 08:00:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AB7A9124D; Mon, 1 Oct 2001 08:00:22 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C8C091250; Mon, 1 Oct 2001 08:00:22 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0C7C9124D for ; Mon, 1 Oct 2001 08:00:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D3845DDA0; Mon, 1 Oct 2001 08:00:20 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 30CDD5DD8C for ; Mon, 1 Oct 2001 08:00:20 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23440; Mon, 1 Oct 2001 04:59:19 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29419; Mon, 1 Oct 2001 07:59:18 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.6+Sun/8.11.6) id f91C09N59593; Mon, 1 Oct 2001 08:00:09 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15288.23240.912295.53053@gargle.gargle.HOWL> Date: Mon, 1 Oct 2001 08:00:08 -0400 (EDT) From: James Carlson To: Jonathan.Sadler@tellabs.com Cc: ietf-ppp@merit.edu Subject: Re: Proposed use of PPP in the OIF UNI In-Reply-To: Jonathan Sadler's message of 20 September 2001 16:40:25 References: <3BAA6249.ABF3E15@tellabs.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Jonathan Sadler writes: > I have some concerns regarding the proposed configuration of PPP for the > OIF UNI that I would like the PPP working group to look at. > > In the OIF UNI (http://www.oiforum.com/public/documents/UNI_1.0.pdf), > Section 6.1 page 22 defines the configuration of PPP on the SONET DCC as > follows: > > "...IP packets are encapsulated using PPP in HDLC like framing as per > RFC1662. ... only PPP encapsulation must be used with no other PPP > procedures (i.e. LCP and NCP need not be executed)." That's absurd on multiple levels. You can't claim to be using PPP if you're just using the framing, and I frankly don't see how any level of interoperability could be hoped for with the phrase "need not be executed." What happens when one vendor chooses to implement the existing IETF Standards Track protocols and another does not? > Is PPP without LCP/NCP negotiation considered a standard implementation > by the IETF? No. It's not PPP. It's effectively SLIP, albeit with different framing. Of course, consenting peers may do anything they like, including omitting the necessary (and useful) RFC 1661 LCP and RFC 1332 IPCP negotiation for no apparent reason. I see no point to doing so, but there's no law prohibiting it. (At a wild guess, I would assume that PPP negotiation is viewed as "unnecessary overhead." I would submit that [1] a useful implementation of the OIF signaling has such significant complexity that PPP is effectively a drop in the bucket and [2] source code that implements PPP is freely available.) > RFC 1661 (which is never referenced by the OIF UNI > document) seems to have strong words preventing this. Right. > It should be noted that the OIF has chosen this in part to facilitate > the misconnection detection feature specified in LMP > (draft-ietf-ccamp-lmp-00.txt, and OIF UNI section 8). Specifically, the > test messages for LMP are defined to be carried within IP PDUs on the > data link. Because successful LCP/NCP negotiation requires a correctly > connected full-duplex link, these IP PDUs be prevented from being sent > on a misconnected link. As a result, LMP would not have a chance to > detect this case. I don't think that's true at all. There are certainly possible failure modes in which PPP establishes normally, but IP-based protocols (such as LMP) don't work at all. For instance, the peer might not be running LMP. Having IPCP properly negotiated does not mean that any applications are available or running; it merely means that IP datagrams are permitted on the link. > While the current LMP solution has this problem, other solutions may > not. For example, the test messages could be carried within an LCP > option (similar to the Identification option specified in RFC 1570). I certainly wouldn't want to see that done. (Perhaps LCP Echo-Request would be useful *in addition* to other higher-level test messages, but they're no substitute.) > Please provide the feeling of the working group on this issue. Review of these documents isn't required here, but I'd hope that the OIF would be interested enough in having the relevant portions reviewed that they'd approach us (or the IESG) for such a review. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Oct 5 11:19:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23919 for ; Fri, 5 Oct 2001 11:19:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56F8E91240; Fri, 5 Oct 2001 11:20:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22B5F91288; Fri, 5 Oct 2001 11:20:29 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A53291240 for ; Fri, 5 Oct 2001 11:20:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C4AF5DDAC; Fri, 5 Oct 2001 11:20:27 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by segue.merit.edu (Postfix) with ESMTP id 6F7865DDA5 for ; Fri, 5 Oct 2001 11:20:27 -0400 (EDT) Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id ABH96578; Fri, 5 Oct 2001 10:19:01 -0500 (CDT) Received: from tellabs.com (dhcp-172-17-44-44.lisle.tellabs.com [172.17.44.44]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id KAA14816; Fri, 5 Oct 2001 10:18:59 -0500 (CDT) Message-ID: <3BBDCF64.F30554D6@tellabs.com> Date: Fri, 05 Oct 2001 10:19:00 -0500 From: Jonathan Sadler Reply-To: Jonathan.Sadler@tellabs.com Organization: Tellabs ONG SE Platform X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: James Carlson , ietf-ppp@merit.edu Subject: Re: Proposed use of PPP in the OIF UNI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James - Thanks for your response. I hope that others have opinions to express regarding this issue so a better "consensus" feeling can be developed. I have not received any verification from the official OIF liaison to the IETF, David O'Leary (Juniper Networks), on whether a proper liaison was submitted to the IETF regarding the OIF UNI. It is quite likely that they have not done so. The OIF has started a Principal Ballot period for the OIF UNI, completing on October 16th. I would like to include comments on this issue in our company's response, but would like to base them on the PPP working group's feeling on this issue. Consequently, I would like to suggest that you send your responses within the next couple of days. Thanks you! Jonathan Sadler James Carlson wrote: > > Jonathan Sadler writes: > > I have some concerns regarding the proposed configuration of PPP for the > > OIF UNI that I would like the PPP working group to look at. > > > > In the OIF UNI (http://www.oiforum.com/public/documents/UNI_1.0.pdf), > > Section 6.1 page 22 defines the configuration of PPP on the SONET DCC as > > follows: > > > > "...IP packets are encapsulated using PPP in HDLC like framing as per > > RFC1662. ... only PPP encapsulation must be used with no other PPP > > procedures (i.e. LCP and NCP need not be executed)." > > That's absurd on multiple levels. You can't claim to be using PPP if > you're just using the framing, and I frankly don't see how any level > of interoperability could be hoped for with the phrase "need not be > executed." What happens when one vendor chooses to implement the > existing IETF Standards Track protocols and another does not? > > > Is PPP without LCP/NCP negotiation considered a standard implementation > > by the IETF? > > No. It's not PPP. It's effectively SLIP, albeit with different > framing. > > Of course, consenting peers may do anything they like, including > omitting the necessary (and useful) RFC 1661 LCP and RFC 1332 IPCP > negotiation for no apparent reason. I see no point to doing so, but > there's no law prohibiting it. > > (At a wild guess, I would assume that PPP negotiation is viewed as > "unnecessary overhead." I would submit that [1] a useful > implementation of the OIF signaling has such significant complexity > that PPP is effectively a drop in the bucket and [2] source code that > implements PPP is freely available.) > > > RFC 1661 (which is never referenced by the OIF UNI > > document) seems to have strong words preventing this. > > Right. > > > It should be noted that the OIF has chosen this in part to facilitate > > the misconnection detection feature specified in LMP > > (draft-ietf-ccamp-lmp-00.txt, and OIF UNI section 8). Specifically, the > > test messages for LMP are defined to be carried within IP PDUs on the > > data link. Because successful LCP/NCP negotiation requires a correctly > > connected full-duplex link, these IP PDUs be prevented from being sent > > on a misconnected link. As a result, LMP would not have a chance to > > detect this case. > > I don't think that's true at all. There are certainly possible > failure modes in which PPP establishes normally, but IP-based > protocols (such as LMP) don't work at all. For instance, the peer > might not be running LMP. Having IPCP properly negotiated does not > mean that any applications are available or running; it merely means > that IP datagrams are permitted on the link. > > > While the current LMP solution has this problem, other solutions may > > not. For example, the test messages could be carried within an LCP > > option (similar to the Identification option specified in RFC 1570). > > I certainly wouldn't want to see that done. (Perhaps LCP Echo-Request > would be useful *in addition* to other higher-level test messages, but > they're no substitute.) > > > Please provide the feeling of the working group on this issue. > > Review of these documents isn't required here, but I'd hope that the > OIF would be interested enough in having the relevant portions > reviewed that they'd approach us (or the IESG) for such a review. > > -- > James Carlson, Solaris Networking > SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Fri Oct 5 13:04:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26473 for ; Fri, 5 Oct 2001 13:04:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4509791291; Fri, 5 Oct 2001 13:05:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16B8B9129A; Fri, 5 Oct 2001 13:05:14 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA88A91291 for ; Fri, 5 Oct 2001 13:05:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 655C65DE0B; Fri, 5 Oct 2001 13:05:12 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mx4.tellabs.com (mx4.tellabs.com [204.68.180.54]) by segue.merit.edu (Postfix) with ESMTP id 1417C5DE07 for ; Fri, 5 Oct 2001 13:05:12 -0400 (EDT) Received: from mailw02.hq.tellabs.com (mailw02.bb.tellabs.com [138.111.51.101]) by mx4.tellabs.com (Mirapoint) with ESMTP id ABH98233; Fri, 5 Oct 2001 11:50:20 -0500 (CDT) Received: from tellabs.com (dhcp-172-17-44-44.lisle.tellabs.com [172.17.44.44]) by mailw02.hq.tellabs.com with ESMTP (8.8.6 (PHNE_17190)/8.7.1) id LAA26437; Fri, 5 Oct 2001 11:50:20 -0500 (CDT) Message-ID: <3BBDE4C4.6F052728@tellabs.com> Date: Fri, 05 Oct 2001 11:50:12 -0500 From: Jonathan Sadler Reply-To: Jonathan.Sadler@tellabs.com Organization: Tellabs ONG SE Platform X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: James Carlson Cc: ietf-ppp@merit.edu Subject: Re: Proposed use of PPP in the OIF UNI References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit James, et al - James Carlson wrote: > Review of these documents isn't required here, but I'd hope that the > OIF would be interested enough in having the relevant portions > reviewed that they'd approach us (or the IESG) for such a review. Here is the response I got from David O'Leary regarding the liaison of the OIF UNI to the IETF: At Fri, 5 Oct 2001 05:41:21 -0700, dave o'leary wrote: > A meeting was held last spring where OIF and IETF leadership > discussed how to work together. Since many of us are active in both > groups, and the IETF doesn't require any formal liaison to submit > drafts, and decisions to review/comment are made on an individual > basis rather than a group basis, so a request for review basically > has no effect - and it was decided that it was not worthwhile to > write and send formal liaison letters. So my job is really to educate > each group about the other and about relevant activities, and to > keep the OIF informed of related activities and status in the IETF. I have sent him a message stating that the current OIF UNI discusses PPP implementation issues, and that the PPP working group should be engaged to discuss these issues. Jonathan Sadler From owner-ietf-ppp@merit.edu Sat Oct 6 13:32:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28220 for ; Sat, 6 Oct 2001 13:32:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA33F9124D; Sat, 6 Oct 2001 13:33:46 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5E8891253; Sat, 6 Oct 2001 13:33:46 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 816229124D for ; Sat, 6 Oct 2001 13:33:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 107EC5DDE3; Sat, 6 Oct 2001 13:33:45 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-018.aiinet.com [38.195.70.18]) by segue.merit.edu (Postfix) with ESMTP id F1F035DD8C for ; Sat, 6 Oct 2001 13:33:43 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sat, 6 Oct 2001 13:31:30 -0400 Message-Id: <4.3.2.7.2.20011006132858.00d85100@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 06 Oct 2001 13:30:31 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: PPP Multiplexed to Proposed Standard Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that PPP Multiplexed (draft-ietf-pppext-pppmux-03.txt) be advanced to Proposed Standard. From owner-ietf-ppp@merit.edu Sat Oct 6 13:50:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28276 for ; Sat, 6 Oct 2001 13:50:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A69191253; Sat, 6 Oct 2001 13:51:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 441D891254; Sat, 6 Oct 2001 13:51:10 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25A8F91253 for ; Sat, 6 Oct 2001 13:51:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CC345DD8D; Sat, 6 Oct 2001 13:51:08 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-018.aiinet.com [38.195.70.18]) by segue.merit.edu (Postfix) with ESMTP id 8B8715DD8C for ; Sat, 6 Oct 2001 13:51:07 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sat, 6 Oct 2001 13:49:39 -0400 Message-Id: <4.3.2.7.2.20011006134738.05062100@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 06 Oct 2001 13:49:21 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Re: WG opinion on draft-haverinen-pppext-eap-sim-01.txt? Cc: henry.haverinen@nokia.com In-Reply-To: <6D1A8E7871B9D211B3B00008C7490AA504E625AF@treis03nok> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi folks, Any reason why we shouldn't move eap-sim to Proposed Standard? Please voice your comments now. Thanks, Karl At 05:20 AM 4/12/01, henry.haverinen@nokia.com wrote: >Hi all, > >I just submitted a new version of the eap-sim draft >(draft-haverinen-pppext-eap-sim-01.txt), which is now >available in the IETF directories. This version contains >a couple of clarifications and editorial changes. > >We also have an implementation of the protocol up and running. > >I'd like to hear the working group's opinion on this >submission. Do you think this could be a standards track >document? Or, if there isn't enough interest for this to be >a working group item, could the draft become an experimental RFC? > >Regards, >Henry From owner-ietf-ppp@merit.edu Tue Oct 9 10:26:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04436 for ; Tue, 9 Oct 2001 10:26:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 876A39120F; Tue, 9 Oct 2001 10:27:39 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B78E912AB; Tue, 9 Oct 2001 10:27:39 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42E709120F for ; Tue, 9 Oct 2001 10:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B2EB95DD90; Tue, 9 Oct 2001 10:27:37 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CC7A65DD8F for ; Tue, 9 Oct 2001 10:27:36 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f99EQif22153 for ; Tue, 9 Oct 2001 17:26:44 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 9 Oct 2001 17:26:09 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <4M64018P>; Tue, 9 Oct 2001 17:26:09 +0300 Message-ID: From: henry.haverinen@nokia.com To: ietf-ppp@merit.edu Subject: EAP TLS drafts Date: Tue, 9 Oct 2001 17:26:08 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi all, I really like the idea of tunnelling EAP within EAP/TLS, and I hope this idea gets standardized. But why two separate drafts that essentially propose the same thing? (draft-josefsson-pppext-eap-tls-eap-01.txt and draft-ietf-pppext-eap-ttls-00.txt) Is the latter one a working group document, like the name implies? Regards, Henry From owner-ietf-ppp@merit.edu Tue Oct 9 14:13:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11004 for ; Tue, 9 Oct 2001 14:13:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73A0F9121A; Tue, 9 Oct 2001 14:14:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 418F49121D; Tue, 9 Oct 2001 14:14:40 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 437B69121A for ; Tue, 9 Oct 2001 14:14:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0DEA5DDB2; Tue, 9 Oct 2001 14:14:38 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mapleoptical.com (mail.MapleOptical.com [63.111.208.202]) by segue.merit.edu (Postfix) with ESMTP id 3C5095DDB1 for ; Tue, 9 Oct 2001 14:14:38 -0400 (EDT) Received: from morphius.mapleoptical.com (localhost [127.0.0.1]) by mapleoptical.com (8.11.0/8.11.0) with ESMTP id f99IDGK13350 for ; Tue, 9 Oct 2001 11:13:16 -0700 (PDT) Received: from MLEWIS-LT.NetEFX.com (MLEWIS-LT [192.168.12.218]) by morphius.mapleoptical.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RH74HKDH; Tue, 9 Oct 2001 11:12:13 -0700 Message-Id: <5.1.0.14.0.20011009110447.00ac6358@morphius> X-Sender: msl@mail.NetEFX.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 09 Oct 2001 11:13:03 -0700 To: ietf-ppp@merit.edu From: "Mark S. Lewis" Subject: Recommendations for PPP source code Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu My company is looking to replace our current PPP stack with a better one. It's been awhile since I've been working in the PPP area and so I'm asking you guys for any recommendations. It must be current with the latest RFCs and be portable for relatively easy integration. Is ppp-2.4 a suitable free source? Is it current? Can it be used in commercial products? Any other solid free source? Do you guys have any specific recommendations on commercial sources? Please email me privately unless you think it would be of benefit to the list. Thanks. ... Mark http://www.NetEFX.com <<<==---- Custom video and website production From owner-ietf-ppp@merit.edu Tue Oct 9 21:05:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16183 for ; Tue, 9 Oct 2001 21:05:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2302F91231; Tue, 9 Oct 2001 21:06:10 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8DC491232; Tue, 9 Oct 2001 21:06:09 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B222E91231 for ; Tue, 9 Oct 2001 21:06:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 303505DD9F; Tue, 9 Oct 2001 21:06:08 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from mail.ca (unknown [209.121.99.6]) by segue.merit.edu (Postfix) with ESMTP id ADB3B5DDA9 for ; Tue, 9 Oct 2001 21:06:07 -0400 (EDT) Received: from smtpmail.certicom.com (smtpmail [10.0.1.25]) by mail.ca (8.9.3/8.9.3) with SMTP id UAA09436; Tue, 9 Oct 2001 20:57:34 -0400 (EDT) Received: by smtpmail.certicom.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256AE1.0005CE8D ; Tue, 9 Oct 2001 21:03:25 -0400 X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: henry.haverinen@nokia.com Cc: ietf-ppp@merit.edu Message-ID: <85256AE1.0005CDB6.00@smtpmail.certicom.com> Date: Tue, 9 Oct 2001 21:03:20 -0400 Subject: Re: EAP TLS drafts Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Henry, I'm one of the authors of draft-ietf-pppext-eap-ttls-00.txt. Paul and I submitted this as a WG draft, and it believe it was accepted as a working group document. I agree it doesn't make sense to have two separate drafts saying the same thing ... I'm hoping we're able to merge the two drafts going forward, although I haven't had time to study draft-josefsson-pppext-eap-tls-eap-01.txt in detail yet. Best regards. simon henry.haverinen@nokia.com on 10/09/2001 10:26:08 AM To: ietf-ppp@merit.edu cc: (bcc: Simon Blake-Wilson/Certicom) Subject: EAP TLS drafts Hi all, I really like the idea of tunnelling EAP within EAP/TLS, and I hope this idea gets standardized. But why two separate drafts that essentially propose the same thing? (draft-josefsson-pppext-eap-tls-eap-01.txt and draft-ietf-pppext-eap-ttls-00.txt) Is the latter one a working group document, like the name implies? Regards, Henry From owner-ietf-ppp@merit.edu Wed Oct 10 08:22:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08360 for ; Wed, 10 Oct 2001 08:22:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CF679122B; Wed, 10 Oct 2001 08:22:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28D6991261; Wed, 10 Oct 2001 08:22:30 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3FCA9122B for ; Wed, 10 Oct 2001 08:22:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA1EE5DDC2; Wed, 10 Oct 2001 08:22:28 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-122.aiinet.com [38.195.70.122]) by segue.merit.edu (Postfix) with ESMTP id 2928E5DD9E for ; Wed, 10 Oct 2001 08:22:28 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 10 Oct 2001 08:22:15 -0400 Message-Id: <4.3.2.7.2.20011010081806.04f34d50@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 08:22:12 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: PPP over AAL2 - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to take "PPP over AAL2" (draft-ietf-pppext-ppp-over-aal2-01.txt) to Proposed Standard on October 25 unless there is substantive comment raised on the list. Karl From owner-ietf-ppp@merit.edu Wed Oct 10 08:24:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08377 for ; Wed, 10 Oct 2001 08:24:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B51291261; Wed, 10 Oct 2001 08:24:22 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB23B91262; Wed, 10 Oct 2001 08:24:21 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 945D491261 for ; Wed, 10 Oct 2001 08:24:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 72E7A5DDC2; Wed, 10 Oct 2001 08:24:20 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-122.aiinet.com [38.195.70.122]) by segue.merit.edu (Postfix) with ESMTP id D5D225DD9E for ; Wed, 10 Oct 2001 08:24:19 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 10 Oct 2001 08:24:12 -0400 Message-Id: <4.3.2.7.2.20011010082222.04ed5820@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Oct 2001 08:24:10 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Class Extensions for PPP over AAL2 - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to take "Class Extensions for PPP over AAL2" (draft-ietf-pppext-ppp-over-aal2-class-00.txt) to Proposed Standard on October 25 unless there is substantive comment raised on the list. Karl From owner-ietf-ppp@merit.edu Mon Oct 15 12:04:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03702 for ; Mon, 15 Oct 2001 12:04:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 57DA49120A; Mon, 15 Oct 2001 12:04:03 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29D3F91224; Mon, 15 Oct 2001 12:04:03 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D4049120A for ; Mon, 15 Oct 2001 12:04:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D69E65DDC2; Mon, 15 Oct 2001 12:04:01 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from frontal3.sagem.com (frontal3.sagem.com [62.160.59.146]) by segue.merit.edu (Postfix) with ESMTP id 8B7F05DD8C for ; Mon, 15 Oct 2001 12:04:01 -0400 (EDT) Received: from mlksrv17.sagem.ads.sagem (notes2.dmz2.sagem.fr [10.20.251.39]) by frontal3.sagem.com (Postfix) with SMTP id F3AC37B853 for ; Mon, 15 Oct 2001 18:03:56 +0200 (CEST) Received: from 10.20.201.54 by mlksrv17.sagem.ads.sagem (InterScan E-Mail VirusWall NT); Mon, 15 Oct 2001 18:02:13 +0200 Received: from estuaire.sagem.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 15 Oct 2001 18:03:46 +0200 To: ietf-ppp@merit.edu Cc: "Herve CHABANNE" X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: "Romain BERRENDONNER" Date: Mon, 15 Oct 2001 18:03:49 +0200 X-MIMETrack: Serialize by Router on ESTUAIRE/SAGEM(Release 5.0.6a |January 17, 2001) at 15/10/2001 18:03:46 MIME-Version: 1.0 Content-type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi everybody, Some time ago, Herve Chabanne and I submitted an internet draft describing a new authentication protocol suitable for EAP. We would be glad to have your opinion about it. Particularly, does anyone in the community consider it as : 1/ Interesting ? 2/ Worth being examined at the next IETf meeting? See http://www.ietf.org/internet-drafts/draft-berrendo-chabanne-pppext-eapmake-00.txt for more information, or mail me back. Any feedback will be welcome. Regards, -- Romain Berrendonner From owner-ietf-ppp@merit.edu Tue Oct 16 14:29:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14191 for ; Tue, 16 Oct 2001 14:29:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB5FF91270; Tue, 16 Oct 2001 14:29:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7925491271; Tue, 16 Oct 2001 14:29:31 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64DAA91270 for ; Tue, 16 Oct 2001 14:29:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A0885DDBE; Tue, 16 Oct 2001 14:29:30 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id D2F505DDBD for ; Tue, 16 Oct 2001 14:29:29 -0400 (EDT) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Tue, 16 Oct 2001 14:29:29 -0400 Message-Id: <5.1.0.14.2.20011016124202.02644638@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 14:29:12 -0400 To: ietf-ppp@merit.edu From: Robert Moskowitz Subject: Security comment on draft-ietf-pppext-eap-srp-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hello, I am new to the pppext list. I joined because I find my work in 802.11 is dragging me over to EAP types. I have reviewed RFC 1945 (SRP) and this Internet Draft. The protocol presented here is good for most dialup uses of EAP, but is not for 802.11. I will give an abstract then some details: Most client-server authentication models exist in an environment where the client has some outside assurance that it is engaged in an exchange with the server it 'thinks' it should be. 802.1x for 802.11 does not offer any such assurance. Since the EAP packets are sent over layer 2, the only knowledge the supplicant has of the authenticator is its SSID which is totally spoofable. This fact leads to a requirement that any EAP type used for 802.11 provide EXPLICIT mutual authentication. That is not only does the supplicant need to know that the authentication server can prove that it has knowledge of the supplicant's identity, but the supplicant has to prove that it has knowledge of tha authentication server's identity. EAP/TLS provides this. EAP/SRP as defined in this draft does not. Now to the attack. in SRP, the authentication system has the supplicant's userid and password verifier. This verifier is a public value. If it is acquired by another attacker, that attacker can put up its own access point with its own authentication server and the supplicant will merrily authenticate to this rogue AP. My recommendation is as follows: Leave this EAP type as is for domains of AS trust, like dialup or wired networks (eg VLANs). For shared media, like 802.11 a different exchange is needed. The AS needs its UserID and Password and thus its Password Verifier (this is really nothing more than a Diffie-Hellman raw public key). This information MUST be distributed to all supplicants. Then first the supplicant must prove it has the AS's identity followed by the more 'normal' SRP exchange. This does produce 2 session keys. The first one is discarded. This does have the 'problem' of distributing the AS's Password Validator. This can be done in a number of ways including using a X.509 cert with a D-H key value. This is a quick writeup of the attack against this EAP Type in an WLAN world. Note that it has NOTHING to do with the trust relationship of the AP to the AS, rather how does the STA KNOW it is talking to the AS it thinks it should be talking too. All things considered, I believe that SRP is better than TLS for MOST applications in 802.11. It is more workable for WISPer and SOHO. It also has an interesting property for 'public' WLANs where the STA wants to prove it is connected to the public network it thinks it is connected to (like at IETF meetings). From owner-ietf-ppp@merit.edu Tue Oct 16 15:02:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15717 for ; Tue, 16 Oct 2001 15:02:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E1E19126F; Tue, 16 Oct 2001 15:02:44 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6010291271; Tue, 16 Oct 2001 15:02:44 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 544FD9126F for ; Tue, 16 Oct 2001 15:02:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A0AA5DDBE; Tue, 16 Oct 2001 15:02:42 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id AF3665DDBD for ; Tue, 16 Oct 2001 15:02:41 -0400 (EDT) Received: from client62-2-83-93.hispeed.ch (HELO ETCL001.yahoo.com) (62.2.83.93) by smtp.mail.vip.sc5.yahoo.com with SMTP; 16 Oct 2001 19:02:40 -0000 X-Apparently-From: Message-Id: <5.1.0.14.0.20011016204845.038ddc18@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 20:58:18 +0200 To: Robert Moskowitz From: Jacques Caron Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt Cc: ietf-ppp@merit.edu In-Reply-To: <5.1.0.14.2.20011016124202.02644638@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi, At 20:29 16/10/2001, Robert Moskowitz wrote: >Hello, I am new to the pppext list. I joined because I find my work in >802.11 is dragging me over to EAP types. > >I have reviewed RFC 1945 (SRP) and this Internet Draft. The protocol >presented here is good for most dialup uses of EAP, but is not for >802.11. I will give an abstract then some details: > >Most client-server authentication models exist in an environment where the >client has some outside assurance that it is engaged in an exchange with >the server it 'thinks' it should be. 802.1x for 802.11 does not offer any >such assurance. Since the EAP packets are sent over layer 2, the only >knowledge the supplicant has of the authenticator is its SSID which is >totally spoofable. This fact leads to a requirement that any EAP type >used for 802.11 provide EXPLICIT mutual authentication. That is not only >does the supplicant need to know that the authentication server can prove >that it has knowledge of the supplicant's identity, but the supplicant has >to prove that it has knowledge of tha authentication server's identity. I don't quite see the point for the server to know that the client know that the servers knows the client's verifier (urg). Actually, it already does, as the client should abort the connection if anything in the EAP exchange shows that the server doesn't know the verifier. >EAP/TLS provides this. EAP/SRP as defined in this draft does not. > >Now to the attack. > >in SRP, the authentication system has the supplicant's userid and password >verifier. This verifier is a public value. If it is acquired by another >attacker, that attacker can put up its own access point with its own >authentication server and the supplicant will merrily authenticate to this >rogue AP. The verifier is *not* a public value. It is supposed to be kept secret, like any crypted password (e.g. DES or MD5 crypted passwords in /etc/passwd derivatives on Unix systems). SRP adds security by making sure that even if the verifier becomes public, it is not possible to derive the clear text password, and to authenticate as the original user. If the verifier becomes compromised, the password should be changed. >My recommendation is as follows: > >Leave this EAP type as is for domains of AS trust, like dialup or wired >networks (eg VLANs). > >For shared media, like 802.11 a different exchange is needed. The AS >needs its UserID and Password and thus its Password Verifier (this is >really nothing more than a Diffie-Hellman raw public key). This >information MUST be distributed to all supplicants. Then first the >supplicant must prove it has the AS's identity followed by the more >'normal' SRP exchange. You're describing bi-directional SRP auth, which if I understood things correctly is covered by a patent. If that isn't a problem for you, then >This does produce 2 session keys. The first one is discarded. > >This does have the 'problem' of distributing the AS's Password >Validator. This can be done in a number of ways including using a X.509 >cert with a D-H key value. And how would you distribute this? Not within EAP I guess... >This is a quick writeup of the attack against this EAP Type in an WLAN >world. Note that it has NOTHING to do with the trust relationship of the >AP to the AS, rather how does the STA KNOW it is talking to the AS it >thinks it should be talking too. > >All things considered, I believe that SRP is better than TLS for MOST >applications in 802.11. It is more workable for WISPer and SOHO. It also >has an interesting property for 'public' WLANs where the STA wants to >prove it is connected to the public network it thinks it is connected to >(like at IETF meetings). Definitely, EAP SRP is probably the ideal auth protocol for public WLANs. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-ietf-ppp@merit.edu Tue Oct 16 15:32:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17263 for ; Tue, 16 Oct 2001 15:32:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D83A91273; Tue, 16 Oct 2001 15:32:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED7B091274; Tue, 16 Oct 2001 15:32:12 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AAE5A91273 for ; Tue, 16 Oct 2001 15:32:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D40B5DDBE; Tue, 16 Oct 2001 15:32:11 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id BAB815DDBD for ; Tue, 16 Oct 2001 15:32:10 -0400 (EDT) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Tue, 16 Oct 2001 15:32:11 -0400 Message-Id: <5.1.0.14.2.20011016152728.026483c0@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 15:31:52 -0400 To: Jacques Caron From: Robert Moskowitz Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt Cc: ietf-ppp@merit.edu In-Reply-To: <5.1.0.14.0.20011016204845.038ddc18@pop.mail.yahoo.com> References: <5.1.0.14.2.20011016124202.02644638@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 08:58 PM 10/16/2001 +0200, Jacques Caron wrote: >I don't quite see the point for the server to know that the client know >that the servers knows the client's verifier (urg). Actually, it already >does, as the client should abort the connection if anything in the EAP >exchange shows that the server doesn't know the verifier. Any server that has gained the public userid and public password verifier would pass this test. >The verifier is *not* a public value. It is supposed to be kept secret, >like any crypted password (e.g. DES or MD5 crypted passwords in >/etc/passwd derivatives on Unix systems). SRP adds security by making sure >that even if the verifier becomes public, it is not possible to derive the >clear text password, and to authenticate as the original user. If the >verifier becomes compromised, the password should be changed. If the verifier becomes public, and the servers g and N, then any other server can process this verifier. Also, there is nothing in RFC 2945 or eap-srp-03 that states the danger of password verifier leakage. Quite the opposite. It is called a public password verifier. Many implementations will not make enough effort to keep it secret. >You're describing bi-directional SRP auth, which if I understood things >correctly is covered by a patent. If that isn't a problem for you, then Which patent? EKE? Can you point me to any statement to establish this? >>This does have the 'problem' of distributing the AS's Password >>Validator. This can be done in a number of ways including using a X.509 >>cert with a D-H key value. > >And how would you distribute this? Not within EAP I guess... same way in TLS that a client gets its signer's certificate. out of band. From owner-ietf-ppp@merit.edu Tue Oct 16 22:25:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25197 for ; Tue, 16 Oct 2001 22:25:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B2F491207; Tue, 16 Oct 2001 22:25:33 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 672519120D; Tue, 16 Oct 2001 22:25:33 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4879091207 for ; Tue, 16 Oct 2001 22:25:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22D055DD98; Tue, 16 Oct 2001 22:25:32 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 07C485DD94 for ; Tue, 16 Oct 2001 22:25:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id TAA10825; Tue, 16 Oct 2001 19:17:46 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 16 Oct 2001 19:17:46 -0700 (PDT) From: Bernard Aboba To: Robert Moskowitz Cc: ietf-ppp@merit.edu Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt In-Reply-To: <5.1.0.14.2.20011016124202.02644638@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Most client-server authentication models exist in an environment where the > client has some outside assurance that it is engaged in an exchange with > the server it 'thinks' it should be. In general, the EAP exchange is between the client and the AAA server, not between the client and the NAS. This is no different for PPP than for 802.1X. So if there is mutual authentication, it is between the client and AAA server. The NAS acts as a "passthrough" and so is not authenticated as part of the exchange. This actually makes sense because the client would typically not be able to validate the identity of the NAS anyway -- what good would it do to know that it was ap123.foo.net? What is important is that the NAS has a trust relationship with the AAA infrastructure, and is not a "rogue" NAS. So the client is looking for the NAS to show that it has a trusted relationship with the AAA server, by proving posession of a private key (TLS) or shared secret (SRP). Typically, AAA protocols require that the communication between NAS and AAA server be mutually authenticated. RADIUS accomplishes this via a shared secret or IPsec; Diameter can handle this via TLS or IPsec. > 802.1x does not offer such assurance. 802.1x is not any different from PPP in this respect. This is a property of EAP, AAA and the individual methods and does not relate to the encapsulation. > Since the EAP packets are sent over layer 2, the only > knowledge the supplicant has of the authenticator is its SSID which is > totally spoofable. Actually, since the SSID is typically not available to the EAP method, it isn't possible to take this into account explicitly. In EAP TLS, both client and AAA server provide a claimed identity, then prove the claim. In EAP SRP, only the client provides a claim of identity, and then both sides prove knowledge of the shared secret. The problem arises when you have several accounts. For example, you could have a userid on a corporate network, a userid on an ISP, and a userID on a public "hotspot" network. How do you know which credentials to use for a given connection? It could be argued that in the case of PPP, you have dialed a phone number; for VPN (e.g. L2TP), you have connected at an IP address; and for 802.11 you have chosen to associate with an SSID -- and so based on the selected destination, one could have an expectation about who is on the other end, and select the credentials appropriately. Of course, phone numbers, DNS to IP address resolution and SSIDs can all be spoofed. So I think that the issue is not related to the encapsulation. The issue is whether, given a rogue NAS, any useful information is leaked by the client during the exchange. > Not only does the supplicant need to know that the authentication server > can prove that it has knowledge of the supplicant's identity, but the > supplicant has to prove that it has knowledge of tha authentication > server's identity. > > EAP/TLS provides this. EAP/SRP as defined in this draft does not. > Yes, you are correct that in SRP the AAA server does not make a claim of identity, nor does it prove such a claim. Rather, it proves knowledge of the client's credentials. > in SRP, the authentication system has the supplicant's userid and password > verifier. This verifier is a public value. No, the SRP verifier is *not* public -- because if it is known, then SRP is subject to dictionary attack. Rather, the SRP verifier, salt, prime modulus is assumed to be in a protected credential store. This is superior to a password stored in reversibly encrypted form or in the clear in that one has to put more work into obtaining the password if the credential store is compromised. At various points in the EAP SRP protocol, the client is supposed to disconnect, if the AAA server doesn't behave as expected. Are you claiming that there is information leakage which isn't addressed in the spec? > If it is acquired by another > attacker, that attacker can put up its own access point with its own > authentication server and the supplicant will merrily authenticate to this > rogue AP. This is true, because you'd have all the information to impersonate the credential store -- because the store would be compromised. That's like saying that if I obtain your password in a network where passwords are used, then I can get on the network. If we assume that the verifiers are compromised, then the attacker can mount a dictionary attack on them and obtain some fraction of the passwords directly. At that point you have more to worry about than rogue NASen ;) > My recommendation is as follows: > > Leave this EAP type as is for domains of AS trust, like dialup or wired > networks (eg VLANs). The issue, if it exists, is valid for all encapsulations. > Validator. This can be done in a number of ways including using a X.509 > cert with a D-H key value. What you've just described is very similar to SRP-Z, which is covered by a Stanford patent. And yes, it is better because each side claims an identity and proves the claim. From owner-ietf-ppp@merit.edu Tue Oct 16 23:11:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26711 for ; Tue, 16 Oct 2001 23:11:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD9BB9120D; Tue, 16 Oct 2001 23:10:53 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B7BB91227; Tue, 16 Oct 2001 23:10:53 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74CEA9120D for ; Tue, 16 Oct 2001 23:10:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FAB55DD98; Tue, 16 Oct 2001 23:10:52 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id C41235DD94 for ; Tue, 16 Oct 2001 23:10:51 -0400 (EDT) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Tue, 16 Oct 2001 23:10:50 -0400 Message-Id: <5.1.0.14.2.20011016223322.02668e98@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 16 Oct 2001 23:10:29 -0400 To: Bernard Aboba From: Robert Moskowitz Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt Cc: ietf-ppp@merit.edu In-Reply-To: References: <5.1.0.14.2.20011016124202.02644638@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 07:17 PM 10/16/2001 -0700, Bernard Aboba wrote: > > Most client-server authentication models exist in an environment where the > > client has some outside assurance that it is engaged in an exchange with > > the server it 'thinks' it should be. > >In general, the EAP exchange is between the client and the AAA server, not >between the client and the NAS. This is no different for PPP than for >802.1X. So if there is mutual authentication, it is between the client and >AAA server. The NAS acts as a "passthrough" and so is not authenticated as >part of the exchange. yes. in EAP the 'server' is the AAA box, not the NAS or AP. And in a NAS situation, the client has partial knowledge of what AAA server it is dealing with be the phone number dialed. There is very good control over phone numbers. Games like busy forwarding on someone elses lines DOES happen, but rarely. With APs, SSIDs do not have the same level of trust. Not by a long shot. >This actually makes sense because the client would typically not be able >to validate the identity of the NAS anyway -- what good would it do to >know that it was ap123.foo.net? What is important is that the NAS has a >trust relationship with the AAA infrastructure, and is not a "rogue" NAS. >So the client is looking for the NAS to show that it has a trusted >relationship with the AAA server, by proving posession of a private key >(TLS) or shared secret (SRP). Ah, but the NAS owns the phone number. So in fact the client DOES know something about the name of the NAS. It belongs to Mindspring or UUnet, etc. >Typically, AAA protocols require that the communication between NAS and >AAA server be mutually authenticated. RADIUS accomplishes this via a >shared secret or IPsec; Diameter can handle this via TLS or IPsec. Not at issue for THIS point. There is a separate issue here in corporate deployments of 802.1x with lots of APs. But that is not the nature of this discussion. > > 802.1x does not offer such assurance. > >802.1x is not any different from PPP in this respect. This is a property >of EAP, AAA and the individual methods and does not relate to the >encapsulation. 802.1x is not like PPP. Or rather only when deployed over a media like PPP is deployed. If done to a switch with real wires it is like PPP. If done over 802.11, nope. > > Since the EAP packets are sent over layer 2, the only > > knowledge the supplicant has of the authenticator is its SSID which is > > totally spoofable. > >Actually, since the SSID is typically not available to the EAP method, it >isn't possible to take this into account explicitly. In EAP TLS, both >client and AAA server provide a claimed identity, then prove the claim. In >EAP SRP, only the client provides a claim of identity, and then both sides >prove knowledge of the shared secret. Of course not. It is too late, the STA has associated with an AP based on SSID with no real knowledge how authentication will proceed. An expectation, but a weak one. >The problem arises when you have several accounts. For example, you could >have a userid on a corporate network, a userid on an ISP, and a userID on >a public "hotspot" network. How do you know which credentials to use for a >given connection? And EAP lacks an announcement of here you are. So the STA uses the SSID. 'The SSID is CORPORATE, therefore use my company ID'. This according to some draft stuff I have seen is how XP works with TLS certs ( :) ). >It could be argued that in the case of PPP, you have dialed a phone >number; for VPN (e.g. L2TP), you have connected at an IP address; and >for 802.11 you have chosen to associate with an SSID -- and so >based on the selected destination, one could have an expectation about who >is on the other end, and select the credentials appropriately. >Of course, phone numbers, DNS to IP address resolution and SSIDs can all >be spoofed. So I think that the issue is not related to the encapsulation. It is hard to spoof phone numbers. Most VPNs are configured to IP address, not domain names. SSIDs are not only spoofable, one expects to see duplicates. >The issue is whether, given a rogue NAS, any useful information is >leaked by the client during the exchange. The issue is given the public nature of the verifier, rogue AP-AAA pairings are easy to implement. Rogue NAS-AAA are not. > > Not only does the supplicant need to know that the authentication server > > can prove that it has knowledge of the supplicant's identity, but the > > supplicant has to prove that it has knowledge of tha authentication > > server's identity. > > > > EAP/TLS provides this. EAP/SRP as defined in this draft does not. > > > >Yes, you are correct that in SRP the AAA server does not make a claim of >identity, nor does it prove such a claim. Rather, it proves knowledge of >the client's credentials. which with SRP are public credentials unless we change wording in the draft and clearly state that this stuff is either for dedicated media use only or else protect them as much as passwords. > > in SRP, the authentication system has the supplicant's userid and password > > verifier. This verifier is a public value. > >No, the SRP verifier is *not* public -- because if it is known, then SRP >is subject to dictionary attack. Rather, the SRP verifier, salt, prime >modulus is assumed to be in a protected credential store. Where in the RFC or the draft does it say this? In fact 2845 says: SRP also has the added advantage of permitting the host to store passwords in a form that is not directly useful to an attacker. Even if the host's password database were publicly revealed, the attacker would still need an expensive dictionary search to obtain any passwords. The exponential computation required to validate a guess in this case is much more time-consuming than the hash currently used by most UNIX systems. Hosts are still advised, though, to try their best to keep their password files secure. Advised. Not you had better! Theft is only a problem in a shared media environment where there is no other reliable check that you are accessing the proper authentication server. >This is superior >to a password stored in reversibly encrypted form or in the clear in that >one has to put more work into obtaining the password if the credential >store is compromised. > >At various points in the EAP SRP protocol, the client is supposed to >disconnect, if the AAA server doesn't behave as expected. Are you claiming >that there is information leakage which isn't addressed in the spec? Oh, no. That is the beauty of this risk. There is no leakage in the protocol and everyone things everything is fine. The analysis is that the credentials work on any AAA server. So you trick the client to go to the rogue server through a rogue access point. This can be done in 802.11 fairly easily, but not in so easily in PPP. I do not know enough about PPPoE implementations to know if this also has a similar risk. > > If it is acquired by another > > attacker, that attacker can put up its own access point with its own > > authentication server and the supplicant will merrily authenticate to this > > rogue AP. > >This is true, because you'd have all the information to impersonate the >credential store -- because the store would be compromised. That's like >saying that if I obtain your password in a network where passwords are >used, then I can get on the network. But there is a body of knowledge about passwords and their theft. 'public verifier' (words from the RFC) is a dangerous term. >If we assume that the verifiers are compromised, then the attacker can >mount a dictionary attack on them and obtain some fraction of the >passwords directly. At that point you have more to worry about than >rogue NASen ;) See the security considerations in 2945. Of course Tom Wu's analysis might be too kind and you might be right. In which case stronger words are needed here than exist in the RFC or the draft. The draft does say: The security of the credentials stored in the authenticator's data- base relies on the entropy in the chosen password, the difficulty of hash inversion of a salted string, and the security of the system containing the database. For this reason, the chosen password SHOULD be restricted to limit the effectiveness of dictionary attacks against a disclosed database. However, since typical passwords have only a few bits of entropy, the database itself MUST be protected against disclosure. I can see systems that will enforce a reasonable level of entropy get this wrong. And since the RFC is more lenient, there should be something here stating why. Perhaps reference to a paper or two. > > Leave this EAP type as is for domains of AS trust, like dialup or wired > > networks (eg VLANs). > >The issue, if it exists, is valid for all encapsulations. > > > Validator. This can be done in a number of ways including using a X.509 > > cert with a D-H key value. > >What you've just described is very similar to SRP-Z, which is covered by a >Stanford patent. And yes, it is better because each side claims an >identity and proves the claim. I have talked to Tom Wu about this. As long as it is 2 exchanges, not one exchange with 2 identites, it is not covered by the patent. From owner-ietf-ppp@merit.edu Tue Oct 16 23:47:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27614 for ; Tue, 16 Oct 2001 23:47:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BC8891235; Tue, 16 Oct 2001 23:46:54 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B576A91238; Tue, 16 Oct 2001 23:46:53 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E07C091235 for ; Tue, 16 Oct 2001 23:46:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE2DA5DDBC; Tue, 16 Oct 2001 23:46:51 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E157E5DD94 for ; Tue, 16 Oct 2001 23:46:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id UAA10917; Tue, 16 Oct 2001 20:39:09 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 16 Oct 2001 20:39:09 -0700 (PDT) From: Bernard Aboba To: Robert Moskowitz Cc: ietf-ppp@merit.edu Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt In-Reply-To: <5.1.0.14.2.20011016223322.02668e98@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Ah, but the NAS owns the phone number. So in fact the client DOES know > something about the name of the NAS. It belongs to Mindspring or UUnet, etc. There are documented cases of phone number hijacking -- see "The Masters of Deception". So I'd claim that depending on this assurance is suspect. > And EAP lacks an announcement of here you are. So the STA uses the > SSID. 'The SSID is CORPORATE, therefore use my company ID'. This > according to some draft stuff I have seen is how XP works with TLS certs ( > :) ). Actually, EAP *does* support this -- there is nothing to stop a client from sending an EAP-Request/Identity to a AAA server. In PPP this is expected. In 802.1X it is not. > The issue is whether, given the public nature of the verifier.... If the SRP verifier is public, then SRP does not provide dictionary attack protection. So precautions need to be taken. > >Yes, you are correct that in SRP the AAA server does not make a claim of > >identity, nor does it prove such a claim. Rather, it proves knowledge of > >the client's credentials. > > which with SRP are public credentials unless we change wording in the draft > and clearly state that this stuff is either for dedicated media use only or > else protect them as much as passwords. Agree with "protect them as much as passwords." This is essential to get the claimed benefits from SRP. > >No, the SRP verifier is *not* public -- because if it is known, then SRP > >is subject to dictionary attack. Rather, the SRP verifier, salt, prime > >modulus is assumed to be in a protected credential store. > > Where in the RFC or the draft does it say this? In fact 2845 says: > > SRP also has the added advantage of permitting the host to store > passwords in a form that is not directly useful to an attacker. Even > if the host's password database were publicly revealed, the attacker > would still need an expensive dictionary search to obtain any > passwords. The exponential computation required to validate a guess > in this case is much more time-consuming than the hash currently used > by most UNIX systems. Hosts are still advised, though, to try their > best to keep their password files secure. > > Advised. Not you had better! Point taken. I think that the language should be considerably stronger. Since the major advantage of SRP is dictionary attack resistance, this seems like a MUST to me. > >At various points in the EAP SRP protocol, the client is supposed to > >disconnect, if the AAA server doesn't behave as expected. Are you claiming > >that there is information leakage which isn't addressed in the spec? > > Oh, no. That is the beauty of this risk. There is no leakage in the > protocol and everyone things everything is fine. The analysis is that the > credentials work on any AAA server. So you trick the client to go to the > rogue server through a rogue access point. This can be done in 802.11 > fairly easily, but not in so easily in PPP. I do not know enough about > PPPoE implementations to know if this also has a similar risk. OK, it's just verifier leakage then. But we should probably go over it again with a fine tooth comb to make sure. > But there is a body of knowledge about passwords and their theft. 'public > verifier' (words from the RFC) is a dangerous term. Agree. The term is not really appropriate -- and some warning text should be inserted in the draft. How about this? "EAP SRP implementations MUST protect the verifier against compromise. While an attacker would still need to carry out a dictionary attack against a compromised verifier in order to recover the shared secret, such a compromise does enable an attacker to impersonate an EAP authenticator. Therefore, EAP SRP implementations MUST NOT treat the verifier as public information." > The security of the credentials stored in the authenticator's data- > base relies on the entropy in the chosen password, the difficulty of > hash inversion of a salted string, and the security of the system > containing the database. For this reason, the chosen password SHOULD > be restricted to limit the effectiveness of dictionary attacks > against a disclosed database. However, since typical passwords have > only a few bits of entropy, the database itself MUST be protected > against disclosure. > > I can see systems that will enforce a reasonable level of entropy get this > wrong. And since the RFC is more lenient, there should be something here > stating why. Perhaps reference to a paper or two. Any suggested papers to reference? > I have talked to Tom Wu about this. As long as it is 2 exchanges, not one > exchange with 2 identites, it is not covered by the patent. OK. Are you saying that there should be language encouraging use of 2 exchanges, one for each direction? From owner-ietf-ppp@merit.edu Wed Oct 17 00:29:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29113 for ; Wed, 17 Oct 2001 00:29:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D9BE91241; Wed, 17 Oct 2001 00:29:15 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4178191243; Wed, 17 Oct 2001 00:29:15 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 271A191241 for ; Wed, 17 Oct 2001 00:29:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECBB85DDAC; Wed, 17 Oct 2001 00:29:13 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id 804AE5DDA3 for ; Wed, 17 Oct 2001 00:29:13 -0400 (EDT) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 17 Oct 2001 00:29:13 -0400 Message-Id: <5.1.0.14.2.20011017002129.026adea8@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Oct 2001 00:28:55 -0400 To: Bernard Aboba From: Robert Moskowitz Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt Cc: ietf-ppp@merit.edu In-Reply-To: References: <5.1.0.14.2.20011016223322.02668e98@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 08:39 PM 10/16/2001 -0700, Bernard Aboba wrote: > > Ah, but the NAS owns the phone number. So in fact the client DOES know > > something about the name of the NAS. It belongs to Mindspring or > UUnet, etc. > >There are documented cases of phone number hijacking -- see "The Masters >of Deception". So I'd claim that depending on this assurance is suspect. We had a case here in Detroit of a Plumber getting in a busy forward order to his lines on one of his competitor's lines, so yes things are possible in PSTN, but not easy like SSIDs. There is really a scale of difference in the attack. > > And EAP lacks an announcement of here you are. So the STA uses the > > SSID. 'The SSID is CORPORATE, therefore use my company ID'. This > > according to some draft stuff I have seen is how XP works with TLS > certs ( > > :) ). > >Actually, EAP *does* support this -- there is nothing to stop a client >from sending an EAP-Request/Identity to a AAA server. In PPP this is >expected. In 802.1X it is not. Maybe because it is so weak an assurance, why bother? > > Where in the RFC or the draft does it say this? In fact 2845 says: oops 2945. > > SRP also has the added advantage of permitting the host to store > > passwords in a form that is not directly useful to an attacker. Even > > if the host's password database were publicly revealed, the attacker > > would still need an expensive dictionary search to obtain any > > passwords. The exponential computation required to validate a guess > > in this case is much more time-consuming than the hash currently used > > by most UNIX systems. Hosts are still advised, though, to try their > > best to keep their password files secure. > > > > Advised. Not you had better! > >Point taken. I think that the language should be considerably >stronger. Since the major advantage of SRP is dictionary attack >resistance, this seems like a MUST to me. agreed. > > >At various points in the EAP SRP protocol, the client is supposed to > > >disconnect, if the AAA server doesn't behave as expected. Are you claiming > > >that there is information leakage which isn't addressed in the spec? > > > > Oh, no. That is the beauty of this risk. There is no leakage in the > > protocol and everyone things everything is fine. The analysis is that the > > credentials work on any AAA server. So you trick the client to go to the > > rogue server through a rogue access point. This can be done in 802.11 > > fairly easily, but not in so easily in PPP. I do not know enough about > > PPPoE implementations to know if this also has a similar risk. > >OK, it's just verifier leakage then. But we should probably go over it >again with a fine tooth comb to make sure. I have, but I am not a cryptographer. Perhaps a question directed to Tom might provide an analysis paper. > > But there is a body of knowledge about passwords and their theft. 'public > > verifier' (words from the RFC) is a dangerous term. > >Agree. The term is not really appropriate -- and some warning text should >be inserted in the draft. How about this? > > >"EAP SRP implementations MUST protect the verifier against >compromise. While an attacker would still need to carry out a dictionary >attack against a compromised verifier in order to recover the shared >secret, such a compromise does enable an attacker to impersonate an EAP >authenticator. Therefore, EAP SRP implementations MUST NOT treat the >verifier as public information." yes. > > The security of the credentials stored in the authenticator's data- > > base relies on the entropy in the chosen password, the difficulty of > > hash inversion of a salted string, and the security of the system > > containing the database. For this reason, the chosen password SHOULD > > be restricted to limit the effectiveness of dictionary attacks > > against a disclosed database. However, since typical passwords have > > only a few bits of entropy, the database itself MUST be protected > > against disclosure. > > > > I can see systems that will enforce a reasonable level of entropy get this > > wrong. And since the RFC is more lenient, there should be something here > > stating why. Perhaps reference to a paper or two. > >Any suggested papers to reference? No. Rather on suggestions on who to ask, like Tom Wu. > > I have talked to Tom Wu about this. As long as it is 2 exchanges, not one > > exchange with 2 identites, it is not covered by the patent. > >OK. Are you saying that there should be language encouraging use of 2 >exchanges, one for each direction? Yes. And perhaps an example of how to do it in fewer than 8 packets by doing multiple operations. But then I am not really fluent in EAP and it might not allow that. I would like to have a submission like this for the Nov 802 meeting in Austin. From owner-ietf-ppp@merit.edu Wed Oct 17 07:13:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17981 for ; Wed, 17 Oct 2001 07:13:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0377B9126B; Wed, 17 Oct 2001 07:13:31 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C148A9126D; Wed, 17 Oct 2001 07:13:30 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A2E569126B for ; Wed, 17 Oct 2001 07:13:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 780BB5DDAF; Wed, 17 Oct 2001 07:13:29 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 09F665DD9D for ; Wed, 17 Oct 2001 07:13:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17915; Wed, 17 Oct 2001 07:13:26 -0400 (EDT) Message-Id: <200110171113.HAA17915@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-00.txt Date: Wed, 17 Oct 2001 07:13:26 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-rfc2284bis-00.txt Pages : 20 Date : 16-Oct-01 This document defines the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-00.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-pppext-rfc2284bis-00.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-pppext-rfc2284bis-00.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: <20011016113129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011016113129.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Wed Oct 17 07:14:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18044 for ; Wed, 17 Oct 2001 07:14:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A12891274; Wed, 17 Oct 2001 07:13:39 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E72BD91271; Wed, 17 Oct 2001 07:13:38 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0325C9126D for ; Wed, 17 Oct 2001 07:13:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4BE25DDAF; Wed, 17 Oct 2001 07:13:34 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 669D05DD9D for ; Wed, 17 Oct 2001 07:13:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17932; Wed, 17 Oct 2001 07:13:31 -0400 (EDT) Message-Id: <200110171113.HAA17932@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-otp-00.txt Date: Wed, 17 Oct 2001 07:13:31 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : The One Time Password (OTP) and Generic Token Card Authentication Protocols Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-otp-00.txt Pages : 12 Date : 16-Oct-01 EAP is an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and re-transmission. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document defines the One Time Password (OTP) and Generic Token Card EAP methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-otp-00.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-pppext-otp-00.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-pppext-otp-00.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: <20011016113137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-otp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-otp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011016113137.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Wed Oct 17 07:55:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19256 for ; Wed, 17 Oct 2001 07:55:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B02CC91233; Wed, 17 Oct 2001 07:55:14 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E22A91242; Wed, 17 Oct 2001 07:55:14 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65A8391233 for ; Wed, 17 Oct 2001 07:55:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39D5E5DDC6; Wed, 17 Oct 2001 07:55:13 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from htt-consult.com (homebase.htt-consult.com [65.84.78.210]) by segue.merit.edu (Postfix) with SMTP id C83E35DD9D for ; Wed, 17 Oct 2001 07:55:12 -0400 (EDT) Received: from portege3490.htt-consult.com ([65.84.78.214]) by htt-consult.com ; Wed, 17 Oct 2001 07:55:14 -0400 Message-Id: <5.1.0.14.2.20011017075105.02632d60@localhost> X-Sender: rgm-ietf@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Oct 2001 07:54:54 -0400 To: Bernard Aboba From: Robert Moskowitz Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt Cc: ietf-ppp@merit.edu In-Reply-To: References: <5.1.0.14.2.20011016223322.02668e98@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 08:39 PM 10/16/2001 -0700, Bernard Aboba wrote: > > I have talked to Tom Wu about this. As long as it is 2 exchanges, not one > > exchange with 2 identites, it is not covered by the patent. > >OK. Are you saying that there should be language encouraging use of 2 >exchanges, one for each direction? I forgot to mention one VERY important aspect of this in light of the dictionary attack against the password verifier. Every client will have the server's password verifier. It is PUBLIC. Thus the password has to have adequate entropy to be resilient against dictionary attacks. a 64 bit random number SHOULD do it. But probably 96 bits or even 128 bits is best. A random password for a server is not a problem. It is entered once into the server and promptly forgotten. Of course, like any private key, the server needs to protect it very well (Dah, like this is any different from TLS). From owner-ietf-ppp@merit.edu Wed Oct 17 11:51:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28014 for ; Wed, 17 Oct 2001 11:51:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEF4591209; Wed, 17 Oct 2001 11:50:54 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0F149124B; Wed, 17 Oct 2001 11:50:54 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E0B291209 for ; Wed, 17 Oct 2001 11:50:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5584D5DDD0; Wed, 17 Oct 2001 11:50:53 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8FE9D5DD9D for ; Wed, 17 Oct 2001 11:50:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA11842; Wed, 17 Oct 2001 08:43:08 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 17 Oct 2001 08:43:08 -0700 (PDT) From: Bernard Aboba To: Robert Moskowitz Cc: ietf-ppp@merit.edu Subject: Re: Security comment on draft-ietf-pppext-eap-srp-03.txt In-Reply-To: <5.1.0.14.2.20011017075105.02632d60@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > I forgot to mention one VERY important aspect of this in light of the > dictionary attack against the password verifier. > > Every client will have the server's password verifier. It is PUBLIC. You're assuming two one-way authentications, correct? In SRP, the client does *not* have the server's verifier, only its own. Also, you are assuming that the server's verifier is the same for every client. > Thus > the password has to have adequate entropy to be resilient against > dictionary attacks. a 64 bit random number SHOULD do it. But probably 96 > bits or even 128 bits is best. How about this: "If two authentications are being done, once in each direction, then the client will need to store the server's verifier, in addition to its own. If the server verifier is the same for each client, then this constitutes a public quantity, and needs to have adequate entropy to be resilient against dictionary attack. The server verifier MUST have at least 64 bits of entropy, and SHOULD have at least 128 bits." > > A random password for a server is not a problem. It is entered once into > the server and promptly forgotten. Of course, like any private key, the > server needs to protect it very well (Dah, like this is any different from > TLS). > > > From owner-ietf-ppp@merit.edu Sat Oct 20 11:34:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16428 for ; Sat, 20 Oct 2001 11:34:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4323491217; Sat, 20 Oct 2001 11:34:28 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1520B9121A; Sat, 20 Oct 2001 11:34:27 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E493C91217 for ; Sat, 20 Oct 2001 11:34:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9A725DDD3; Sat, 20 Oct 2001 11:34:26 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (dhcp93125084.columbus.rr.com [24.93.125.84]) by segue.merit.edu (Postfix) with ESMTP id 4A74E5DDCB for ; Sat, 20 Oct 2001 11:34:26 -0400 (EDT) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Sat, 20 Oct 2001 11:33:47 -0400 Message-Id: <4.3.2.7.2.20011020113323.05629cd0@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 20 Oct 2001 11:33:44 -0400 To: Thomas Narten From: Karl Fox Subject: Re: PPP Multiplexed to Proposed Standard Cc: Erik Nordmark , ietf-ppp@merit.edu, Steve Coya In-Reply-To: <200110200202.f9K22Tt02520@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thank you! Karl At 10:02 PM 10/19/01, Thomas Narten wrote: >Back on Oct 6... > >Karl Fox writes: > >> Thomas and Erik, > >> The PPPEXT Working Group recommends that PPP Multiplexed >> (draft-ietf-pppext-pppmux-03.txt) be advanced to Proposed Standard. > >To clarify. The IESG approved this ID as a PS back in July, and the >RFC apparently came out in August. However, the announcement of the >RFC apparently never went out (there was a bug and no announcements >were going out for a while). > >So, this document is already out as RFC 3153. > >Thomas From owner-ietf-ppp@merit.edu Thu Oct 25 03:49:06 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11326 for ; Thu, 25 Oct 2001 03:49:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0456891212; Thu, 25 Oct 2001 03:48:35 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA87991214; Thu, 25 Oct 2001 03:48:34 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F33B91212 for ; Thu, 25 Oct 2001 03:48:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5973F5DDAB; Thu, 25 Oct 2001 03:48:33 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from fsnt.future.futsoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id 6FB3F5DD96 for ; Thu, 25 Oct 2001 03:48:32 -0400 (EDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 25 Oct 2001 13:30:19 +0530 Received: from aruljp (aruljp.future.futsoft.com [10.6.12.21]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id f9P7lvd14168 for ; Thu, 25 Oct 2001 13:17:57 +0530 Reply-To: From: "Arul J.P." To: Subject: PPPOE Doubts Date: Thu, 25 Oct 2001 13:18:18 +0530 Message-Id: <000c01c15d29$6a05eca0$150c060a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, Please clarify the following doubts. 1. If PPPOE is used for service selection, wthether service selection during PPP authentication is not necessary. 2. If the service profile for the user is retrieved from the radius server, wthether the service name TAG present in PPPOE is used as the user name is Access-Request packet. 3. If PPPOE service name indicates the user has to be tunneled to a corporate gateway, then is it correct to tunnel the user to corporate gateway without authenticating the user. 4. Please give an example for PPPOE service name tag if PPPOE is used for service selection. 5. Please give an example for PPP user name if PPP is used for service selection. Thanks and Regards, Arul Mohan. --- J.P. Arul Mohan Senior Software Engineer Phone No: 4330550 Extn: 339 email: aruljp@future.futsoft.com From owner-ietf-ppp@merit.edu Thu Oct 25 05:37:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12358 for ; Thu, 25 Oct 2001 05:37:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 585469129D; Thu, 25 Oct 2001 05:37:23 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25F469129E; Thu, 25 Oct 2001 05:37:23 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D13309129D for ; Thu, 25 Oct 2001 05:37:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A3F615DDAB; Thu, 25 Oct 2001 05:37:21 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from bjapp4.163.net (unknown [202.108.255.197]) by segue.merit.edu (Postfix) with ESMTP id 45B385DD9A for ; Thu, 25 Oct 2001 05:37:21 -0400 (EDT) Received: from book-xiaolee (unknown [61.153.40.79]) by bjapp4.163.net (Postfix) with ESMTP id 22B911CCC02DB; Thu, 25 Oct 2001 17:37:18 +0800 (CST) Date: Thu, 25 Oct 2001 17:37:3 +0800 From: xiaolee To: "aruljp@future.futsoft.com" Cc: "ietf-ppp@merit.edu" Subject: Re: PPPOE Doubts X-mailer: FoxMail 3.11 Release [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20011025093718.22B911CCC02DB@bjapp4.163.net> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit 1. If PPPOE is used for service selection, wthether service selection during PPP authentication is not necessary. // i doubt that whether the ppp supports service selection or not, as i know, it does not. // in my opinion, it is good idea to do the service selection in the ppp protocol after the // authentication if finished. u know, the ppp is so pop for a user to access the network. // if we do so, pppoe, l2tp can all benefit from this. 2. If the service profile for the user is retrieved from the radius server, wthether the service name TAG present in PPPOE is used as the user name is Access-Request packet. // this may need more TLV for radius to be defined, while not a new user account to be used. 3. If PPPOE service name indicates the user has to be tunneled to a corporate gateway, then is it correct to tunnel the user to corporate gateway without authenticating the user. // it may need two steps authentication, first for dialing in the local access server, and // second for dialing in the remote access server. 4. Please give an example for PPPOE service name tag if PPPOE is used for service selection. // u can find what u want in the follow drafts: // draft-penno-pppoe-ext-service-03.txt // draft-penno-pppoe-ext-qos-00.txt 5. Please give an example for PPP user name if PPP is used for service selection. Thanks and Regards, Arul Mohan. From owner-ietf-ppp@merit.edu Tue Oct 30 08:16:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27568 for ; Tue, 30 Oct 2001 08:16:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E35609129D; Tue, 30 Oct 2001 08:15:13 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE5DB9129E; Tue, 30 Oct 2001 08:15:13 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63D959129D for ; Tue, 30 Oct 2001 08:15:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07B0A5DD9F; Tue, 30 Oct 2001 08:15:12 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-189.aiinet.com [38.195.70.189]) by segue.merit.edu (Postfix) with ESMTP id 5DB385DD95 for ; Tue, 30 Oct 2001 08:15:11 -0500 (EST) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 30 Oct 2001 08:14:14 -0500 Message-Id: <4.3.2.7.2.20011030081115.0597ab80@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 08:14:11 -0500 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: PPP over AAL2 to Proposed Standard Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that PPP over AAL2 (draft-ietf-pppext-ppp-over-aal2-01.txt) be advanced to Proposed Standard. From owner-ietf-ppp@merit.edu Tue Oct 30 08:17:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27651 for ; Tue, 30 Oct 2001 08:17:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 721DE9129E; Tue, 30 Oct 2001 08:17:31 -0500 (EST) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF925912A0; Tue, 30 Oct 2001 08:17:29 -0500 (EST) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71B409129E for ; Tue, 30 Oct 2001 08:17:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 579605DD9F; Tue, 30 Oct 2001 08:17:28 -0500 (EST) Delivered-To: ietf-ppp@merit.edu Received: from karl-w98l (ai70-189.aiinet.com [38.195.70.189]) by segue.merit.edu (Postfix) with ESMTP id AC9285DD95 for ; Tue, 30 Oct 2001 08:17:27 -0500 (EST) Received: from [127.0.0.1] by karl-w98l (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 30 Oct 2001 08:16:35 -0500 Message-Id: <4.3.2.7.2.20011030081445.00affa70@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Oct 2001 08:16:32 -0500 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: Class Extensions for PPP over AAL2 to Proposed Standard Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that Class Extensions for PPP over AAL2 (draft-ietf-pppext-ppp-over-aal2-class-00.txt) be advanced to Proposed Standard.