From ietf-ppp-request@MERIT.EDU Fri Aug 2 07:07:18 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA15783; Fri, 2 Aug 1996 07:07:18 -0400 (EDT) Resent-Date: Fri, 2 Aug 1996 07:07:18 -0400 (EDT) Date: Fri, 2 Aug 96 06:31:08 EDT From: Ben.McCann@proteon.com (Ben McCann) Message-Id: <9608021031.AA20736@kerplop.proteon.com> To: gurdeep@microsoft.com Cc: ietf-ppp@MERIT.EDU In-Reply-To: <9607310918.aa02802@ietf.org> (Internet-Drafts@ietf.org) Subject: Microsoft Point-To-Point Compression (MPPC) Protocol Resent-Message-ID: <"xoJL43.0.9s3.A4U0o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1825 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I scanned your draft. If I'm correct, the motivation for this compression protocol is its small history size and rapid execution time thus making it suitable for systems running many parallel PPP sessions. Is this essentially correct? I'm curious, do you have any data about the compression factors achieved by your algorithm or benchmarks on its throughput? Can you contrast it to STAC's LZS which was recently ratified to RFC status? -Ben McCann --- Ben McCann, bem@proteon.com Proteon, MailStop #21, 9 Technology Drive, Westborough, MA 01581-1799 Tel: (508) 898-2800 x2540 FAX: (508) 898-3176 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 2 07:53:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA16448; Fri, 2 Aug 1996 07:53:31 -0400 (EDT) Resent-Date: Fri, 2 Aug 1996 07:53:31 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 2 Aug 1996 12:47:32 +0100 Message-ID: <201ec280@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Self-Describing-Padding and Multilink To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"e_3yi1.0.h04.smU0o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1826 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Am I right in saying that, when implementing self-describing-padding, you need to know exactly which protocols to remove the padding from, and that you can't assume every protocol is going to be padded ? Which are the "identified special protocols" that require trailing padding to be removed (other than Multilink) ? So far I haven't supported padding in my Multilink PPP implementation (because I don't know which other protocols it will apply to), although RFC1717 recommends that I SHOULD do so - does anyone know if I am likely to encounter problems as a result ? Also, does anyone know what's happening with the recently expired draft-ietf-pppext-multilink-12 - is there a new version out, or is it to be ratified to RFC status to obsolete 1717 ? -- Jonathan Goodchild Racal Datacom Ltd, Hook, Hampshire, England EMail: Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 2 09:34:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA18101; Fri, 2 Aug 1996 09:34:17 -0400 (EDT) Resent-Date: Fri, 2 Aug 1996 09:34:17 -0400 (EDT) Date: Fri, 2 Aug 1996 07:33:57 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608021333.HAA09762@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Self-Describing-Padding and Multilink Resent-Message-ID: <"jJEKF2.0.WQ4.HFW0o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1827 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) > Am I right in saying that, when implementing self-describing-padding, > you need to know exactly which protocols to remove the padding from, > and that you can't assume every protocol is going to be padded ? > > Which are the "identified special protocols" that require trailing > padding to be removed (other than Multilink) ? I thought that once you negotiate it, all packets must be padded. Otherwise, the peer will be stripping good bytes from the packets you system sends. > So far I haven't supported padding in my Multilink PPP implementation > (because I don't know which other protocols it will apply to), > although RFC1717 recommends that I SHOULD do so - does anyone know if > I am likely to encounter problems as a result ? > ... I've never seen any system ask for self-describing padding. I thought it had been agreed that self-describing padding was headed for the bit bucket, and recently ripped it out of my code. Consider all except the first sentence of section 3.1 of RFC 1717 for why you do not really need self-describing padding with Multilink. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 2 09:59:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA18697; Fri, 2 Aug 1996 09:59:12 -0400 (EDT) Resent-Date: Fri, 2 Aug 1996 09:59:12 -0400 (EDT) From: "rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com Message-Id: <199608021400.QAA21281@vbormc.vbo.dec.com> Date: Fri, 2 Aug 96 16:00:00 MET DST To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: PPP forum meeting minutes Resent-Message-ID: <"K2mx81.0.mZ4.hcW0o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1828 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: NAME: Stephen Waters (MARVIN::WATERS) TEL: +44 (0) 1548 831170 ADDR: marvin::waters To: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Are the PPP forum meeting minutes kept on-line? If not, can someone mail me a copy of the last meeting minutes? Cheers, Steve. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 2 12:23:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA21089; Fri, 2 Aug 1996 12:23:28 -0400 (EDT) Resent-Date: Fri, 2 Aug 1996 12:23:28 -0400 (EDT) Message-Id: <199608021623.SAA29943@vbormc.vbo.dec.com> Date: Fri, 2 Aug 96 18:23:57 MET DST From: 02-Aug-1996 1722 +0100 <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com> To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: comment on PPP minutes Resent-Message-ID: <"nHKqQ3.0.695.ojY0o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1829 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: NAME: Stephen Waters (MARVIN::WATERS) TEL: +44 (0) 1548 831170 ADDR: marvin::waters To: NAME: ietf-ppp <"ietf-ppp@merit.edu"@nm%vbormc@MRGATE> >1. LCP Extensions (draft-ietf-pppext-lcpext-ds-00.txt) > >Bill Simpson led a discussion of the various LCP extensions >described in the document. >Bill said this draft has been on hold waiting for someone >who wanted to change callback. >An informal poll showed that there are 2 implementations of the >Identification option, and 2 implementations of callback. >Discussion revealed there is concern that the callback option is >not ready yet. > >Resolution is that Callback option will be stripped from current >draft and made into a separate draft, so that the remaining LCP >extensions can continue on the standards track. >draft-ietf-pppext-lcpext-ds will then be resubmitted and sent >out for working group last call. Who is working the new LCP CallBack draft? Bill? Cheers, Steve. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 6 13:40:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA19507; Tue, 6 Aug 1996 13:40:12 -0400 (EDT) Resent-Date: Tue, 6 Aug 1996 13:40:12 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'Ben.McCann@proteon.com'" Cc: "'ietf-ppp@MERIT.EDU'" Subject: FW: Microsoft Point-To-Point Compression (MPPC) Protocol Date: Tue, 6 Aug 1996 10:28:28 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 36 TEXT Resent-Message-ID: <"el2db1.0.zl4.1Du1o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1830 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > >---------- >From: Ben.McCann@proteon.com[SMTP:Ben.McCann@proteon.com] >Sent: Friday, August 02, 1996 3:31 AM >To: Gurdeep Singh Pall >Cc: ietf-ppp@MERIT.EDU >Subject: Microsoft Point-To-Point Compression (MPPC) Protocol > >I scanned your draft. If I'm correct, the motivation for this >compression protocol is its small history size and rapid execution >time thus making it suitable for systems running many parallel PPP >sessions. Is this essentially correct? > >Gurdeep> This is correct. > >I'm curious, do you have any data about the compression factors >achieved by your algorithm or benchmarks on its throughput? Can you >contrast it to STAC's LZS which was recently ratified to RFC status? > >Gurdeep> From our evaluation, STAC LZS offers more features (multiple >history's, history update for uncompressed packets, CPU >utilization/compressibility tradeoffs, etc.) than MPPC. MPPC on the other >hand is "optimal" in CPU utilization/compression - in our tests the STAC >scheme would either compress at comparable rates and give lower compression >ratio - or give comparable compression ratio and compress significantly >slower. While I've shared these numbers with STAC, I cannot discuss them on >this list. MPPC documents the compression scheme implemented in Win95 and NT. I will be shortly posting a draft that documents MPPE (Microsoft Point-to-Point Encryption) that goes hand-in-glove with MPPC and provides RSA RC4 encryption for PPP payloads. (I'll appreciate if >questions regarding MPPE are held off until the draft is posted) > > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 8 15:12:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA25031; Thu, 8 Aug 1996 15:12:34 -0400 (EDT) Resent-Date: Thu, 8 Aug 1996 15:12:34 -0400 (EDT) Message-Id: <199608081913.AA19637@seegiri.NSD.3Com.COM> To: ietf-ppp@MERIT.EDU Subject: Question on ...Stacker-10.txt. Organization: 3Com, 5400 Bayfront Plaza, P.O.Box 58145, Santa Clara, CA 95052 Phone.......: (408) 764-6333 (Office) (415) 969-4400 (General Office) Date: Thu, 08 Aug 1996 12:13:52 -0700 From: "Podi Kuruppu" Resent-Message-ID: <"NfhV11.0.h66.clZ2o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1831 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, I have 2 questions on draft-ietf-pppext-stacket-10.txt. First has to do with section 2.5.4, where it says, "on receipt, if Sequence Number one (1) follows any other number than zero (0), or is otherwise out of sequence,..." I really do not quite follow the logic here. Can somebody please simplify this for me? In section 2.5.3.3 Sequence Number, It states that, "...After CCP has reached the open state, the transmitter MUST set the value of the sequence number field (the sequence number of the packet) to "1" . Why 1 ? why not 0? Thanks, -Podibanda Kuruppu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 9 05:35:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA04314; Fri, 9 Aug 1996 05:35:58 -0400 (EDT) Resent-Date: Fri, 9 Aug 1996 05:35:58 -0400 (EDT) From: Manas Barooah Message-Id: <199608091008.PAA19177@comm10> Subject: SOS for remote bridging .. To: ietf-ppp@MERIT.EDU Date: Fri, 9 Aug 1996 15:08:25 +0500 (GMT+0500) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6L-441.0.131.EPm2o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1832 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all, I have certain doubts regarding remote bridging after going through the rfc on PPP Bridging Control Protocol (rfc1638). They are. 1. What do you mean by a system which implement LAN Frame Checksum preservation? Does it mean a system that modifies the LAN packet before transmission, without re-calculating the checksum of the new packet either in Software or in Hardware. 2. If after running 802.1d Spanning tree algorithm on remote bridge ports, we reach a condition when the port's state becomes blocking. Then is there any such standard methods of bringing down the physical connection, to save call charges and making it up once a topology change changes the state of the port to forwarding from blocking. When considering remote bridge ports I am talking of ports connected to PSTN links via modems only. 3. What is the frame type used by a BPDU on an Ethernet 802.3 LAN. Is is Ethernet_802.2 or some other type. Thanking you in advance. Manas (manas@wipinfo.soft.net) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 9 07:38:25 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA05278; Fri, 9 Aug 1996 07:38:25 -0400 (EDT) Resent-Date: Fri, 9 Aug 1996 07:38:25 -0400 (EDT) Sender: rkb@NetEdge.COM Message-Id: <320B2308.41C67EA6@NetEdge.com> Date: Fri, 09 Aug 1996 07:37:44 -0400 From: Rich Bowen Organization: NetEdge Systems, Inc. X-Mailer: Mozilla 3.0b5aGold (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: Manas Barooah Cc: ietf-ppp@MERIT.EDU Subject: Re: SOS for remote bridging .. References: <199608091008.PAA19177@comm10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"KYgt83.0.5I1.iCo2o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1833 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Manas Barooah wrote: > 1. What do you mean by a system which implement LAN Frame Checksum > preservation? > > Does it mean a system that modifies the LAN packet > before transmission, without re-calculating the checksum of the > new packet either in Software or in Hardware. > No, if the FCS is preserved it must be valid. When a system bridges a packet between like media types, it may preserve the original FCS since it does not need to modify the frame (except in the case of source routing explorer frames). Similarly, when bridging from a LAN interface to a PPP interface the FCS can generally be preserved since, for instance, an Ethernet frame can be bridged as a PPP- encapsulated Ethernet frame. The frame is encapsulated but not modified, so the original FCS can be preserved. If a LAN frame is modified before transmission on the PPP interface the FCS must be removed or recalculated. > 2. If after running 802.1d Spanning tree algorithm on remote > bridge ports, we reach a condition when the port's state > becomes blocking. Then is there any such standard methods of > bringing down the physical connection, to save call charges > and making it up once a topology change changes the state > of the port to forwarding from blocking. When considering > remote bridge ports I am talking of ports connected to > PSTN links via modems only. > There is no standard method of doing so that I am aware of. The problem that such a method would have to solve is that as soon as the physical connection goes down the port stops receiving BPDUs, causing the port to go back into forwarding state -- you would have endless oscillations. > 3. What is the frame type used by a BPDU on an Ethernet 802.3 > LAN. Is is Ethernet_802.2 or some other type. > 802.1d BPDUs use IEEE 802.3 format with an LLC header of 0x42-42-03. Rich -------------------------------------------------------------------- Richard K. Bowen NetEdge Systems Phone: 919-991-9041 P.O. Box 14993 E-Mail: Rich_Bowen@NetEdge.com RTP, NC 27709-4993 1-800-NETEDGE -------------------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Aug 10 22:22:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA24274; Sat, 10 Aug 1996 22:22:58 -0400 (EDT) Resent-Date: Sat, 10 Aug 1996 22:22:58 -0400 (EDT) Message-Id: <199608110217.TAA00787@chaos.gordian.com> To: ietf-ppp@MERIT.EDU cc: steveh@gordian.com Subject: ATCP status? Date: Sat, 10 Aug 1996 19:17:01 -0700 From: Jay Laefer Resent-Message-ID: <"q7VWx3.0.Mw5.8BK3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1834 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What is the status on updating RFC 1378, AppleTalk Control Protocol? Two years ago, draft-ietf-pppext-atcp2-00.txt was released which contained some clarifications and at least one major change to ATCP. Obviously, that draft expired quite a while ago. The major change was that dial-up users were now placed on an extended network. RFC 1378 specified a nonextended network. At least one (nameless) vendor requires that the network be extended based on the expired atcp2 draft. That same vendor also requests that no RTMP packets be sent, but fails to work unless they are. Another vendor does not negotiate for the routing protocol (which defaults to RTMP), but fails to work properly if RTMP packets are sent. Considering that I only know of 3 dial-up ATCP packages, this represents a real problem for our attempt to implement an ATCP dial-up server. -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Aug 11 21:57:24 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA03825; Sun, 11 Aug 1996 21:57:24 -0400 (EDT) Resent-Date: Sun, 11 Aug 1996 21:57:24 -0400 (EDT) Date: Mon, 12 Aug 1996 02:00:27 GMT Message-Id: <199608120200.CAA10776@carp.morningstar.com> From: Karl Fox To: Jay Laefer Cc: ietf-ppp@MERIT.EDU, steveh@gordian.com Subject: ATCP status? In-Reply-To: <199608110217.TAA00787@chaos.gordian.com> References: <199608110217.TAA00787@chaos.gordian.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"KcqBv2.0.Cx.uye3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1835 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Jay Laefer writes: > What is the status on updating RFC 1378, AppleTalk Control Protocol? > > Two years ago, draft-ietf-pppext-atcp2-00.txt was released which > contained some clarifications and at least one major change to ATCP. I don't have a copy of that draft--did Brad Parker write it? Brad, are you out there? If not, does anyone know what his e-mail address is? -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 *** NOTE: NEW PHONE NUMBER *** - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Aug 11 23:02:32 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id XAA04380; Sun, 11 Aug 1996 23:02:32 -0400 (EDT) Resent-Date: Sun, 11 Aug 1996 23:02:32 -0400 (EDT) Message-Id: <199608120301.UAA01978@chaos.gordian.com> In-reply-to: karl@ascend.com's message of Mon, 12 Aug 1996 02:00:27 GMT To: ietf-ppp@MERIT.EDU Subject: Re: ATCP status? References: <199608110217.TAA00787@chaos.gordian.com> <199608120200.CAA10776@carp.morningstar.com> Date: Sun, 11 Aug 1996 20:01:50 -0700 From: Jay Laefer Resent-Message-ID: <"lZyRg.0.741.1xf3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1836 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl Fox writes: >Jay Laefer writes: >> Two years ago, draft-ietf-pppext-atcp2-00.txt was released which >> contained some clarifications and at least one major change to ATCP. > >I don't have a copy of that draft--did Brad Parker write it? Brad, >are you out there? If not, does anyone know what his e-mail address >is? Yes, Brad Parker wrote it. The date on the draft is July 1994, and the author's address is listed as brad@fcr.com. The address appears to be current. FYI, I only have a hardcopy of the draft. -Jay Laefer jay@gordian.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 12 06:44:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA07258; Mon, 12 Aug 1996 06:44:40 -0400 (EDT) Resent-Date: Mon, 12 Aug 1996 06:44:40 -0400 (EDT) From: Craig Fox Message-Id: <199608121042.DAA07218@greatdane.cisco.com> Subject: Re: ATCP status? To: jay@gordian.com (Jay Laefer) Date: Mon, 12 Aug 96 3:42:59 PDT Cc: ietf-ppp@MERIT.EDU, brad@american.com In-Reply-To: <199608120301.UAA01978@chaos.gordian.com>; from "Jay Laefer" at Aug 11, 96 8:01 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"pDyrN3.0.5n1.rhm3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1837 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Karl Fox writes: > >Jay Laefer writes: > >> Two years ago, draft-ietf-pppext-atcp2-00.txt was released which > >> contained some clarifications and at least one major change to ATCP. > > > >I don't have a copy of that draft--did Brad Parker write it? Brad, > >are you out there? If not, does anyone know what his e-mail address > >is? > > Yes, Brad Parker wrote it. The date on the draft is July 1994, and > the author's address is listed as brad@fcr.com. The address appears > to be current. > I believe that he is still reachable thru that address as he is still a boardmember for FCR, but the most recent address that I had for him (from May this year) is 'brad@american.com'. I have copied him on this message in case he slipped off of the mailing list. Craig > FYI, I only have a hardcopy of the draft. > > > -Jay Laefer > jay@gordian.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 12 08:34:28 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA08302; Mon, 12 Aug 1996 08:34:28 -0400 (EDT) Resent-Date: Mon, 12 Aug 1996 08:34:28 -0400 (EDT) MR-Received: by mta SUTRA.MUAS; Relayed; Mon, 12 Aug 1996 13:37:54 +0000 MR-Received: by mta VALMTS; Relayed; Mon, 12 Aug 1996 12:34:09 +0000 Disclose-recipients: prohibited Date: Mon, 12 Aug 1996 13:37:54 +0000 (GMT) From: "Pasi Kinnari, OSSG/PATHWORKS Remote Engineering" Subject: PPP BSD Compress question To: ietf-ppp@MERIT.EDU Message-id: <7454371412081996/A43749/SUTRA/11A863A53500*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal Sensitivity: Company-Confidential UA-content-id: 11A863A53500 X400-MTS-identifier: [;7454371412081996/A43749/SUTRA] Hop-count: 1 Resent-Message-ID: <"w74wF2.0.K12.FJo3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1838 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have one situation, which I don't know how to implement related to the PPP BSD Compress. I tried to find the answer from the draft (Oct 95), but didn't find it. If I have a situation, where the compressed packet expands, I'm supposed to send it uncompressed. The compression requires, that before the compression the protocol field is "PPP protocol field compressed" even if the protocol field compression is not negociated. If the protocol field compression is not negociated, should I send the packet this field uncompressed (but my compression dictionary was updated with the compressed protocol field)? This means, that when the receiver updates its dictionary, it needs to check, if the field is not compressed and can it be compressed. If yes, then update the dictionary with the compressed protocol field instead of the received field (which was uncompressed). Otherwise update with the packet as it is. I hope I explaned my problem clearly enough. //pasi - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 12 11:38:54 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA11161; Mon, 12 Aug 1996 11:38:54 -0400 (EDT) Resent-Date: Mon, 12 Aug 1996 11:38:54 -0400 (EDT) Date: Mon, 12 Aug 1996 09:38:29 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608121538.JAA03038@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: PPP BSD Compress question Cc: kinnari@AM_SUTRA.VALMTS.VBE.mts.dec.com Resent-Message-ID: <"CSxGh1.0.3k2.10r3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1839 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Pasi Kinnari, OSSG/PATHWORKS Remote Engineering" > I have one situation, which I don't know how to implement > related to the PPP BSD Compress. I tried to find the answer > from the draft (Oct 95), but didn't find it. > > If I have a situation, where the compressed packet expands, > I'm supposed to send it uncompressed. The compression requires, > that before the compression the protocol field is "PPP protocol > field compressed" even if the protocol field compression is not > negociated. > > If the protocol field compression is not negociated, should I send > the packet this field uncompressed (but my compression dictionary > was updated with the compressed protocol field)? This means, > that when the receiver updates its dictionary, it needs to check, > if the field is not compressed and can it be compressed. If yes, > then update the dictionary with the compressed protocol field instead > of the received field (which was uncompressed). Otherwise update > with the packet as it is. > > I hope I explaned my problem clearly enough. The current definition of "BSD Compress" is in RFC 1977. I do not understand the question. On one hand, no compressed packets should be sent before compression is negotiated. Until and unless compression is negotiated, the (de)compression machinery may as well be turned off. On the other hand, all packets after the Configure-Ack finishing the negotiation of compression and with protocol numbers in the relevant range are assumed to be "compressed". So called "compressed" packets after the CCP Configure-Ack with protocol IDs of other 0xfd or 0xfb must be run though the dictionary in order to keep the dictonary up to date. The dictionary must be reset upon the receipt of a CCP Configure-Ack (since that resets the PPP FSM) or of a Reset-Request. Perhaps the words in RFC 1979 (Deflate) would make the scheme clear. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 12 12:18:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA11831; Mon, 12 Aug 1996 12:18:48 -0400 (EDT) Resent-Date: Mon, 12 Aug 1996 12:18:48 -0400 (EDT) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Protocol Action: The PPP SNA Control Protocol (SNACP) to Proposed Standard Date: Mon, 12 Aug 1996 11:33:14 -0400 Sender: scoya@ietf.org Message-ID: <9608121133.aa00014@ietf.org> Resent-Message-ID: <"MKNGZ2.0.Wu2.abr3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1840 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has approved the Internet-Draft "The PPP SNA Control Protocol (SNACP)" as a Proposed Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary Multiple higher-level protocols may operate over PPP links. For a protocol to be carried over a PPP link, a control protocol is required. This control protocol is used to negotiate the operations of that protocol. The PPP SNA Control Protocol is used to configure and control PPP links to carry SNA traffic. Working Group Summary This protocol was developed in the PPPEXT working group. Development was without rancor. Protocol Quality The protocol has been reviewed by Frank Kastenholz. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 12 13:05:40 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA12900; Mon, 12 Aug 1996 13:05:40 -0400 (EDT) Resent-Date: Mon, 12 Aug 1996 13:05:40 -0400 (EDT) From: "valmts::valmts::mrgate::vbe::valmts::am_sutra::kinnari"@sutra.enet.dec.com Message-Id: <199608121706.TAA05760@vbormc.vbo.dec.com> Date: Mon, 12 Aug 96 19:06:13 MET DST To: vbormc::"ietf-ppp@merit.edu"@sutra.enet.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: re: PPP BSD Compress question Resent-Message-ID: <"lT4RI1.0.F93.QHs3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1841 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: NAME: Pasi Kinnari, OSSG/PATHWORKS Remote Engineering To: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@SUTRA@MRGATE@VALMTS@VBO>, vjs@sgi.com@internet OK, I'll try to explane it using an example: 1. The LCP negociation has been done, No Protocol Field Compression is enabled 2. The CCP negociation has been done, BSD COmpress has been accepted 3. I want to send a IP frame (protocol field x0021) 4. according to the spec, the frame to be compressed is (protocol field compressed) | 0x21 | Data ... | The frame expands, which means, that I need to send an uncompressed frame 5. The question is, which kind of frame do I send a) the uncompressed one, which I have used to update my dictionary, ie. ------------------------------------------ | 0x21 | Data ... | or b) the frame with no protocol field compression | 0x00 | 0x21 | Data ... | The problem with the a) is, that it's not the correct frame to send, because the protocol field compression is not negociated. The problem with the b) is, that the received can't use the full frame to update the dictionary (not the first byte 0x00). My assumption was, that the receiver need to check the received frame, and update the dictionary using or not using the first byte of the uncompressed packet, depending on the ability to compress or not to compress the protocol field. Does this make any more sense or do I have lost the ball totally? //pasi - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 12 15:01:01 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA15175; Mon, 12 Aug 1996 15:01:01 -0400 (EDT) Resent-Date: Mon, 12 Aug 1996 15:01:01 -0400 (EDT) Date: Mon, 12 Aug 1996 12:56:49 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608121856.MAA03492@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU, Subject: re: PPP BSD Compress question Resent-Message-ID: <"YPb2U2.0.oi3.Zzt3o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1842 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Pasi Kinnari, OSSG/PATHWORKS Remote Engineering" > > Subject: re: PPP BSD Compress question > To: "ietf-ppp@MERIT.EDU" > <"\"ietf-ppp@MERIT.EDU\""@VBORMC.SUTRA.MRGATE.VALMTS.VBO.mts.dec.com>, > vjs@sgi.com (as an asside, that To: line looks a little problematic.) > Importance: normal > Priority: normal > Sensitivity: Company-Confidential (is this stuff is really Company-Confidential for Digital? If so, please note my employer.) > ... > I'll try to explane it using an example: > > 1. The LCP negociation has been done, No Protocol Field Compression is enabled > 2. The CCP negociation has been done, BSD COmpress has been accepted > 3. I want to send a IP frame (protocol field x0021) > 4. according to the spec, the frame to be compressed is > (protocol field compressed) > > | 0x21 | Data ... | > > The frame expands, which means, that I need to send an uncompressed frame > > 5. The question is, which kind of frame do I send > > a) the uncompressed one, which I have used to update my dictionary, ie. > ------------------------------------------ > | 0x21 | Data ... | > > or > > b) the frame with no protocol field compression > > | 0x00 | 0x21 | Data ... | > > > The problem with the a) is, that it's not the correct frame to send, because > the protocol field compression is not negociated. > > The problem with the b) is, that the received can't use the full frame to > update the dictionary (not the first byte 0x00). > > My assumption was, that the receiver need to check the received frame, and > update the dictionary using or not using the first byte of the uncompressed > packet, depending on the ability to compress or not to compress the protocol > field. > ... Ok, I think I see the issue. Perhaps the text could have been more clear, but the nice thing about code is that it is generally unambiguous (if not always clear). Consider the function starting on the end of page 16 of RFC 1977. That is the function that updates the dictionary on the receiver to handle a packet that the transmitter thought would expand. Notice that near the top of page 17, the protocol field is counted as a single byte. A few lines later, only one byte of the argument "ent" is fed into the LZW machine. In other words, as far as the compression and decompression stuff is concerned, it does not matter whether un-BSD-compressed packets use compressed-protocol-fields or not. Only the single significant byte of the protocol field is used to update the receiver's dictionary. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 13 18:12:10 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA07842; Tue, 13 Aug 1996 18:12:10 -0400 (EDT) Resent-Date: Tue, 13 Aug 1996 18:12:10 -0400 (EDT) Message-Id: <2.2.32.19960813220720.00635c78@SanFrancisco01.pop.internex.net> X-Sender: larribeau-2@SanFrancisco01.pop.internex.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Aug 1996 15:07:20 -0700 To: kirtley@fcr.com, sjackson@cisco.com, us013307@interramp.com, andya@xylint.co.uk, cleblanc@gandalf.ca, edlee@gandalf.ca, info@isdntek.com, mthorn@frigate.com, joek@isdnsys.com, tmima@netmanage.com, avbustos@novell.com, mph@ftp.com, binh@sbei.com, kpeirce@usr.com, dan_brennan@3mail.3com.com, lisa.mackay@gandalf.ca, doug.bleich@develcon.com, jasonHwang@acer.com.tw, ikhurana@baynetworks.com, ken@anik.skylinetech.com, mbrooks@zyxel.com, leemay_yen@3mail.3com.com, chuck@flowpoint.com, sgw@sgw.xyplex.com, chris_vanciu@dgii.com, todd@netx.nei.com, nareng@microsoft.com, tim_cotton-u2635@email.mot.com, andyni@microsoft.com, 75202.3407@compuserve.com, rfriend@stac.com, gulick@tomg.mko.dec.com, mrobidas@dnbf01.bram.cdx.mot.com, guyc@eicon.com, crichards@shiva.com, hxl@bridge2.nsd.3com.com, mpt@farallon.com, georgew@europe.shiva.com, kfarnsworth@adtran.com, paulc@diamondmm.com, arnold@fet.com, gmd@proteon.com, art@midnight.com, jhowell@pcmail.casc.com, davidc@isdnsys.com, jackm@isdnsys.com, philc@big-island.com, alain.dazzi@eng.sun.com, kervin@elmic.co.jp, raghu@trancell.com, satdcm@iway.fr, albertt@ngc.com, umesh@cosystems.com, dblair@cisco.com, wwagner@shiva.com, syadaval@usr.com, amirk@radusa.com, rodmc@netcommcorp.com, lp@acc.com, hugh_tebault@ascend.com, simpson@xylogics.com, tcnguyen@cisco.com, hien@trisignal.com, rsurprenant@jetstream.com, 75522.1603@compuserve.com, kevin_yu@ml.e-tech.com.tw, "Robert A. Lemos - NTT-IT" , Tetsuya Koshimura , rpullis@aol.com, tmina@world.std.com, peterg@eicon.com, sgieseler@smtp.microcom.com, simpson@xylogics.com, tjj@nortel.ca, fdain@vnet.ibm.com, Diane.Lee@eng.sun.com, stevek@dgii.com, jboritas@telesoft-intl.com, rglesinger@bioforge.zytrax.com, lp@acc.com, mgarti@arrisnet.com, Jonathan.Goodchild@rdl.co.uk, ron_pullis@rascom.com, cleblanc@gandalf.ca, tkikuchi@nikkeibp.co.jp, klos@klos.com, kcrocker@microsoft.com, cye@bridge2.nsd.3com.com, puz@diamondmm.com, NarenG@microsoft.com, rcs@flowpoint.com, georgew@spider.co.uk, hugh@ascend.com, clara@ascend.com, jim_philippou@rascom.com, ietf-ppp@MERIT.EDU, alfreem@PacBell.COM (Anita Freeman - Pacific Bell), kpeirce@usr.com, dan_brennan@3mail.3com.com, crichards@shiva.com, lp@acc.com, bob@larribeau.com From: bob@larribeau.com (Bob Larribeau) Subject: CIUG Fall ISDN PPP Interoperability Workshop Resent-Message-ID: <"9CvaQ1.0.wv1.EsF4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1843 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU To ISDN Networking Product Developers: The fourth California ISDN Users' Group (CIUG) ISDN PPP Interoperability Workshop will be held Monday, October 21 through Friday, October 25 at Pacific Bell's San Ramon Headquarters. This Workshop will be open to companies with ISDN products implementing PPP Multilink Protocol (PPP MP), PPP Compression Control Protocol (PPP CCP), and/or PPP Bandwidth Allocation Protocol (PPP BACP/BAP). It will provide an opportunity to test the interoperability of your products against products from the other companies attending. The only requirement for attending this Workshop is that you bring a product implementing PPP MP, PPP CCP, and/or a PPP BACP/BAP with you test. For PPP MP products should be at beta or near beta level of operation. For PPP CCP and PPP BACP engineering prototypes are appropriate. THIS IS NOT AN APPROPRIATE PLACE TO TEST BASIC ISDN NETWORK CONNECTION ISSUES. PLEASE TEST YOUR ISDN CONNECTIVITY BEFORE THE WORKSHOP. This Workshop will be open to only the participants. This is not a spectator event; it is not open to observers. Some participants will be working with unreleased products and the other attendees are expected to respect their privacy. There is a charge of $150 per person to participate in this workshop to cover the cost of food and organizing the event. This fee covers the entire week. Each person attending must pay the full amount. There will be no provision for a daily rate for those not attending the entire week. Participants will be responsible for bringing their own workstations and ISDN equipment. Pacific Bell will provide one or two BRI with either a U or an S/T interface for each participant. Please request only the number of lines that you are really going to use. We will assign any lines that are left over to companies that need more than two lines. We have PRI lines available. The PRI lines will be assigned to those companies with products that do not support BRI. Each company will be provided a six foot table, 10 amps of power, and one power strip. Bring additional power strips if you need them. We expect that we will run out of space this time. Please do not request additional tables or additional lines unless you really need them. Also coordinate your requests with all other attendees from your company to be sure you are making the most efficient use of both tables and ISDN lines. This will be a "self organizing" event. It will be your responsibility to develop your own test plan and to find your own testing partners. This has worked well in the past and we believe that it provides the most productive environment for testing. Fill out the attached form and email it to me at to register. Our last Workshop was attended by 50 companies. They found it to be invaluable in moving the interoperability of their products forward. We are expecting more attendees than the last Workshop and we expect to run out of space. Get your reservation in early to assure yourself a place. There are a number of hotels in the San Ramon area. The San Ramon Marriott is conveniently located to Pacific Bell. Pacific Bell is at 2600 Camino Ramon in San Ramon. Camino Ramon is parallel to and just east of the 680 Freeway between the Bollinger Canyon and the Crow Canyon turn offs. You can ship your equipment to: Brent Reid Pacific Bell Room 1S200OO 2600 Camino Ramon San Ramon, CA 94583 Please mark "For PPP MP Testing". Schedule your equipment to arrive on May 16 or 17. The testing rooms will be open from Noon to 8:00 PM on Sunday May 19 for set up. Plan to come in on Sunday to set your equipment up so we can start the testing promptly at 9:00 AM. There will be no testing available on Sunday. WE HAD A LOT OF PROBLEMS SHIPPING EQUIPMENT BACK TO THE PARTICIPANTS AFTER THE LAST CONFERENCE. PLEASE PAY ATTENTION TO THE FOLLOWING PARAGRAPH AND BRING THE REQUIRED PAPERS AND DOCUMENTATION. Please bring your shipping documents to return your equipment to you. These documents should include the carrier form. International shipments required to return equipment must include all appropriate documents, including carrier forms and invoices. Send me email or call me if you have any questions. Bob Larribeau bob@larribeau.com 415-241-9920 Return the following application by email immediately to reserve your place. Make sure you include the names of all attendees so Pacific Bell's security will have a complete list of attendees. Send check for $150 for each participant to: California ISDN Users' Group P.O. Box 27901-318 San Francisco, CA 94127 Or wire funds to: California ISDN Users' Group Account Number 02882 07752 Bank of America #0288 288 West Portal Avenue San Francisco, CA 94127 USA Only checks or wire transfers will be accepted. Cash or credit card payments are not available. Payment must be received in advance. All attendees must pay in full. A reduced rate is not available for those not attending all five days. ------------------------------------------------------------------------------ Primary Contact Name: Names of other Participants: How many tables will you need: We have provided large companies with multiple divisions and/or multiple product lines more than one table in the past. We will do our best to accommodate requests for multiple tables as well as to have as many different companies attend as possible. Company: Address: Phone & Fax: email address: Describe Product: PPP options to be tested: (Filling out this section accurately is important. We will use this to put together a matrix that you can use to find testing partners. We will also have two separate rooms for testing and we will use this information to group vendors in each room.) Authorization (PAP, CHAP): PPP MP (Yes or No): PPP CCP (Yes or No): Uses LAPB (Yes/No) Uses RESET/RESET ACK (Yes/No) Other (explain) Compression Used (STAC, V.42bis, ...) PPP BACP (Yes or No): The following lines will needed: How many BRI lines do you need? 1 2 More than 2: (Specify) We will do our best but we cannot guarantee more than 2. Do you want a U or an S/T interface? We have a limited number of NT1s. Please request an S/T interface only if you really need it. PRI (Yes or No): ISDN BRI and PRI service will be provided by a Nortel DMS-100 NI-1. Other comments or requirements: ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 05:40:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA23621; Wed, 14 Aug 1996 05:40:29 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 05:40:29 -0400 (EDT) From: Manas Barooah Message-Id: <199608141012.PAA11491@comm10> Subject: Frame type query ... To: ietf-ppp@MERIT.EDU Date: Wed, 14 Aug 1996 15:12:52 +0500 (GMT+0500) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"45-jk1.0.Im5.ZxP4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1844 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all, Do any other protocols use the frame type Ethernet_802.3, other than IPX. I have the assumption that the frame type Ethernet_802.3 is Novell Proprietery frame type. Am I correct in making such a guess? Bye Manas (manas@wipinfo.soft.net) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 09:50:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA28906; Wed, 14 Aug 1996 09:50:46 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 09:50:46 -0400 (EDT) MR-Received: by mta SUTRA.MUAS; Relayed; Wed, 14 Aug 1996 14:54:03 +0000 MR-Received: by mta VALMTS; Relayed; Wed, 14 Aug 1996 13:50:11 +0000 Disclose-recipients: prohibited Date: Wed, 14 Aug 1996 14:54:03 +0000 (GMT) From: "Pasi Kinnari, OSSG/PATHWORKS Remote Engineering" Subject: Q: CCP Interoperability testing sites To: ietf-ppp@MERIT.EDU Message-id: <5303541514081996/A50973/SUTRA/11A873F60200*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal UA-content-id: 11A873F60200 X400-MTS-identifier: [;5303541514081996/A50973/SUTRA] Hop-count: 1 Resent-Message-ID: <"VzMHL3.0.G37.jcT4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1845 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I'm looking for systems to do some PPP CCP (BSD and Stac) interoperability testing (IP/PPP/modem line). If you have a public number, which I could contact to test these features, mail me. //pasi Pasi Kinnari Digital Equipment Corporation, OSSG-Europe E-Mail:pasi.kinnari@vbo.mts.dec.com Software Engineer - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 10:16:26 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA29723; Wed, 14 Aug 1996 10:16:26 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 10:16:26 -0400 (EDT) Message-Id: <199608141419.KAA32281@router.thebrads.com> From: "Brad Wilson" To: "Manas Barooah" , Subject: Re: Frame type query ... Date: Wed, 14 Aug 1996 10:15:42 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01BB89C9.8CDF5920" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"jKClR.0.zF7.r-T4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1846 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is a multi-part message in MIME format. ------=_NextPart_000_01BB89C9.8CDF5920 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Do any other protocols use the frame type Ethernet_802.3, > other than IPX. I have the assumption that the frame type > Ethernet_802.3 is Novell Proprietery frame type. Am I correct in > making such a guess? Actually, no, 802.3 is not a Novell proprietary frame type. NBF over Ethernet also uses 802.3. -- Brad Wilson, Objectivist philosopher, software engineer, web designer crucial@pobox.com http://pobox.com/~crucial Objectvst@Undernet "I'm not a savior, I'm not a king, it's only the voice in your head." ------=_NextPart_000_01BB89C9.8CDF5920 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> Do any = other protocols use the frame type Ethernet_802.3,
> other = than IPX. I have the assumption that the frame type
> = Ethernet_802.3 is Novell Proprietery frame type. Am I correct = in
> making such a guess?

Actually, = no, 802.3 is not a Novell proprietary frame type.  NBF over = Ethernet also uses 802.3.

--
Brad Wilson, Objectivist = philosopher, software engineer, web designer
crucial@pobox.com =     http://pobox.com/~crucial    Objectvst@Undernet

"I'm not a savior, I'm not a king, it's = only the voice in your head."

------=_NextPart_000_01BB89C9.8CDF5920-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 10:44:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA00564; Wed, 14 Aug 1996 10:44:58 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 10:44:58 -0400 (EDT) Message-Id: <2.2.32.19960814144409.0060df0c@SanFrancisco01.pop.internex.net> X-Sender: larribeau-2@SanFrancisco01.pop.internex.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 14 Aug 1996 07:44:09 -0700 To: ietf-ppp@MERIT.EDU From: bob@larribeau.com (Bob Larribeau) Subject: CIUG ISDN PPP Interoperability Workshop (correction) Resent-Message-ID: <"lrgJc1.0.V8.cPU4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1847 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Note the correction to the shipping dates and the setup date. Bob Larribeau -------------------------------------------------------------------------------- To ISDN Networking Product Developers: The fourth California ISDN Users' Group (CIUG) ISDN PPP Interoperability Workshop will be held Monday, October 21 through Friday, October 25 at Pacific Bell's San Ramon Headquarters. This Workshop will be open to companies with ISDN products implementing PPP Multilink Protocol (PPP MP), PPP Compression Control Protocol (PPP CCP), and/or PPP Bandwidth Allocation Protocol (PPP BACP/BAP). It will provide an opportunity to test the interoperability of your products against products from the other companies attending. The only requirement for attending this Workshop is that you bring a product implementing PPP MP, PPP CCP, and/or a PPP BACP/BAP with you test. For PPP MP products should be at beta or near beta level of operation. For PPP CCP and PPP BACP engineering prototypes are appropriate. THIS IS NOT AN APPROPRIATE PLACE TO TEST BASIC ISDN NETWORK CONNECTION ISSUES. PLEASE TEST YOUR ISDN CONNECTIVITY BEFORE THE WORKSHOP. This Workshop will be open to only the participants. This is not a spectator event; it is not open to observers. Some participants will be working with unreleased products and the other attendees are expected to respect their privacy. There is a charge of $150 per person to participate in this workshop to cover the cost of food and organizing the event. This fee covers the entire week. Each person attending must pay the full amount. There will be no provision for a daily rate for those not attending the entire week. Participants will be responsible for bringing their own workstations and ISDN equipment. Pacific Bell will provide one or two BRI with either a U or an S/T interface for each participant. Please request only the number of lines that you are really going to use. We will assign any lines that are left over to companies that need more than two lines. We have PRI lines available. The PRI lines will be assigned to those companies with products that do not support BRI. Each company will be provided a six foot table, 10 amps of power, and one power strip. Bring additional power strips if you need them. We expect that we will run out of space this time. Please do not request additional tables or additional lines unless you really need them. Also coordinate your requests with all other attendees from your company to be sure you are making the most efficient use of both tables and ISDN lines. This will be a "self organizing" event. It will be your responsibility to develop your own test plan and to find your own testing partners. This has worked well in the past and we believe that it provides the most productive environment for testing. Fill out the attached form and email it to me at to register. Our last Workshop was attended by 50 companies. They found it to be invaluable in moving the interoperability of their products forward. We are expecting more attendees than the last Workshop and we expect to run out of space. Get your reservation in early to assure yourself a place. There are a number of hotels in the San Ramon area. The San Ramon Marriott is conveniently located to Pacific Bell. Pacific Bell is at 2600 Camino Ramon in San Ramon. Camino Ramon is parallel to and just east of the 680 Freeway between the Bollinger Canyon and the Crow Canyon turn offs. You can ship your equipment to: Brent Reid Pacific Bell Room 1S200OO 2600 Camino Ramon San Ramon, CA 94583 Please mark "For PPP MP Testing". Schedule your equipment to arrive on October 17 or 18. The testing rooms will be open from Noon to 8:00 PM on Sunday October 20 for set up. Plan to come in on Sunday to set your equipment up so we can start the testing promptly at 9:00 AM. There will be no testing available on Sunday. WE HAD A LOT OF PROBLEMS SHIPPING EQUIPMENT BACK TO THE PARTICIPANTS AFTER THE LAST CONFERENCE. PLEASE PAY ATTENTION TO THE FOLLOWING PARAGRAPH AND BRING THE REQUIRED PAPERS AND DOCUMENTATION. Please bring your shipping documents to return your equipment to you. These documents should include the carrier form. International shipments required to return equipment must include all appropriate documents, including carrier forms and invoices. Send me email or call me if you have any questions. Bob Larribeau bob@larribeau.com 415-241-9920 Return the following application by email immediately to reserve your place. Make sure you include the names of all attendees so Pacific Bell's security will have a complete list of attendees. Send check for $150 for each participant to: California ISDN Users' Group P.O. Box 27901-318 San Francisco, CA 94127 Or wire funds to: California ISDN Users' Group Account Number 02882 07752 Bank of America #0288 288 West Portal Avenue San Francisco, CA 94127 USA Only checks or wire transfers will be accepted. Cash or credit card payments are not available. Payment must be received in advance. All attendees must pay in full. A reduced rate is not available for those not attending all five days. ------------------------------------------------------------------------------ Primary Contact Name: Names of other Participants: How many tables will you need: We have provided large companies with multiple divisions and/or multiple product lines more than one table in the past. We will do our best to accommodate requests for multiple tables as well as to have as many different companies attend as possible. Company: Address: Phone & Fax: email address: Describe Product: PPP options to be tested: (Filling out this section accurately is important. We will use this to put together a matrix that you can use to find testing partners. We will also have two separate rooms for testing and we will use this information to group vendors in each room.) Authorization (PAP, CHAP): PPP MP (Yes or No): PPP CCP (Yes or No): Uses LAPB (Yes/No) Uses RESET/RESET ACK (Yes/No) Other (explain) Compression Used (STAC, V.42bis, ...) PPP BACP (Yes or No): The following lines will needed: How many BRI lines do you need? 1 2 More than 2: (Specify) We will do our best but we cannot guarantee more than 2. Do you want a U or an S/T interface? We have a limited number of NT1s. Please request an S/T interface only if you really need it. PRI (Yes or No): ISDN BRI and PRI service will be provided by a Nortel DMS-100 NI-1. Other comments or requirements: -------------------------------------------------------------------------------- ----------------------------------------------------------- Bob Larribeau bob@larribeau.com ISDN Consultant San Francisco - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 10:55:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA01061; Wed, 14 Aug 1996 10:55:58 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 10:55:58 -0400 (EDT) Date: Wed, 14 Aug 1996 10:54:17 -0400 (EDT) From: John Shriver Message-Id: <199608141454.KAA19505@shiva-dev.shiva.com> To: crucial@pobox.com CC: manas@wipinfo.soft.net, ietf-ppp@MERIT.EDU In-reply-to: <199608141419.KAA32281@router.thebrads.com> (crucial@pobox.com) Subject: Re: Frame type query ... Resent-Message-ID: <"wiemV2.0.2G.rZU4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1848 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: "Brad Wilson" To: "Manas Barooah" , Subject: Re: Frame type query ... Date: Wed, 14 Aug 1996 10:15:42 -0400 This is a multi-part message in MIME format. ------=_NextPart_000_01BB89C9.8CDF5920 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > Do any other protocols use the frame type Ethernet_802.3, > other than IPX. I have the assumption that the frame type > Ethernet_802.3 is Novell Proprietery frame type. Am I correct in > making such a guess? Actually, no, 802.3 is not a Novell proprietary frame type. NBF over Ethernet also uses 802.3. Umm, nothing else but botched-up Novell uses 802.3 WITHOUT 802.2. By forgetting to include the 802.2 layer, they totally botched it. You have to look for 802.2 source SAP and destination SAP of 0xFF, and then you assume it's the Novell abomination. NBF uses 802.2, on SAP E0 or F0 (I'm rusty). Moreover, it uses 802.2 Class 2 (connection-oriented). ISO/OSI and SNA also run on 802.2. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 11:31:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA02299; Wed, 14 Aug 1996 11:31:59 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 11:31:59 -0400 (EDT) Date: Wed, 14 Aug 1996 09:31:42 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608141531.JAA09189@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Q: CCP Interoperability testing sites Resent-Message-ID: <"Jm_4r1.0.YZ.g5V4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1849 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Pasi Kinnari, OSSG/PATHWORKS Remote Engineering" > > I'm looking for systems to do some PPP CCP (BSD and Stac) > interoperability testing (IP/PPP/modem line). > > If you have a public number, which I could contact to test > these features, mail me. Boxes running with the freeware ppp-2.2 have BSD Compress. See pub/software/ppp/ppp-2.2.tar.gz on cs.anu.edu.au. It runs on many UNIX varients (including some made by Digital), and I think it's standard in current versions of Linux. If you pay the long distance charges, you could dial one of the modems in Colorado I use for daily work. (Note that I'm offering to help shake down a new implementation, and by "implementation" I do not mean "installation." I'm sorry but I cannot offer technical support to the bagazillions of PPP users.) A cheap way to test such stuff is over the Internet, with PPP over telnet or rlogin. Paul Mackerras and I found that handy, since his machines are in Austrailia and mine in various parts of the U.S. I could set up something like that again for a little while. 415-903-0824 and 415-903-9508 are ISDN numbers in California that answer BSD Compress. See http://www.sgi.com/Technology/Indy_ISDN_interop_howto.html Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 13:36:01 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA04789; Wed, 14 Aug 1996 13:36:01 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 13:36:01 -0400 (EDT) Message-Id: <9608141735.AA67994@bryce.watson.ibm.com> X-Mailer: exmh version 1.6.5 12/11/95 To: ietf-ppp@MERIT.EDU Subject: Flow control and tunneling protocols. Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 96 13:35:45 -0400 From: Baiju Patel Resent-Message-ID: <"hBPNY2.0.WA1.vvW4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1850 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am little-bit confused about flow control and the problem it is trying to solve as proposed in L2TP draft. Unlike TCP, the flow control does not try to react to congestion in the IP network. Its primary purpose is to deal with buffer overflow in the NAS or home Gateway (correct me if I am wrong). Since the flow control mechanism is only across an intermediate link, and not end-to-end, it is effectiveness is questionable. Consider two cases: 1. The buffers at the home gateway are getting full. In that case, the home gateway will send a message to the NAS's asking them to slow down. However, NAS's have no way to telling the remote devices to slow down. As a result, the NAS's buffers will start growing and in no time, they will overflow. So, if the flow control is not there, packets will be dropped at Home gateway. Instead, if the flow control is there, the packets are dropped at NAS. The problem is even more complicated when one NAS is forwarding packets to to gateways (GW1 and GW2). If GW1 has congestion, it will ask NAS to slow down resulting in buffer overflows at NAS. In that case, the packets destined to both GW1 and GW2 will be dropped (buffers are full) even though GW2 does not have congestion. So, one congested home gateway will not only affect traffic destined to that gateway but all other gateways. 2. When the buffers at the NAS are getting full, the NAS will send a back-pressure to all the home gateways that are tunneling traffic to it. Since the home gateways cannot send a back-pressure to the corresponding hosts in the LAN, the buffers will start filling up very fast at the home gateway. And the packets will be dropped there. In my opinion, the flow control only at an intermediate link is of marginal value (if any at all). On other hand, if packets are dropped for a connection, the transport protocol (e.g., TCP) will try to slow down and truly reduce the congestion at NAS, Gateway or network. I think that flow control is additional complexity that does not solve any problem and thus should not be part of the tunneling protocol spec. Baiju =============================================================================== Baiju V. Patel (external): http://www.research.ibm.com/people/b/baiju (internal): http://w3.watson.ibm.com/~baiju/baiju.html IBM T. J. Watson Research Center, H3-D36 30 Saw Mill River Road, Hawthorne, NY 10532 =============================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 14:12:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA05852; Wed, 14 Aug 1996 14:12:29 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 14:12:29 -0400 (EDT) Date: Wed, 14 Aug 1996 20:11:26 +0200 From: kurt@ecrc.de (Kurt Kayser) Message-Id: <9608141811.AA01439@sunkist.ecrc.de> To: ietf-ppp@MERIT.EDU Subject: Problem with mailserver... X-Sun-Charset: US-ASCII Resent-Message-ID: <"eg0oM2.0.4R1.7SX4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1851 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi! Could some kind soul take my unsubscription request to the right address, please? The ietf-ppp-request robot seems to reject any mail I sent to it. THanks, Kurt -- Kurt Kayser => Tel. +49 89 926 99148 ECRC European Computer Research Centre => Fax. +49 89 926 99170 Arabellastr. 17, 81925 Munich, Germany => E-Mail: kurt@ecrc.de - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 14 20:57:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA12503; Wed, 14 Aug 1996 20:57:43 -0400 (EDT) Resent-Date: Wed, 14 Aug 1996 20:57:43 -0400 (EDT) Date: Wed, 14 Aug 1996 17:04:08 -0700 (PDT) From: Andy Valencia Message-Id: <199608150004.RAA09070@vandys-lap.cisco.com> To: baiju@watson.ibm.com Cc: ietf-ppp@MERIT.EDU Subject: Re: Flow control and tunneling protocols. Newsgroups: cisco.external.ietf.ppp References: <9608141735.AA67994@bryce.watson.ibm.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"JhEOY1.0.t23.QNd4o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1852 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: >I am little-bit confused about flow control and the problem it is trying >to solve as proposed in L2TP draft. >... We're just firing up to cover this, but I believe it should be done in the L2TP list, not here where we'll drive the poor PPP world crazy! If anybody on this list missed the initial announcement, the L2TP work of merging PPTP and L2F is well underway, and you can join the discussion of this activity by sending a note to l2tp-request@newbridge.com. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 15 15:28:42 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA25357; Thu, 15 Aug 1996 15:28:42 -0400 (EDT) Resent-Date: Thu, 15 Aug 1996 15:28:42 -0400 (EDT) Date: Thu, 15 Aug 96 15:32:08 EST From: "Whelan, Bill" Message-Id: <9607158401.AA840148405@netx.nei.com> Cc: ietf-ppp@MERIT.EDU Subject: EAP & EAPRSA Resent-Message-ID: <"fn2Ww1.0.WB6.net4o"@merit.edu> To: ietf-ppp@MERIT.EDU Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1853 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What is the status of EAP? Is it supposed to be advanced? What about EAP RSA Public Key Authentication? ______________________________ Reply Separator _________________________________ Subject: I-D ACTION:draft-ietf-pppext-eap-auth-02.txt Author: Internet-Drafts@ietf.org at Internet-mail Date: 7/25/96 10:33 AM --NextPart A Revised 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 : PPP Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht Filename : draft-ietf-pppext-eap-auth-02.txt Pages : 18 Date : 07/23/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. Internet-Drafts are 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-eap-auth-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-eap-auth-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-auth-02.txt". NOTE: The mail server at ds.internic.net 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. For questions, please mail to Internet-Drafts@ietf.org 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@ds.internic.net" Content-Type: text/plain Content-ID: <19960724162722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-auth-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-auth-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960724162722.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 12:53:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA10550; Fri, 16 Aug 1996 12:53:02 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 12:53:02 -0400 (EDT) Message-ID: <01BB8B9B.A73B6560@localhost> From: Ian Puleston To: "'IETF PPP Mailing List'" Subject: RSA for DES Encryption Key Exchange Date: Fri, 16 Aug 1996 17:52:59 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"xnBQt.0.Pa2.HTA5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1854 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There are now RFCs for PPP Encryption Control and PPP DES Encryption = (1968/1969) and there is a draft for using RSA Public Key for = authentication (PPP EAP RSA Public Key Authentication protocol). RFC1969 states that "The means by which the secret becomes known to both = communicating elements is beyond the scope of this document; usually = some form of manual configuration is involved". We do a product with DES encryption, and we find that most (maybe all) = of our customers do not want to manually configure encryption keys, = particularly in a widely distributed network, but would rather have = random keys generated automatically. The RSA Public Key mechanism can = then be used to safely send the DES key to the remote end (who has = already been authenticated by a mechanism such as CHAP). Our product = does this using proprietary messages to do the DES key transfer. We would like to do DES encryption over PPP links using RFC 1968/1969, = but require a standard method for the key transfer. Does anyone know if = any work is being done on standards for using RSA Public Key (or some = other method) for transfer of DES keys ? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 13:06:23 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA10955; Fri, 16 Aug 1996 13:06:23 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 13:06:23 -0400 (EDT) Date: Fri, 16 Aug 96 12:00:29 CDT Message-Id: <9608161700.AA16990@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Whelan, Bill" From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: Re: EAP & EAPRSA Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"pDJkt1.0.sg2.BgA5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1855 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > What is the status of EAP? Is it supposed to be advanced? What about > EAP RSA Public Key Authentication? > > I have asked a question about EAP-02 but I get no response from anyone on the list or from the authors. Why was this draft developed? Does anyone plan on implementing it? Are the authors still participating? -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 13:19:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA11228; Fri, 16 Aug 1996 13:19:35 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 13:19:35 -0400 (EDT) Message-Id: <2.2.32.19960816171728.0069050c@tiac.net> X-Sender: ksiegel@tiac.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Aug 1996 13:17:28 -0400 To: Ian Puleston , "'IETF PPP Mailing List'" From: Ken Siegel Subject: Re: RSA for DES Encryption Key Exchange Resent-Message-ID: <"gpbxa2.0.7l2.ZsA5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1856 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ian, >We would like to do DES encryption over PPP links using RFC 1968/1969, but require a standard method for the key transfer. Does anyone know if any work is being done on standards for using RSA Public Key (or some other method) for transfer of DES keys ? > You might want to check out the ipsec mailing list and associated archives. There are draft RFC's for ISAKMP/Oakley and SKIP key exchange protocols. These may be a good start toward what you are looking for. Ken Ken Siegel Switchblade Networks, Inc. 6 Lisa Drive Nashua, NH 03062 Phone: (603) 888-6818 Internet: ksiegel@switchblade.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 14:05:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA11980; Fri, 16 Aug 1996 14:05:51 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 14:05:51 -0400 (EDT) Message-ID: From: Glen Zorn To: "'IETF PPP Mailing List'" , "'Ian Puleston'" Subject: RE: RSA for DES Encryption Key Exchange Date: Fri, 16 Aug 1996 11:02:40 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 22 TEXT Resent-Message-ID: <"yVYKZ1.0.qw2.rXB5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1857 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Ian Puleston writes: >There are now RFCs for PPP Encryption Control and PPP DES Encryption >(1968/1969) and there is a draft for using RSA Public Key for authentication >(PPP EAP RSA Public Key Authentication protocol). > >RFC1969 states that "The means by which the secret becomes known to both >communicating elements is beyond the scope of this document; usually some >form of manual configuration is involved". > >We do a product with DES encryption, and we find that most (maybe all) of our >customers do not want to manually configure encryption keys, particularly in >a widely distributed network, but would rather have random keys generated >automatically. The RSA Public Key mechanism can then be used to safely send >the DES key to the remote end (who has already been authenticated by a >mechanism such as CHAP). How does this mechanism avoid the manual configuration of keys? CHAP requires a key (password): if there is a human at the remote end, all is well; if not, what? Similarly, how does the remote end obtain the public key matching the private key under which the DES key is encrypted, if not by manual configuration? It cannot be obtained from the Directory, since no NCP is up yet. Am I missing something? ... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 14:44:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA13001; Fri, 16 Aug 1996 14:44:12 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 14:44:12 -0400 (EDT) Date: Fri, 16 Aug 1996 14:43:34 -0400 (EDT) From: Ian Duncan X-Sender: iduncan@magnus2 Reply-To: Ian Duncan To: Glen Zorn cc: "'IETF PPP Mailing List'" , "'Ian Puleston'" Subject: RE: RSA for DES Encryption Key Exchange In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"U4P-m3.0.mA3.u5C5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1858 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Fri, 16 Aug 1996, Glen Zorn wrote: > >Ian Puleston writes: > > > >We do a product with DES encryption, and we find that most (maybe all) of our > >customers do not want to manually configure encryption keys, particularly in > >a widely distributed network, but would rather have random keys generated > >automatically. The RSA Public Key mechanism can then be used to safely send > >the DES key to the remote end (who has already been authenticated by a > >mechanism such as CHAP). > > How does this mechanism avoid the manual configuration of keys? CHAP > requires a key (password): if there is a human at the remote end, all is > well; if not, what? Similarly, how does the remote end obtain the > public key matching the private key under which the DES key is > encrypted, if not by manual configuration? It cannot be obtained from > the Directory, since no NCP is up yet. Am I missing something? > ... What I think you missed is that the PPP authentication protocol was EAP/RSA. This implies some sort of public key management. If you assume that RADIUS is used to forward the EAP/RSA credentials to an authentication server then thay server could return the right public key in the RADIUS response once it's determined to be correct. The PPP device could then use that public key to safely pass across the link randomly generated DES session key(s). -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 15:07:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA13479; Fri, 16 Aug 1996 15:07:13 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 15:07:13 -0400 (EDT) Message-ID: From: Glen Zorn To: "'Ian Duncan'" Cc: "'IETF PPP Mailing List'" , "'Ian Puleston'" Subject: RE: RSA for DES Encryption Key Exchange Date: Fri, 16 Aug 1996 12:06:30 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 46 TEXT Resent-Message-ID: <"waIal1.0.II3.ORC5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1859 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ian Duncan writes: >On Fri, 16 Aug 1996, Glen Zorn wrote: > >> >Ian Puleston writes: >> > >> >We do a product with DES encryption, and we find that most (maybe all) of >>our >> >customers do not want to manually configure encryption keys, particularly >>in >> >a widely distributed network, but would rather have random keys generated >> >automatically. The RSA Public Key mechanism can then be used to safely >>send >> >the DES key to the remote end (who has already been authenticated by a >> >mechanism such as CHAP). >> >> How does this mechanism avoid the manual configuration of keys? CHAP >> requires a key (password): if there is a human at the remote end, all is >> well; if not, what? Similarly, how does the remote end obtain the >> public key matching the private key under which the DES key is >> encrypted, if not by manual configuration? It cannot be obtained from >> the Directory, since no NCP is up yet. Am I missing something? >> ... > >What I think you missed is that the PPP authentication protocol was >EAP/RSA. So after CHAP, EAP/RSA? >This implies some sort of public key management. Yes. >If you assume >that RADIUS is used to forward the EAP/RSA credentials to an >authentication server then thay server could return the right public key >in the RADIUS response once it's determined to be correct. The PPP device >could then use that public key to safely pass across the link randomly >generated DES session key(s). So the assumption is that both peers have public key creds? That makes sense, though it stiil requires the non-human case, since a router (for example) would need to be configured with its own public and private keys. So how did CHAP get involved in this? > >-- > Ian Duncan > Access Products Development > Newbridge Networks Corp. > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 16:02:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA14682; Fri, 16 Aug 1996 16:02:31 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 16:02:31 -0400 (EDT) Date: Fri, 16 Aug 1996 16:00:38 -0400 (EDT) From: Ian Duncan X-Sender: iduncan@magnus2 Reply-To: Ian Duncan To: Glen Zorn cc: "'IETF PPP Mailing List'" , "'Ian Puleston'" Subject: RE: RSA for DES Encryption Key Exchange In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Gv8oR.0.5b3.JFD5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1860 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Fri, 16 Aug 1996, Glen Zorn wrote: > So the assumption is that both peers have public key creds? That makes > sense, though it stiil requires the non-human case, since a router (for > example) would need to be configured with its own public and private > keys. Both peers having public key credentials isn't necessary. Once there's a trusted public-private pair in place the randomly generated session keys can be passed securely in either. The question of trust is mostly a policy issue and for most uses a one-way authentication would be satisfactory. If it isn't something a bit more complex would be required. > So how did CHAP get involved in this? I haven't a clue. Although it was mentioned in Ian Puleston's original message I didn't understand it. -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 17:38:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA16181; Fri, 16 Aug 1996 17:38:35 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 17:38:35 -0400 (EDT) Date: Fri, 16 Aug 96 17:42:41 EST From: "Whelan, Bill" Message-Id: <9607168402.AA840242665@netx.nei.com> To: kfarnsworth@adtran.com (Kyle Farnsworth) Cc: ietf-ppp@MERIT.EDU Subject: Re[2]: EAP & EAPRSA Resent-Message-ID: <"xZmGM2.0.Ty3.IfE5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1861 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The history of EAP preceeded my involvement with the IETF, but old minutes indicate discussions about it as far back as early '94. Network Express had a need which EAP seemed to meet. Neither PAP nor CHAP were adequate. We implemented EAP with RSA Public Key Authentication. We also worked with the Merit folks to develop an interoperable EAP MD5 implementation. At the Montreal meeting there were a dozen or so hands raised when asked who would be implementing EAP. ______________________________ Reply Separator _________________________________ Subject: Re: EAP & EAPRSA Author: kfarnsworth@adtran.com (Kyle Farnsworth) at Internet-mail Date: 8/16/96 12:00 PM > What is the status of EAP? Is it supposed to be advanced? What about > EAP RSA Public Key Authentication? > > I have asked a question about EAP-02 but I get no response from anyone on the list or from the authors. Why was this draft developed? Does anyone plan on implementing it? Are the authors still participating? -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 17:42:32 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA16377; Fri, 16 Aug 1996 17:42:32 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 17:42:32 -0400 (EDT) Message-ID: From: Glen Zorn To: "'Ian Duncan'" Cc: "'IETF PPP Mailing List'" , "'Ian Puleston'" Subject: RE: RSA for DES Encryption Key Exchange Date: Fri, 16 Aug 1996 14:41:18 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 70 TEXT Resent-Message-ID: <"lccby2.0.W_3.3jE5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1862 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ian Duncan writes: >On Fri, 16 Aug 1996, Glen Zorn wrote: > >> So the assumption is that both peers have public key creds? That makes >> sense, though it stiil requires the non-human case, since a router (for >> example) would need to be configured with its own public and private >> keys. > >Both peers having public key credentials isn't necessary. Once there's a >trusted public-private pair in place the randomly generated session keys >can be passed securely in either. The question of trust is mostly a policy >issue and for most uses a one-way authentication would be satisfactory. If >it isn't something a bit more complex would be required. >> So how did CHAP get involved in this? > >I haven't a clue. Although it was mentioned in Ian Puleston's original >message I didn't understand it. I think I understand what you're proposing now (I was thrown by your mention of RADIUS, since it a] doesn't support EAP and b] is probably superfluous in this case, since the EAP response contains the certificate of the authenticating peer), so let me do a reality check (I'm calling the authenticating peer the "user" and the authenticator the "NAS"): user NAS <--------------------------> negotiate EAP <-------------------------- EAP request ---------------------------> (save user cert) EAP response ... ---------------------------> send random DES key encrypted under user's private key Is that about right? If so, the only problem I see is in the last step. I'm unaware of any PPP-esque protocol that does key transfer/negotiation (PPP ECP doesn't help). Something like this would work as well, w/o requiring users to possess PK certs (but it has the same problem): user NAS <---------------------------> CHAP exchange <--------------------------> negotiate EAP ----------------------------> EAP request (save NAS cert) <--------------------------- EAP response ... <--------------------------- send random DES key encrypted under NAS's private key I wonder if this is what Ian Puleston was thinking about? -- gwz > >-- > Ian Duncan > Access Products Development > Newbridge Networks Corp. > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 16 18:01:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA17035; Fri, 16 Aug 1996 18:01:45 -0400 (EDT) Resent-Date: Fri, 16 Aug 1996 18:01:45 -0400 (EDT) Date: Fri, 16 Aug 96 18:06:03 EST From: "Whelan, Bill" Message-Id: <9607168402.AA840244067@netx.nei.com> To: ietf-ppp@MERIT.EDU Subject: Re: RSA for DES Encryption Key Exchange Resent-Message-ID: <"4wpIC.0.s94.5_E5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1863 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Network Express has a PPP encryption product. It is based on one of the early ECP drafts (I haven't read the RFC but I wouldn't expect it has changed much) as well as the EAP RSA Public Key Authentication. After Authentication each side knows the other's public key. We then used RSA to encrypt symetric algorithm keys for exchange during ECP negotiation. I've published the EAP RSA Public Key Authentication and hope to move it to standards track, but I've not yet done so for the ECP negotiation. I could do so if there is interest. ______________________________ Reply Separator _________________________________ Subject: RSA for DES Encryption Key Exchange Author: ietf-ppp@MERIT.EDU at Internet-mail Date: 8/16/96 1:07 PM There are now RFCs for PPP Encryption Control and PPP DES Encryption = (1968/1969) and there is a draft for using RSA Public Key for = authentication (PPP EAP RSA Public Key Authentication protocol). RFC1969 states that "The means by which the secret becomes known to both = communicating elements is beyond the scope of this document; usually = some form of manual configuration is involved". We do a product with DES encryption, and we find that most (maybe all) = of our customers do not want to manually configure encryption keys, = particularly in a widely distributed network, but would rather have = random keys generated automatically. The RSA Public Key mechanism can = then be used to safely send the DES key to the remote end (who has = already been authenticated by a mechanism such as CHAP). Our product = does this using proprietary messages to do the DES key transfer. We would like to do DES encryption over PPP links using RFC 1968/1969, = but require a standard method for the key transfer. Does anyone know if = any work is being done on standards for using RSA Public Key (or some = other method) for transfer of DES keys ? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Aug 17 02:00:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id CAA22178; Sat, 17 Aug 1996 02:00:52 -0400 (EDT) Resent-Date: Sat, 17 Aug 1996 02:00:52 -0400 (EDT) Message-ID: From: Glen Zorn To: "'ietf-ppp@MERIT.EDU'" , "'Whelan, Bill'" Subject: RE: RSA for DES Encryption Key Exchange Date: Fri, 16 Aug 1996 22:39:04 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 55 TEXT Resent-Message-ID: <"kzGLw3.0.6Q5.C0M5o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1864 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Bill Whelan writes: > Network Express has a PPP encryption product. It is based on one of > the early ECP drafts (I haven't read the RFC but I wouldn't expect it > has changed much) as well as the EAP RSA Public Key Authentication. > > After Authentication each side knows the other's public key. How is that? It looks like only the peer's cert is passed back in the EAP RSA response. Is it assumed that the peer already posesses the authenticator's cert? >We then > used RSA to encrypt symetric algorithm keys for exchange during ECP > negotiation. > > I've published the EAP RSA Public Key Authentication and hope to move > it to standards track, but I've not yet done so for the ECP > negotiation. I could do so if there is interest. I'm interested. > > >______________________________ Reply Separator >_________________________________ >Subject: RSA for DES Encryption Key Exchange >Author: ietf-ppp@MERIT.EDU at Internet-mail >Date: 8/16/96 1:07 PM > > >There are now RFCs for PPP Encryption Control and PPP DES Encryption = >(1968/1969) and there is a draft for using RSA Public Key for = >authentication (PPP EAP RSA Public Key Authentication protocol). > >RFC1969 states that "The means by which the secret becomes known to both = >communicating elements is beyond the scope of this document; usually = >some form of manual configuration is involved". > >We do a product with DES encryption, and we find that most (maybe all) = >of our customers do not want to manually configure encryption keys, = >particularly in a widely distributed network, but would rather have = >random keys generated automatically. The RSA Public Key mechanism can = >then be used to safely send the DES key to the remote end (who has = >already been authenticated by a mechanism such as CHAP). Our product = >does this using proprietary messages to do the DES key transfer. > >We would like to do DES encryption over PPP links using RFC 1968/1969, = >but require a standard method for the key transfer. Does anyone know if = >any work is being done on standards for using RSA Public Key (or some = >other method) for transfer of DES keys ? > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 19 06:04:25 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id GAA19132; Mon, 19 Aug 1996 06:04:25 -0400 (EDT) Resent-Date: Mon, 19 Aug 1996 06:04:25 -0400 (EDT) MR-Received: by mta MARVIN.MUAS; Relayed; Mon, 19 Aug 1996 11:02:24 +0000 MR-Received: by mta JOLLY; Relayed; Mon, 19 Aug 1996 10:03:21 +0000 MR-Received: by mta RDGMTS; Relayed; Mon, 19 Aug 1996 10:03:23 +0000 MR-Received: by mta VALMTS; Relayed; Mon, 19 Aug 1996 10:03:25 +0000 Disclose-recipients: prohibited Date: Mon, 19 Aug 1996 11:02:24 +0000 (GMT) From: "Stephen Waters (MARVIN::WATERS) +44 (0) 1548 831170" Subject: Call Back discussion To: ietf-ppp@MERIT.EDU, Dave Nelson , Tom Gulick , gary lewis , Chris Chapman Message-id: <1624031119081996/A30903/LEGB4/11A89AC31500*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal Sensitivity: Company-Confidential UA-content-id: 11A89AC31500 X400-MTS-identifier: [;1624031119081996/A30903/LEGB4] Hop-count: 3 Resent-Message-ID: <"QTNNR2.0.cg4.xl36o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1865 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have been looking at the various CallBack proposals in the current drafts (CBCP/LCP/BAP) The CallBack Control Protocol (CBCP draft) is the best defined at the moment, but there seems to be some talk of working on the LCP extension for call back. I would like to get a feel for which rfc folk have implemented so that I can add the one that will be the most useful at future ISDN/PPP bake-offs. On the topic of Multilink PPP, the current BAP callback is fine for additional channels, but not the initial channel. I think that CBCP should be used (with a few additions) for PPP and the base MPPP link. I'd like to hear from anyone who has implemented CBCP or LCP CallBack plus any views on the way forward before I make any comments on a particular rfc. Thanks, Steve. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 19 09:25:11 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA22125; Mon, 19 Aug 1996 09:25:11 -0400 (EDT) Resent-Date: Mon, 19 Aug 1996 09:25:11 -0400 (EDT) Date: Mon, 19 Aug 96 09:30:46 EST From: "Whelan, Bill" Message-Id: <9607198404.AA840472405@netx.nei.com> To: ietf-ppp@MERIT.EDU, Glen Zorn Subject: Re[2]: RSA for DES Encryption Key Exchange Resent-Message-ID: <"vxh_M.0.OP5.oi66o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1866 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Good point Glen, in our product we've done mutual authentication. So do other products I've seen which interoperate with us. However, that is not enforced. ECP negotiations were then independent of authentication, the only requirement being that the peer's public key is already known. If this information is known through some means other than EAP RSA Public Key Authentication, that should be fine. Bill ______________________________ Reply Separator _________________________________ Subject: RE: RSA for DES Encryption Key Exchange Author: Glen Zorn at Internet-mail Date: 8/17/96 2:08 AM Bill Whelan writes: > Network Express has a PPP encryption product. It is based on one of > the early ECP drafts (I haven't read the RFC but I wouldn't expect it > has changed much) as well as the EAP RSA Public Key Authentication. > > After Authentication each side knows the other's public key. How is that? It looks like only the peer's cert is passed back in the EAP RSA response. Is it assumed that the peer already posesses the authenticator's cert? >We then > used RSA to encrypt symetric algorithm keys for exchange during ECP > negotiation. > > I've published the EAP RSA Public Key Authentication and hope to move > it to standards track, but I've not yet done so for the ECP > negotiation. I could do so if there is interest. I'm interested. > > >______________________________ Reply Separator >_________________________________ >Subject: RSA for DES Encryption Key Exchange >Author: ietf-ppp@MERIT.EDU at Internet-mail >Date: 8/16/96 1:07 PM > > >There are now RFCs for PPP Encryption Control and PPP DES Encryption = >(1968/1969) and there is a draft for using RSA Public Key for = >authentication (PPP EAP RSA Public Key Authentication protocol). > >RFC1969 states that "The means by which the secret becomes known to both = >communicating elements is beyond the scope of this document; usually = >some form of manual configuration is involved". > >We do a product with DES encryption, and we find that most (maybe all) = >of our customers do not want to manually configure encryption keys, = >particularly in a widely distributed network, but would rather have = >random keys generated automatically. The RSA Public Key mechanism can = >then be used to safely send the DES key to the remote end (who has = >already been authenticated by a mechanism such as CHAP). Our product = >does this using proprietary messages to do the DES key transfer. > >We would like to do DES encryption over PPP links using RFC 1968/1969, = >but require a standard method for the key transfer. Does anyone know if = >any work is being done on standards for using RSA Public Key (or some = >other method) for transfer of DES keys ? > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 19 10:50:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA24519; Mon, 19 Aug 1996 10:50:51 -0400 (EDT) Resent-Date: Mon, 19 Aug 1996 10:50:51 -0400 (EDT) Message-Id: <199608191450.QAA01576@vbormc.vbo.dec.com> Date: Mon, 19 Aug 96 16:51:34 MET DST From: Stephen Waters +44 (0)1548 831170 To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Cc: waters@marvin.enet.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: PPP Callback Control Protocol (CBCP) comments Resent-Message-ID: <"Mvxhx2.0.o-5.6z76o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1867 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Comments on PPP Callback Control Protocol 1. I think the terms 'caller','callee' and 'answerer' are ambiguous. How about : Requester - peer that requested a callback service Acceptor - peer that receives the callback request. In any case, the definitions in section 1.2 are open to confusion since a typical callback will involve two calls in which the roles of 'caller','callee' and 'answerer' are reversed. 2. It seems odd for the Acceptor (or answerer in current draft) to be sending a message named 'Callback Request' since it was the Requester that asked for the callback, not the Acceptor. The 'Callback Request' message is more like a 'Callback Options' message. 3. The diagram in section 3.0 does not list the 4 options for callback that are listed later in 3.2 4. My particular interest with ISDN is reducing costs. The current draft requires a two-call handshake to establish the callback. In regions that impose an minimum call charge (e.g. in the UK, a national call will cost 4.2pence event for a call that lasts only one second), if the ISDN connection is frequently allowed to go idle (disconnected when a certain period of inactivity is detected), using a two-call callback can DOUBLE your remote access bill! To achieve a one-call callback, I am suggesting a new Callback types in the configuration options : 'Callback to Calling Line Identifier (CLI) address'. This will be negotiated on 'first contact' and then calls matching the CLI will be cleared and a callback call delivered, e.g. Requester Acceptor INITIAL CALL -------call (with CLI)--> <--------accept---------- ----------LCP callback--> <--LCP callback ack------ <------ Callback options- (including CLI option) -Callback resp(use CLI)-> <------ Callback ack----- <----call cleared ------- callback delay <----- callback call----- Requester Acceptor SUBSEQUENT CALLS ------call (with CLI)--> <-------- clear--------- callback delay <----- callback call---- 5. Negotiation of Requester/Acceptor The text does not consider that negotiation may be needed resolve which end will be the Requester and which the Acceptor. There are a number of possible problems if both peers think they are the Requester or both think they are acceptors. 6. Callback delay default. Having a default value of zero for this timer is not very switch friendly. How about 1? 7. The definition of Callback Address is too restrictive. The LCP Callback extension allows for 'undistinguished octets' or free-format octets. This could be added by supporting another callback option type and another callback address format. 8. Timers. there is no discussion about timer relating to the callback negotiation messages. Steve. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 19 13:47:37 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA29103; Mon, 19 Aug 1996 13:47:37 -0400 (EDT) Resent-Date: Mon, 19 Aug 1996 13:47:37 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'\"ietf-ppp@merit.edu\"@vbormc.vbo.dec.com'" <"ietf-ppp@merit.edu"@vbormc.vbo.dec.com>, "'ietf-ppp@MERIT.EDU'" , "'Stephen Waters +44 1548 831170'" Subject: RE: PPP Callback Control Protocol (CBCP) comments Date: Mon, 19 Aug 1996 10:46:50 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 116 TEXT Resent-Message-ID: <"68sCR2.0.J67.mYA6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1868 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This draft expired 2 years ago and is not on standards track. Callback will be supported thru the LCP callback option which may be enhanced to support more features. >---------- >From: Stephen Waters +44 1548 831170[SMTP:waters@marvin.enet.dec.com] >Sent: Monday, August 19, 1996 9:51 AM >To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com; ietf-ppp@MERIT.EDU >Cc: waters@marvin.enet.dec.com >Subject: PPP Callback Control Protocol (CBCP) comments > > > Comments on PPP Callback Control Protocol > > > > 1. I think the terms 'caller','callee' and 'answerer' are > ambiguous. How about : > > Requester - peer that requested a callback service > Acceptor - peer that receives the callback request. > > In any case, the definitions in section 1.2 are open to > confusion since a typical callback will involve two calls > in which the roles of 'caller','callee' and 'answerer' are > reversed. > > 2. It seems odd for the Acceptor (or answerer in current > draft) to be sending a message named 'Callback Request' > since it was the Requester that asked for the callback, not > the Acceptor. The 'Callback Request' message is more like > a 'Callback Options' message. > > 3. The diagram in section 3.0 does not list the 4 options for > callback that are listed later in 3.2 > > > 4. My particular interest with ISDN is reducing costs. The > current draft requires a two-call handshake to establish > the callback. In regions that impose an minimum call > charge (e.g. in the UK, a national call will cost 4.2pence > event for a call that lasts only one second), if the ISDN > connection is frequently allowed to go idle (disconnected > when a certain period of inactivity is detected), using a > two-call callback can DOUBLE your remote access bill! > > To achieve a one-call callback, I am suggesting a new > Callback types in the configuration options : > > 'Callback to Calling Line Identifier (CLI) address'. > > This will be negotiated on 'first contact' and then calls > matching the CLI will be cleared and a callback call > delivered, e.g. > > Requester Acceptor > INITIAL CALL > > -------call (with CLI)--> > <--------accept---------- > ----------LCP callback--> > <--LCP callback ack------ > > <------ Callback options- > (including CLI option) > > -Callback resp(use CLI)-> > <------ Callback ack----- > > <----call cleared ------- > > callback delay > > <----- callback call----- > > Requester Acceptor > SUBSEQUENT CALLS > > ------call (with CLI)--> > <-------- clear--------- > > callback delay > > <----- callback call---- > > > 5. Negotiation of Requester/Acceptor > > The text does not consider that negotiation may be needed > resolve which end will be the Requester and which the > Acceptor. There are a number of possible problems if > both peers think they are the Requester or both think > they are acceptors. > > 6. Callback delay default. > > Having a default value of zero for this timer is not > very switch friendly. How about 1? > > 7. The definition of Callback Address is too restrictive. > > The LCP Callback extension allows for 'undistinguished > octets' or free-format octets. This could be added by > supporting another callback option type and another > callback address format. > > 8. Timers. > > there is no discussion about timer relating to the > callback negotiation messages. > > Steve. > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 19 15:52:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA02051; Mon, 19 Aug 1996 15:52:07 -0400 (EDT) Resent-Date: Mon, 19 Aug 1996 15:52:07 -0400 (EDT) MR-Received: by mta MARVIN.MUAS; Relayed; Mon, 19 Aug 1996 20:50:32 +0000 MR-Received: by mta JOLLY; Relayed; Mon, 19 Aug 1996 19:51:34 +0000 MR-Received: by mta RDGMTS; Relayed; Mon, 19 Aug 1996 19:51:34 +0000 MR-Received: by mta VALMTS; Relayed; Mon, 19 Aug 1996 19:51:36 +0000 Disclose-recipients: prohibited Date: Mon, 19 Aug 1996 20:50:32 +0000 (GMT) From: "Stephen Waters (MARVIN::WATERS) or waters@marvin.enet.dec.com +44 (0) 1548 831170" Subject: RE: PPP Callback Control Protocol (CBCP) comments In-reply-to: To: ietf-ppp@MERIT.EDU Cc: nareng@MICROSOFT.com Message-id: <7132512019081996/A31969/LEGB4/11A89D331F00*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Importance: normal Priority: normal Sensitivity: Company-Confidential UA-content-id: 11A89D331F00 X400-MTS-identifier: [;7132512019081996/A31969/LEGB4] Hop-count: 3 Resent-Message-ID: <"XlgdI3.0.aV.VNC6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1869 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >This draft expired 2 years ago and is not on standards track. > >Callback will be supported thru the LCP callback option which may be >enhanced to support more features. > Sorry? I have a copy dated April 22 1996? I received this copy via the PPP mailing list. It is an 'information' draft, but something like this should be on the standards track. Maybe the author can be persuaded to reissue it as a PPP working group item? When you say 'may be enhanced', do you know who is working on enhancing it? Since there seems to be little interest in this subject, I will volunteer if no one else is already working on it. Steve (waters@marvin.enet.dec.com). - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 19 17:25:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA04300; Mon, 19 Aug 1996 17:25:20 -0400 (EDT) Resent-Date: Mon, 19 Aug 1996 17:25:20 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'Stephen Waters (MARVIN::WATERS) or waters@marvin.enet.dec.com +44 (0) 1548831170'" Cc: Narendra Gidwani Subject: RE: PPP Callback Control Protocol (CBCP) comments Date: Mon, 19 Aug 1996 14:08:35 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 36 TEXT Resent-Message-ID: <"sTgR_3.0.t21.wkD6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1870 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU My apologies, this was filed as an informational since it is implemented in Microsoft products. Nonetheless, it was decided in the PPPEXT meetings that it is best to enhance LCP callback option rather than create another CP. Bill Simpson, I believe, still owns enhancing this option and advancing it on standards track. >---------- >From: Stephen Waters (MARVIN::WATERS) or waters@marvin.enet.dec.com +44 (0) >1548831170[SMTP:Waters@AM_MARVIN.RDGENG.mts.dec.com] >Sent: Monday, August 19, 1996 1:50 PM >To: ietf-ppp@MERIT.EDU >Cc: Narendra Gidwani >Subject: RE: PPP Callback Control Protocol (CBCP) comments > >>This draft expired 2 years ago and is not on standards track. >> >>Callback will be supported thru the LCP callback option which may be >>enhanced to support more features. >> > > Sorry? I have a copy dated April 22 1996? I received this > copy via the PPP mailing list. > > It is an 'information' draft, but something like this > should be on the standards track. Maybe the author can be > persuaded to reissue it as a PPP working group item? > > When you say 'may be enhanced', do you know who is working on enhancing it? > Since there seems to be little interest in this subject, I will > volunteer if no one else is already working on it. > > Steve (waters@marvin.enet.dec.com). > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 04:58:08 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA18044; Tue, 20 Aug 1996 04:58:08 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 04:58:08 -0400 (EDT) From: "rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com Message-Id: <199608200858.KAA18762@vbormc.vbo.dec.com> Date: Tue, 20 Aug 96 10:58:45 MET DST To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: RE: PPP Callback Control Protocol (CBCP) comments Resent-Message-ID: <"w0Hu22.0.dP4.MuN6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1871 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: NAME: Stephen Waters (MARVIN::WATERS) or waters@marvin.enet.dec.com TEL: +44 (0) 1548 831170 ADDR: marvin::waters To: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO>, NAME: Dave Nelson , NAME: Chris Chapman >Nonetheless, it was decided in the PPPEXT meetings that it is best to >enhance LCP callback option rather than create another CP. Bill Simpson, >I believe, still owns enhancing this option and advancing it on >standards track. O.K. Thanks for clearing that up. Can you help me with Bill Simpson's email address? Thanks, Steve. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 05:12:50 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA18498; Tue, 20 Aug 1996 05:12:50 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 05:12:50 -0400 (EDT) Message-ID: <01BB8E80.16714260@localhost> From: Ian Puleston To: "'IETF PPP Mailing List'" Subject: RSA for DES Encryption Key Exchange Date: Tue, 20 Aug 1996 10:12:04 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"M8Msw1.0.fW4.E6O6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1872 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU There are now RFCs for PPP Encryption Control and PPP DES Encryption = (1968/1969) and there is a draft for using RSA Public Key for = authentication (PPP EAP RSA Public Key Authentication protocol). RFC1969 states that "The means by which the secret becomes known to both = communicating elements is beyond the scope of this document; usually = some form of manual configuration is involved". We do a product with DES encryption, and we find that most (maybe all) = of our customers do not want to manually configure encryption keys, = particularly in a widely distributed network, but would rather have = random keys generated automatically. The RSA Public Key mechanism can = then be used to safely send the DES key to the remote end (who has = already been authenticated by a mechanism such as CHAP). Our product = does this using proprietary messages to do the DES key transfer. We would like to do DES encryption over PPP links using RFC 1968/1969, = but require a standard method for the key transfer. Does anyone know if = any work is being done on standards for using RSA Public Key (or some = other method) for transfer of DES keys ? - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 10:12:43 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA24191; Tue, 20 Aug 1996 10:12:43 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 10:12:43 -0400 (EDT) Date: Tue, 20 Aug 96 13:40:05 GMT From: "William Allen Simpson" Message-ID: <5465.wsimpson@greendragon.com> To: ietf-ppp@MERIT.EDU Subject: Re: RE: PPP Callback Control Protocol (CBCP) comments Resent-Message-ID: <"LY5HS1.0.bv5.2VS6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1873 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com > From: NAME: Stephen Waters (MARVIN::WATERS) or waters@marvin.enet.dec.com > > >Nonetheless, it was decided in the PPPEXT meetings that it is best to > >enhance LCP callback option rather than create another CP. Bill Simpson, > >I believe, still owns enhancing this option and advancing it on > >standards track. > > O.K. Thanks for clearing that up. Can you help me with > Bill Simpson's email address? > Ummm, I'm here. I was deliberately holding off until the other raging debates on tunneling and BACP and such cooled off, since I have found that WG list doesn't concentrate well on a large number of papers at the same time.... Let's talk about it privately, instead? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 10:36:26 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA24975; Tue, 20 Aug 1996 10:36:26 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 10:36:26 -0400 (EDT) Date: Tue, 20 Aug 1996 10:35:51 -0400 (EDT) From: Ian Duncan X-Sender: iduncan@magnus2 Reply-To: Ian Duncan To: William Allen Simpson cc: ietf-ppp@MERIT.EDU Subject: Re: RE: PPP Callback Control Protocol (CBCP) comments In-Reply-To: <5465.wsimpson@greendragon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"QAqnx1.0.m56.brS6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1874 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Bill, On Tue, 20 Aug 1996, William Allen Simpson wrote: > Ummm, I'm here. I was deliberately holding off until the other raging > debates on tunneling and BACP and such cooled off [...] Appreciated. Note that there's some machinery in BACP for shovelling dialing information around and it would be reasonable to believe that what's good for BACP is suitable for call-back as well. FWIW. Let's try and be consistent. -- Ian Duncan Access Products Development Newbridge Networks Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 10:53:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA25329; Tue, 20 Aug 1996 10:53:20 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 10:53:20 -0400 (EDT) Mime-Version: 1.0 Date: Tue, 20 Aug 1996 10:09:44 +0100 Message-ID: <219ceb00@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Microsoft Authentication To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"T52rx.0.QB6.S5T6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1875 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In the Microsoft technet article PSS ID Number Q136634 (09-18-1995), PSS database name: CROSSNET it states that: "The Windows NT RAS server does not support RSA MD5 because this method requires a clear-text password at the server" I don't follow this at all. Why is this a reason for not implementing standard MD5 CHAP, and can anyone enlighten me on how this differs from MS-CHAP (RSA MD4) ? Also, does anyone know if SPAP (Shiva Password Authentication Protocol) is a published draft, or is it private to Shiva and Microsoft ? --- Jonathan Goodchild Racal Datacom, Hook, Hampshire, England - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 10:54:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA25372; Tue, 20 Aug 1996 10:54:19 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 10:54:19 -0400 (EDT) Message-Id: <9608201439.AA11304@enet-gw.pa.dec.com> Date: Tue, 20 Aug 96 07:43:56 PDT From: "Pasi Kinnari, DTN 828-5624, European NOS, Valbonne" To: ietf-ppp@MERIT.EDU Apparently-To: ietf-ppp@MERIT.EDU Subject: Q: RFC 1979 (PPP Deflate) Configuration Option Format Resent-Message-ID: <"t1utk3.0.7C6.N6T6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1876 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In the RFC1979, August 1996, Page 8, it says, that the length of the configuration option is 3. I guess is should be 4 (type+length+2bytes)?!? //pasi - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 11:36:04 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA27124; Tue, 20 Aug 1996 11:36:04 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 11:36:04 -0400 (EDT) Message-Id: <199608201532.LAA21385@router.thebrads.com> From: "Brad Wilson" To: "Jonathan Goodchild" , Subject: Re: Microsoft Authentication Date: Tue, 20 Aug 1996 11:31:23 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LlVpn.0.Pd6.UjT6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1877 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > "The Windows NT RAS server does not support RSA MD5 because this > method requires a clear-text password at the server" > > I don't follow this at all. Why is this a reason for not implementing > standard MD5 CHAP, and can anyone enlighten me on how this differs from > MS-CHAP (RSA MD4) ? From what I understand, here are the issues: a) Standard MD5 CHAP requires plain text on the server. The passwords on an NT box are stored in DES format, and cannot be reversed. b) MS CHAP (non-standard) uses the DES form of the password instead of the plaintext form of the password (presumably passing a salt to the remote side to DES the password before hashing against it). PAP, of course, isn't an issue, since the plaintext password goes to the server, where it can then be run through DES and checked against the stored password (much like Unix logins and /etc/passwd). No clue on SPAP, sorry. -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 12:27:27 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA28941; Tue, 20 Aug 1996 12:27:27 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 12:27:27 -0400 (EDT) Message-Id: <199608201622.MAA05679@home.merit.edu> To: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) cc: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication In-reply-to: Your message of "Tue, 20 Aug 1996 10:09:44 BST." <219ceb00@rdl.co.uk> Date: Tue, 20 Aug 1996 12:22:48 -0400 From: "Larry J. Blunk" Resent-Message-ID: <"gcHx82.0.q37.gTU6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1878 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > In the Microsoft technet article PSS ID Number Q136634 (09-18-1995), PSS > > database name: CROSSNET it states that: > > "The Windows NT RAS server does not support RSA MD5 because this > method requires a clear-text password at the server" > > I don't follow this at all. Why is this a reason for not implementing > standard MD5 CHAP, and can anyone enlighten me on how this differs from > MS-CHAP (RSA MD4) ? It's because Microsoft is clueless. MD5 CHAP does not request you keep a "clear-text password". It requires that there is a "shared secret". RFC 1334 does not mandate how this "shared secret" is stored/generated contrary to Microsoft's assertion. MS-CHAP still requires a shared secret, just as MD5 CHAP does. MS-CHAP specifies that the secret is generated by running a one-way has on a password entered by the user (and storing the hashed value). When the user enters their password at authentication time, the hash is again generated and used as the shared secret. This same mechanism could have been used with MD5 CHAP. While most MD5 CHAP implementations will use the user's password directly as the secret, the procotol spec in no way prohibits you from using a hash function on the password to get the secret. It's just a matter of semantics and didn't require a new protocol specification. The distinction is that it requires NAS vendors to modify their PPP implementation to support MS-CHAP. Whereas, if Microsoft had used MD5 CHAP, all that would have been required is a change to the secret storage/generation (i.e., on the RADIUS server, if the NAS can use RADIUS). -Larry Blunk Merit - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 12:58:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA00669; Tue, 20 Aug 1996 12:58:49 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 12:58:49 -0400 (EDT) Message-Id: <9608201702.AA5165@hqsmtp2.ops.3com.com> To: ietf-ppp Cc: bob , Anita Freeman , Shirley Sun/HQ/3Com , Chandy Nilakantan /HQ/3Com , Vince Liu/HQ /3Com From: Leemay Yen/HQ/3Com Date: 20 Aug 96 9:46:43 EDT Subject: IPXCP Interoperability test in CIUG PPP workshop? Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"WX_m21.0.4A.3xU6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1879 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, All: For those who are NOTgoing to this October's PPP workship in PacBell, please ignore this email. I would like to know whether you are interested in doing the PPP IPXCP (RFC 1552) interoperbility testing with our product, AccessBuilder 4000, in this October's CIUG PPP workshop. Bob Larribeau thinks it's a great idea to have such a test and Anita Freeman told me that there are plans to have IPX server in this coming workshop(but need someone to set up the servers, with Novell's or Microsoft's assistance ??). I believe that we could resolve the IPX server setup problems later. However, before going to the details, I just want to know if there is enough interest for this different test. Please reply to me if you are interested. Thanks. Leemay Yen 3Com P.S. Sorry to use this mailing list to send such a request. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 13:33:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA02228; Tue, 20 Aug 1996 13:33:52 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 13:33:52 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'Jonathan.Goodchild@rdl.co.uk'" , "'Larry J. Blunk'" Cc: "'ietf-ppp@MERIT.EDU'" Subject: RE: Microsoft Authentication Date: Tue, 20 Aug 1996 10:26:21 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 61 TEXT Resent-Message-ID: <"QFPGB2.0.VY.xRV6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1880 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >---------- >From: Larry J. Blunk[SMTP:ljb@MERIT.EDU] >Sent: Tuesday, August 20, 1996 9:22 AM >To: Jonathan.Goodchild@rdl.co.uk >Cc: ietf-ppp@MERIT.EDU >Subject: Re: Microsoft Authentication > > >> >> In the Microsoft technet article PSS ID Number Q136634 (09-18-1995), >>PSS >> >> database name: CROSSNET it states that: >> >> "The Windows NT RAS server does not support RSA MD5 because this >> method requires a clear-text password at the server" >> >> I don't follow this at all. Why is this a reason for not implementing >> standard MD5 CHAP, and can anyone enlighten me on how this differs >>from >> MS-CHAP (RSA MD4) ? > > > > It's because Microsoft is clueless. MD5 CHAP does not request you >keep a "clear-text password". It requires that there is a "shared >secret". RFC 1334 does not mandate how this "shared secret" is >stored/generated contrary to Microsoft's assertion. MS-CHAP still >requires a shared secret, just as MD5 CHAP does. MS-CHAP specifies >that the secret is generated by running a one-way has on a password >entered by the user (and storing the hashed value). When the >user enters their password at authentication time, the hash is again >generated and used as the shared secret. This same mechanism could >have been used with MD5 CHAP. While most MD5 CHAP implementations >will use the user's password directly as the secret, the procotol spec >in no way prohibits you from using a hash function on the password to get the >secret. It's just a matter of semantics and didn't require a new >protocol specification. The distinction is that it requires NAS >vendors to modify their PPP implementation to support MS-CHAP. Whereas, >if Microsoft had used MD5 CHAP, all that would have been required is >a change to the secret storage/generation (i.e., on the RADIUS server, >if the NAS can use RADIUS). > gurdeep> Ahhaa. Another bright guy who has figured out how clueless Microsoft is! Anyway here is the scoop: Since NT and Win95 store their passwords in MD-4 hashed (not MD-5) form it makes PPP logon from NT and Win95 clients seamless i.e. you dont need to type two usernames and passwords - one to logon to the machine and one for dialup. Since the password is *only* available in MD-4 form on the server end it is not possible to validate MD-5 derived credentials. One way to fix this is to store the password in clear text so that all the different password derivatives can be supported (MD-4, MD-5, DES, Netware, etc.) - but this violates NT's security tenets. That is what the technet article alludes to. (Larry in the future feel free to ask questions.) > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 14:02:45 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA03055; Tue, 20 Aug 1996 14:02:45 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 14:02:45 -0400 (EDT) Message-Id: <199608201752.NAA09998@home.merit.edu> To: Gurdeep Singh Pall cc: "'Jonathan.Goodchild@rdl.co.uk'" , "'ietf-ppp@MERIT.EDU'" Subject: Re: Microsoft Authentication In-reply-to: Your message of "Tue, 20 Aug 1996 10:26:21 PDT." Date: Tue, 20 Aug 1996 13:52:27 -0400 From: "Larry J. Blunk" Resent-Message-ID: <"M-5bt1.0.Ql.0tV6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1881 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > >---------- > >From: Larry J. Blunk[SMTP:ljb@MERIT.EDU] > >Sent: Tuesday, August 20, 1996 9:22 AM > >To: Jonathan.Goodchild@rdl.co.uk > >Cc: ietf-ppp@MERIT.EDU > >Subject: Re: Microsoft Authentication > > > > > >> > >> In the Microsoft technet article PSS ID Number Q136634 (09-18-1995), > >>PSS > >> > >> database name: CROSSNET it states that: > >> > >> "The Windows NT RAS server does not support RSA MD5 because this > >> method requires a clear-text password at the server" > >> > >> I don't follow this at all. Why is this a reason for not implementin >g > >> standard MD5 CHAP, and can anyone enlighten me on how this differs > >>from > >> MS-CHAP (RSA MD4) ? > > > > > > > > It's because Microsoft is clueless. MD5 CHAP does not request you > >keep a "clear-text password". It requires that there is a "shared > >secret". RFC 1334 does not mandate how this "shared secret" is > >stored/generated contrary to Microsoft's assertion. MS-CHAP still > >requires a shared secret, just as MD5 CHAP does. MS-CHAP specifies > >that the secret is generated by running a one-way has on a password > >entered by the user (and storing the hashed value). When the > >user enters their password at authentication time, the hash is again > >generated and used as the shared secret. This same mechanism could > >have been used with MD5 CHAP. While most MD5 CHAP implementations > >will use the user's password directly as the secret, the procotol spec > >in no way prohibits you from using a hash function on the password to get th >e > >secret. It's just a matter of semantics and didn't require a new > >protocol specification. The distinction is that it requires NAS > >vendors to modify their PPP implementation to support MS-CHAP. Whereas, > >if Microsoft had used MD5 CHAP, all that would have been required is > >a change to the secret storage/generation (i.e., on the RADIUS server, > >if the NAS can use RADIUS). > > > gurdeep> Ahhaa. Another bright guy who has figured out how clueless > Microsoft is! Anyway here is the scoop: > > Since NT and Win95 store their passwords in MD-4 hashed (not MD-5) form > it makes PPP logon from NT and Win95 clients seamless i.e. you dont need > to type two usernames and passwords - one to logon to the machine and > one for dialup. Since the password is *only* available in MD-4 form on > the server end it is not possible to validate MD-5 derived credentials. > One way to fix this is to store the password in clear text so that all > the different password derivatives can be supported (MD-4, MD-5, DES, > Netware, etc.) - but this violates NT's security tenets. That is what > the technet article alludes to. > > (Larry in the future feel free to ask questions.) > It doesn't matter whether the password it hashed with MD4, MD5, DES or whatever when it is stored, other than the peer must be aware of the hashing function used when the user enters their password. When it runs the hash function, it will then have the same secret as stored on the server. It can then use MD5 CHAP for authentication using that shared secret. Yes, it would mean that Microsoft would need code for both the MD4 (to hash the password) and MD5 (for MD5 CHAP authentication) digests, but it certainly would work and would have made the NAS vendors lives easier. -Larry Blunk Merit - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 14:03:34 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA03120; Tue, 20 Aug 1996 14:03:34 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 14:03:34 -0400 (EDT) Message-Id: <199608201803.OAA10497@home.merit.edu> To: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication Date: Tue, 20 Aug 1996 14:03:26 -0400 From: "Larry J. Blunk" Resent-Message-ID: <"Cupsn3.0.Mm.ntV6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1882 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > >---------- > >From: Larry J. Blunk[SMTP:ljb@MERIT.EDU] > >Sent: Tuesday, August 20, 1996 9:22 AM > >To: Jonathan.Goodchild@rdl.co.uk > >Cc: ietf-ppp@MERIT.EDU > >Subject: Re: Microsoft Authentication > > > > > >> > >> In the Microsoft technet article PSS ID Number Q136634 (09-18-1995), > >>PSS > >> > >> database name: CROSSNET it states that: > >> > >> "The Windows NT RAS server does not support RSA MD5 because this > >> method requires a clear-text password at the server" > >> > >> I don't follow this at all. Why is this a reason for not implementin >g > >> standard MD5 CHAP, and can anyone enlighten me on how this differs > >>from > >> MS-CHAP (RSA MD4) ? > > > > > > > > It's because Microsoft is clueless. MD5 CHAP does not request you > >keep a "clear-text password". It requires that there is a "shared > >secret". RFC 1334 does not mandate how this "shared secret" is > >stored/generated contrary to Microsoft's assertion. MS-CHAP still > >requires a shared secret, just as MD5 CHAP does. MS-CHAP specifies > >that the secret is generated by running a one-way has on a password > >entered by the user (and storing the hashed value). When the > >user enters their password at authentication time, the hash is again > >generated and used as the shared secret. This same mechanism could > >have been used with MD5 CHAP. While most MD5 CHAP implementations > >will use the user's password directly as the secret, the procotol spec > >in no way prohibits you from using a hash function on the password to get th >e > >secret. It's just a matter of semantics and didn't require a new > >protocol specification. The distinction is that it requires NAS > >vendors to modify their PPP implementation to support MS-CHAP. Whereas, > >if Microsoft had used MD5 CHAP, all that would have been required is > >a change to the secret storage/generation (i.e., on the RADIUS server, > >if the NAS can use RADIUS). > > > gurdeep> Ahhaa. Another bright guy who has figured out how clueless > Microsoft is! Anyway here is the scoop: > > Since NT and Win95 store their passwords in MD-4 hashed (not MD-5) form > it makes PPP logon from NT and Win95 clients seamless i.e. you dont need > to type two usernames and passwords - one to logon to the machine and > one for dialup. Since the password is *only* available in MD-4 form on > the server end it is not possible to validate MD-5 derived credentials. > One way to fix this is to store the password in clear text so that all > the different password derivatives can be supported (MD-4, MD-5, DES, > Netware, etc.) - but this violates NT's security tenets. That is what > the technet article alludes to. > > (Larry in the future feel free to ask questions.) > It doesn't matter whether the password it hashed with MD4, MD5, DES or whatever when it is stored, other than the peer must be aware of the hashing function used when the user enters their password. When it runs the hash function, it will then have the same secret as stored on the server. It can then use MD5 CHAP for authentication using that shared secret. Yes, it would mean that Microsoft would need code for both the MD4 (to hash the password) and MD5 (for MD5 CHAP authentication) digests, but it certainly would work and would have made the NAS vendors lives easier. -Larry Blunk Merit P.S. I'm assuming some sort of random salt isn't incorporated into the hash function. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 14:15:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA03455; Tue, 20 Aug 1996 14:15:12 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 14:15:12 -0400 (EDT) Date: Tue, 20 Aug 1996 11:14:57 -0700 (PDT) From: Erik Olson To: Gurdeep Singh Pall Cc: "'ietf-ppp@MERIT.EDU'" Subject: RE: Microsoft Authentication In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"mHulF2.0.gr.b2W6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1883 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 20 Aug 1996, Gurdeep Singh Pall wrote: > > It's because Microsoft is clueless. MD5 CHAP does not request you > >keep a "clear-text password". It requires that there is a "shared > >secret". RFC 1334 does not mandate how this "shared secret" is > >stored/generated contrary to Microsoft's assertion. MS-CHAP still > >requires a shared secret, just as MD5 CHAP does. > Ahhaa. Another bright guy who has figured out how clueless > Microsoft is! Anyway here is the scoop: > > Since NT and Win95 store their passwords in MD-4 hashed (not MD-5) form > it makes PPP logon from NT and Win95 clients seamless i.e. you dont need > to type two usernames and passwords - one to logon to the machine and > one for dialup. Since the password is *only* available in MD-4 form on > the server end it is not possible to validate MD-5 derived credentials. > One way to fix this is to store the password in clear text so that all > the different password derivatives can be supported (MD-4, MD-5, DES, > Netware, etc.) - but this violates NT's security tenets. That is what > the technet article alludes to. No, I think Larry is still correct in his assertation. There would have been nothing *wrong* with simply using the MD4-hashed NT password (or the DES-hashed Lan Manager password, or whatever hash you happen to have) as the shared secret, and doing the normal MD5 hashing on this. The downside is that to be interoperable with this, you still must modify the other side of the connection to actually *produce* the MD4 hash, and this is almost as annoying to implement as the entire separate CHAP digest type. And actually, having the separate CHAP digest does clarify which hash you're using as the shared secret. So there is some sense in MS-CHAP, when used in the context of "client-server" dialups. - Erik --- Erik D. Olson eriko@wrq.com WRQ, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 15:04:02 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA04929; Tue, 20 Aug 1996 15:04:02 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 15:04:02 -0400 (EDT) Date: Tue, 20 Aug 1996 13:03:41 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608201903.NAA24379@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"vECeF1.0.YC1.OmW6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1884 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > "The Windows NT RAS server does not support RSA MD5 because this > > method requires a clear-text password at the server" > > > > I don't follow this at all. Why is this a reason for not implementing > > standard MD5 CHAP, and can anyone enlighten me on how this differs from > > MS-CHAP (RSA MD4) ? > > >From what I understand, here are the issues: > > a) Standard MD5 CHAP requires plain text on the server. The passwords on an > NT box are stored in DES format, and cannot be reversed. > > b) MS CHAP (non-standard) uses the DES form of the password instead of the > plaintext form of the password (presumably passing a salt to the remote > side to DES the password before hashing against it). > ... I've seen statements similar to that before, but they've never made sense to me. I think it is impossible for a PPP peer to have a secret that both is secret from itself and that is used to authenticate other PPP peers. If "cannot be reversed" has any useful meaning, it must be that the secret cannot be determined from any data available to the local peer. If the secret cannot be determined by the local peer, then it cannot be used by the local peer to check a response respond to a challenge, by computing a number or string that depends on both the secret and a varying challenge value. If a DES encrypted password were used as a constant part of a computation used to answer a challenge, then the DES-encrypted password would itself be a plaintext password. That the password is obtained by a long computation (e.g. DES or MD4) from some other, Unicode string would be irrelevant. If the secret is in one or more disk files (or other 'stable storage'), so that files copied from one computer to another would allow the other computer to falsely authenticate itself, then the "cannot be reversed" nature of the string is irrelevant. The password might not be clear text in the sense of being English words or a Unicode string, but it is cleartext in the cryptographic sense. I've just now read ftp.sgi.com:developr/rfc/chapexts.txt. That document is not clear to me, and I doubt I understand the MS CHAP protocol. However, it seems that anyone who can get the NT file containing those "cannot be reversed" values can break into the NT box simpy by using one of the "cannot be reversed" values. It appears that NT keeps its real MS CHAP passwords as cleartext on the NT server. ]From: Gurdeep Singh Pall ] ... ]gurdeep> Ahhaa. Another bright guy who has figured out how clueless ]Microsoft is! Anyway here is the scoop: ] ]Since NT and Win95 store their passwords in MD-4 hashed (not MD-5) form ]it makes PPP logon from NT and Win95 clients seamless i.e. you dont need ]to type two usernames and passwords - one to logon to the machine and ]one for dialup. Since the password is *only* available in MD-4 form on ]the server end it is not possible to validate MD-5 derived credentials. ]One way to fix this is to store the password in clear text so that all ]the different password derivatives can be supported (MD-4, MD-5, DES, ]Netware, etc.) - but this violates NT's security tenets. That is what ]the technet article alludes to. Perhaps that text should be reworded to respond more forcefully to the charge that Microsoft doesn't get it: - in many cases it is a serious security problem to allow a password that is good for a PPP link to also be used for starting sessions in which commands can be run. Yes, in the trivial case of a single user, single-process "PPP client," this consideration may not apply. On the other hand, consider a PC used by members of a family to access the Internet, so that different family members can see differing degrees of naughtiness, but they all use the same PPP credentials with the nearby PPP server. - in effect, the MS CHAP PPP secret is cleartext. That the constant, cleartext MS CHAP secret is derived from some other password using MD4 or DES is irrelevant as far as PPP is concerned, except that most people consider deriving one password or secret used for one purpose from some other password or secret used for some other purpose a serious security problem. - Contrary to that text, it is "possible to validate MD-5 derived credentials". Microsoft could easily and trivially use MD5 CHAP instead of MS CHAP, simply by using the MD4 (DES?) encryption of the user's password as the shared secret. The NT server could (as it does now) save the DES (MD4?) encrypted version of the Unicode password and use that as the secret for MD5 instead of DES (MD4?). - supporting a standard PPP authentication scheme implies nothing about "different password derivatives ... (MD-4, MD-5, DES, Netware, etc.)." That many other systems using PAP or CHAP PPP authentication also use Kerberos, login/getty, rhosts, and various other authentication schemes implies nothing about PAP or CHAP. Vernon Schryver, vjs@sgi.com P.S. my suggestions to produce a new authentication mechanism like CHAP but in LCP have met with resounding indifference privately. The consensus seems to be "yes, but at this late date the current scheme is not broken badly enough to justify trying to replace it." So it goes. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 15:11:22 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA05261; Tue, 20 Aug 1996 15:11:22 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 15:11:22 -0400 (EDT) Message-Id: <199608201911.PAA26678@router.thebrads.com> From: "Brad Wilson" To: "'ietf-ppp@MERIT.EDU'" Subject: Re: Microsoft Authentication Date: Tue, 20 Aug 1996 15:09:39 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dhM7W3.0.uH1.LtW6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1885 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > It doesn't matter whether the password it hashed with MD4, MD5, > DES or whatever when it is stored, other than the peer must be > aware of the hashing function used when the user enters their > password. When it runs the hash function, it will then have the > same secret as stored on the server. It can then use MD5 CHAP > for authentication using that shared secret. Yes, it would mean > that Microsoft would need code for both the MD4 (to hash the password) and > MD5 (for MD5 CHAP authentication) digests, but it certainly would > work and would have made the NAS vendors lives easier. Hmm ... I'm not sure I agree here. Why is it 'easier' to support MD4 inside MD5 rather than just simply MD4? NAS vendors would still need to support MD4 as well as MD5, in either case, and you would still have to have a separate authentication type (unless you propose to try passwords in plaintext and, failing that, MD4 them first to see if the other end is a Microsoft client/server). It still remains that anyone who wants to support encrypted passwords with MS will still need to implement MD4. What is the 'easier' you get out of this scenario? (FWIW, I think this discussion is getting way off the target of the original intent of the Email) -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 15:32:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA06005; Tue, 20 Aug 1996 15:32:33 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 15:32:33 -0400 (EDT) Message-Id: <199608201932.PAA15050@home.merit.edu> To: "Brad Wilson" cc: "'ietf-ppp@MERIT.EDU'" Subject: Re: Microsoft Authentication In-reply-to: Your message of "Tue, 20 Aug 1996 15:09:39 EDT." <199608201911.PAA26678@router.thebrads.com> Date: Tue, 20 Aug 1996 15:32:20 -0400 From: "Larry J. Blunk" Resent-Message-ID: <"gNvYT1.0.UT1.CBX6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1886 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > It doesn't matter whether the password it hashed with MD4, MD5, > > DES or whatever when it is stored, other than the peer must be > > aware of the hashing function used when the user enters their > > password. When it runs the hash function, it will then have the > > same secret as stored on the server. It can then use MD5 CHAP > > for authentication using that shared secret. Yes, it would mean > > that Microsoft would need code for both the MD4 (to hash the password) > and > > MD5 (for MD5 CHAP authentication) digests, but it certainly would > > work and would have made the NAS vendors lives easier. > > Hmm ... I'm not sure I agree here. Why is it 'easier' to support MD4 > inside MD5 rather than just simply MD4? NAS vendors would still need to > support MD4 as well as MD5, in either case, and you would still have to > have a separate authentication type (unless you propose to try passwords in > plaintext and, failing that, MD4 them first to see if the other end is a > Microsoft client/server). It still remains that anyone who wants to > support encrypted passwords with MS will still need to implement MD4. > > What is the 'easier' you get out of this scenario? > > (FWIW, I think this discussion is getting way off the target of the > original intent of the Email) > > -- > Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer > crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet > > "I know that you would love to know the answers, > but to you the truth is just another lie." > Assuming the NAS supported RADIUS (as all good NAS's should) they would not need to implement MD4. The RADIUS server could either store the the password in the clear and perform the MD4 hash to generate the secret or store the pre-hashed secret. In either case, the NAS neither knows or cares. -Larry Blunk Merit - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 15:36:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA06127; Tue, 20 Aug 1996 15:36:06 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 15:36:06 -0400 (EDT) Date: Tue, 20 Aug 1996 13:35:46 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608201935.NAA24487@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication Resent-Message-ID: <"yKQw_3.0.OV1.WEX6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1887 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Brad Wilson" > ... > Hmm ... I'm not sure I agree here. Why is it 'easier' to support MD4 > inside MD5 rather than just simply MD4? NAS vendors would still need to > support MD4 as well as MD5, in either case, and you would still have to > have a separate authentication type (unless you propose to try passwords in > plaintext and, failing that, MD4 them first to see if the other end is a > Microsoft client/server). It still remains that anyone who wants to > support encrypted passwords with MS will still need to implement MD4. > > What is the 'easier' you get out of this scenario? > ... Not so. Consider how most of us MD5 CHAP. - Somehow the operators of the two peers pick a common secret, say "JimBob'sPC", and store it in their computers. Now consider how a clue-full Microsoft can use MD5 CHAP: - the operators of the two peers, one a PC and the other your favorite non-Microsoft box, pick a common secret, say "JimBob'sPC". - the operator of the PC says "just a minute. let me feed that into the Microsoft SuperSecretSecurityEnhancer version 3.54. yep, it says we will be using "asdfjasfdqweoiuwqer" for our MD5 CHAP password and I'm supposed to tell you that. - so Jim Bob lets the Microsoft SuperSecretSecurityEnhancer version 3.54 put "JimBob'sPC" into his PC while the operator of the non-Microsoft box types "asdfjasfdqweoiuwqer" into that box. That the Microsoft SuperSecretSecurityEnhancer version 3.54 uses DES, MD4 or rot13 is irrelevant to everyone except people in Redmond. The non-Microsoft box need not have any code that does MD4, DES, or rot13. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 15:56:18 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA06729; Tue, 20 Aug 1996 15:56:18 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 15:56:18 -0400 (EDT) Date: Tue, 20 Aug 1996 19:59:29 GMT Message-Id: <199608201959.TAA01169@carp.morningstar.com> From: Karl Fox To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication In-Reply-To: <199608201903.NAA24379@mica.denver.sgi.com> References: <199608201903.NAA24379@mica.denver.sgi.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"m-B3X1.0.pe1.UXX6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1888 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > it seems that anyone who can get the NT file containing those > "cannot be reversed" values can break into the NT box simpy by using > one of the "cannot be reversed" values. It appears that NT keeps > its real MS CHAP passwords as cleartext on the NT server. When I brought up this very issue back when MS-CHAP first came out, I got the feeling that nobody understood the problem. In any case, it's no worse than CHAP, just incompatible. Except, of course, that MD4 is a little less secure than MD5. Plus I have my doubts about the security of the way MS-CHAP hashes passwords (padding with zeros); it looks to me like it would be easy to break when short passwords are used (DES gets used with a zero key). -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 *** NOTE: NEW PHONE NUMBER. Try +1 614 451 1883 ext. 841 if it doesn't work *** - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 17:01:15 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA08655; Tue, 20 Aug 1996 17:01:15 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 17:01:15 -0400 (EDT) Date: Tue, 20 Aug 1996 21:04:15 GMT Message-Id: <199608202104.VAA04502@carp.morningstar.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Cc: Saroop Mathur , Mark.S.Lewis@telebit.com Subject: CIPX progress Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"BjWqV2.0.t62.KUY6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1889 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Many of the comments I got back about RFC 1553 indicated that the language could use some clarification in a few places. I haven't gotten any response to my e-mail to the authors, Saroop Mathur and Mark Lewis . Does anybody know how to contact either of them? -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 *** NOTE: NEW PHONE NUMBER. Try +1 614 451 1883 ext. 841 if it doesn't work *** - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 17:05:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA08803; Tue, 20 Aug 1996 17:05:17 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 17:05:17 -0400 (EDT) Message-Id: <9608210003.AA3039@SMTP.shiva.com> To: ietf-ppp Cc: Vernon Schryver From: Robert Webster/Shiva Corporation Date: 20 Aug 96 17:04:20 EDT Subject: RE: Microsoft Authentication Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"o69UG1.0.F92.9YY6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1890 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> > "The Windows NT RAS server does not support RSA MD5 because this >> > method requires a clear-text password at the server" >> > >> > I don't follow this at all. Why is this a reason for not implementing >> > standard MD5 CHAP, and can anyone enlighten me on how this differs from >> > MS-CHAP (RSA MD4) ? >> >> >From what I understand, here are the issues: >> >> a) Standard MD5 CHAP requires plain text on the server. The passwords on an >> NT box are stored in DES format, and cannot be reversed. >> >> b) MS CHAP (non-standard) uses the DES form of the password instead of the >> plaintext form of the password (presumably passing a salt to the remote >> side to DES the password before hashing against it). >> ... >I've seen statements similar to that before, but they've never made >sense to me. I think it is impossible for a PPP peer to have a secret >that both is secret from itself and that is used to authenticate other >PPP peers. If "cannot be reversed" has any useful meaning, it must be >that the secret cannot be determined from any data available to the >local peer. If the secret cannot be determined by the local peer, then >it cannot be used by the local peer to check a response respond to a >challenge, by computing a number or string that depends on both the >secret and a varying challenge value. >If a DES encrypted password were used as a constant part of a >computation used to answer a challenge, then the DES-encrypted password >would itself be a plaintext password. That the password is obtained by >a long computation (e.g. DES or MD4) from some other, Unicode string >would be irrelevant. > >If the secret is in one or more disk files (or other 'stable storage'), >so that files copied from one computer to another would allow the other >computer to falsely authenticate itself, then the "cannot be reversed" >nature of the string is irrelevant. The password might not be clear >text in the sense of being English words or a Unicode string, but it is >cleartext in the cryptographic sense. >I've just now read ftp.sgi.com:developr/rfc/chapexts.txt. That >document is not clear to me, and I doubt I understand the MS CHAP >protocol. However, it seems that anyone who can get the NT file >containing those "cannot be reversed" values can break into the NT box >simpy by using one of the "cannot be reversed" values. It appears that >NT keeps its real MS CHAP passwords as cleartext on the NT server. Microsoft needs to irreversibly hash all of the Windows NT passwords because the server code is running on a PC. It is quite a bit easier to scan memory on a PC for a clear text password than it is on a typical dedicated-hardware NAS. This is the crux of the MS-CHAP problem. Microsoft cannot recover the clear text password to use for MD5 CHAP, since it does not store this value on the NT server. Rob Webster Shiva Corp. ]From: Gurdeep Singh Pall ] ... ]gurdeep> Ahhaa. Another bright guy who has figured out how clueless ]Microsoft is! Anyway here is the scoop: ] ]Since NT and Win95 store their passwords in MD-4 hashed (not MD-5) form ]it makes PPP logon from NT and Win95 clients seamless i.e. you dont need ]to type two usernames and passwords - one to logon to the machine and ]one for dialup. Since the password is *only* available in MD-4 form on ]the server end it is not possible to validate MD-5 derived credentials. ]One way to fix this is to store the password in clear text so that all ]the different password derivatives can be supported (MD-4, MD-5, DES, ]Netware, etc.) - but this violates NT's security tenets. That is what ]the technet article alludes to. Perhaps that text should be reworded to respond more forcefully to the charge that Microsoft doesn't get it: - in many cases it is a serious security problem to allow a password that is good for a PPP link to also be used for starting sessions in which commands can be run. Yes, in the trivial case of a single user, single-process "PPP client," this consideration may not apply. On the other hand, consider a PC used by members of a family to access the Internet, so that different family members can see differing degrees of naughtiness, but they all use the same PPP credentials with the nearby PPP server. - in effect, the MS CHAP PPP secret is cleartext. That the constant, cleartext MS CHAP secret is derived from some other password using MD4 or DES is irrelevant as far as PPP is concerned, except that most people consider deriving one password or secret used for one purpose from some other password or secret used for some other purpose a serious security problem. - Contrary to that text, it is "possible to validate MD-5 derived credentials". Microsoft could easily and trivially use MD5 CHAP instead of MS CHAP, simply by using the MD4 (DES?) encryption of the user's password as the shared secret. The NT server could (as it does now) save the DES (MD4?) encrypted version of the Unicode password and use that as the secret for MD5 instead of DES (MD4?). - supporting a standard PPP authentication scheme implies nothing about "different password derivatives ... (MD-4, MD-5, DES, Netware, etc.)." That many other systems using PAP or CHAP PPP authentication also use Kerberos, login/getty, rhosts, and various other authentication schemes implies nothing about PAP or CHAP. Vernon Schryver, vjs@sgi.com P.S. my suggestions to produce a new authentication mechanism like CHAP but in LCP have met with resounding indifference privately. The consensus seems to be "yes, but at this late date the current scheme is not broken badly enough to justify trying to replace it." So it goes. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 18:25:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA10578; Tue, 20 Aug 1996 18:25:59 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 18:25:59 -0400 (EDT) Date: Tue, 20 Aug 1996 16:25:42 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608202225.QAA25063@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"YHaKb1.0.0b2.ojZ6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1891 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Robert Webster/Shiva Corporation > > ... it seems that anyone who can get the NT file > >containing those "cannot be reversed" values can break into the NT box > >simpy by using one of the "cannot be reversed" values. It appears that > >NT keeps its real MS CHAP passwords as cleartext on the NT server. > > Microsoft needs to irreversibly hash all of the Windows NT passwords because > the server > code is running on a PC. It is quite a bit easier to scan memory on a PC for a > clear text password than it is on a typical dedicated-hardware NAS. > This is the crux of the MS-CHAP problem. Microsoft cannot recover the clear > text password > to use for MD5 CHAP, since it does not store this value on the NT server. Please read my paragraph above. I'll say it again: MS CHAP USES A CLEARTEXT PASSWORD That the password looks like gobbledygook is completely irrelevant. The term "cleartext" has nothing to do with whether the password appears is to a human, or even whether the password used in the protocol is the same as something typed by a human. The MS CHAP password is cleartext because anyone who grabs the contents of that NT file has all of the information that is necessary to break into that NT server. There is no way that the NT server can tell whether the PPP peer is the legitimate client or a fake using a stolen copy of the NT file. The ASCII or Unicode password typed by an operator is not the main password that must be considered when analyzing the security of MS CHAP. That the normal, legitmate use of MS CHAP involves taking an ASCII or Unicode password from the operator and computing a hash is irrelevant, unless you assume that all of your adversaries are incredibly stupid fools. Bad guys that are not dirt stupid will skip the hassles of hashing ASCII strings, and use the real password from the NT file. A bad guy with at least half a brain will not care what the original ASCII password might have been, and will use the cleartext password from the NT file. That there might be a related password that gives a different kind of access is mostly irrelevant to PPP. The MS CHAP PPP password is whatever secret the NT server has. That it is a hash of a Unicode string is completely irrelevant to us. All that matters is that MS CHAP DOES USE CLEARTEXT PPP PASSWORDS AND STORES THE CLEARTEXT PASSWORDS ON THE NT SERVER. This aint rocket science. There is nothing subtle about it. This CHAP problem of cleartext passwords is provably unsolvable. If the NT operating system can look at files on its disk to figure out a secret to be used to validate the response to some kind of challenge, then a bad guy can copy the contents of that disk and make the same calculation, except to generate a response that the target NT system will find valid. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 18:52:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA11228; Tue, 20 Aug 1996 18:52:49 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 18:52:49 -0400 (EDT) Message-Id: <199608202254.SAA32005@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: Microsoft Authentication Date: Tue, 20 Aug 1996 18:52:37 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"9ZJc43.0.5l2.z6a6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1892 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Vernon Schryver This is lengthy. If you care, read it ALL before you respond. I do -not- work for Microsoft, and have been known to bash them from time to time, but all this anti-Microsoft rhetoric is ridiculous (not all from Vernon, obviously). > I've seen statements similar to that before, but they've never made > sense to me. I think it is impossible for a PPP peer to have a secret > that both is secret from itself and that is used to authenticate other > PPP peers. If "cannot be reversed" has any useful meaning, it must be > that the secret cannot be determined from any data available to the > local peer. It can be validated against a plain text version of the password by re-encryption. This, of course, happens when the user logs in (just like Unix). > If a DES encrypted password were used as a constant part of a > computation used to answer a challenge, then the DES-encrypted password > would itself be a plaintext password. That the password is obtained by > a long computation (e.g. DES or MD4) from some other, Unicode string > would be irrelevant. Only marginally irrelevant. The password, which could be used for other things (such as gaining access to the box) cannot easily be determined from the 'plain text but encrypted' version of the password, without lots of brute force. As I understand it, C2 certification requirements state that the users' passwords cannot be kept in plain text on the box. Since NT chose to implement PPP authentication against the user database, they could not perform standard CHAP with MD5 (as the definition of the 'shared secret' may vary from box to box; DES or MD4 encrypted on a Microsoft box vs. plain text on another system). > I've just now read ftp.sgi.com:developr/rfc/chapexts.txt. That > document is not clear to me, and I doubt I understand the MS CHAP > protocol. However, it seems that anyone who can get the NT file > containing those "cannot be reversed" values can break into the NT box > simpy by using one of the "cannot be reversed" values. It appears that > NT keeps its real MS CHAP passwords as cleartext on the NT server. The C2 certification document recognizes, as most security experts do, that once physical security is breached all hope is gone. NT keeps encrypted passwords for the same reason Unix keeps encrypted passwords (in fact, NT's encrypted passwords are protected under portions of the Registry that are not even accessible to any users, unless a system administrator breaches the default security, unlike Unix which stores the DES passwords in /etc/passwd). Microsoft made a design decision: one set of passwords. That means, either you do PAP or MSCHAP if you want to authenticate against an NT box, because they didn't want to keep plain text version of access passwords on the hard disk (something you'll find on my Linux box, unfortunately). If someone were to comprimise the physical security of my Linux box, boot a single user kernel on a floppy disk as root, they could access that file and the security is comprimised. Microsoft merely made the choice, based on their desire of C2, to not give the bad guy that option. Do you argue this vehemently against Unix, too? > Perhaps that text should be reworded to respond more forcefully to the > charge that Microsoft doesn't get it: Let us address each of these in turn. > - in many cases it is a serious security problem to allow a password > that is good for a PPP link to also be used for starting sessions > in which commands can be run. Yes, in the trivial case of a single > user, single-process "PPP client," this consideration may not > apply. On the other hand, consider a PC used by members of a > family to access the Internet, so that different family members can > see differing degrees of naughtiness, but they all use the same PPP > credentials with the nearby PPP server. On client systems, the password does not need to be saved, and you are not necessarily made to live under the same restrictions (in fact, in NT 3.51, you CANNOT store the client side password for access, because their client side supports MD5 CHAP, even though their server side doesn't). So ignore the client side access; it doesn't apply. > - in effect, the MS CHAP PPP secret is cleartext. That the constant, > cleartext MS CHAP secret is derived from some other password using > MD4 or DES is irrelevant as far as PPP is concerned ^^^^^^^^^^^^^^^^^^^^^^^^^^ Despite this being the PPP protocol, and this being the PPP working group, Microsoft makes its decisions in the context of the entire operating system, NOT just the PPP protocol. > most people consider deriving one password or secret used for one > purpose from some other password or secret used for some other > purpose a serious security problem. Should I have a different password for each command I can issue in my operating system? Exactly at what point do we say "enough is enough"? It is perfectly reasonable, IMO, to have a single password which logs you onto a remote system, whether that is via PPP or Ethernet, and allows you to access that system. > - Contrary to that text, it is "possible to validate MD-5 derived > credentials". Microsoft could easily and trivially use MD5 CHAP > instead of MS CHAP, simply by using the MD4 (DES?) encryption of > the user's password as the shared secret. The NT server could (as > it does now) save the DES (MD4?) encrypted version of the Unicode > password and use that as the secret for MD5 instead of DES (MD4?). Except that all clients expect MD5 CHAP to be across a plain text password. If MS started injected MD4 encrypted passwords with MD5 CHAP -- and this is the important part -- WITHOUT A SEPARATE AUTHENTICATION TYPE SO THAT WE KNEW AHEAD OF TIME -- you'd be screaming just as loudly. > - supporting a standard PPP authentication scheme implies nothing > about "different password derivatives ... Not true, from what I've seen. PPP clients would have to try a password and, failing, then attempt to encode it with MD4 and try again to see if that succeeded. I think the different type is a good solution. > P.S. my suggestions to produce a new authentication mechanism like > CHAP but in LCP have met with resounding indifference privately. The > consensus seems to be "yes, but at this late date the current scheme > is not broken badly enough to justify trying to replace it." > So it goes. Nonetheless, I would help you work on such a beast if you still would like to forward it. -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 19:47:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA12319; Tue, 20 Aug 1996 19:47:17 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 19:47:17 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp'" , "'Vernon Schryver'" Subject: RE: Microsoft Authentication Date: Tue, 20 Aug 1996 16:44:38 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 26 TEXT Resent-Message-ID: <"ij10z1.0.B03.0wa6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1893 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >---------- Vernon Schryver writes: > >Perhaps that text should be reworded to respond more forcefully to the >charge that Microsoft doesn't get it: > > - Contrary to that text, it is "possible to validate MD-5 derived > credentials". Microsoft could easily and trivially use MD5 CHAP > instead of MS CHAP, simply by using the MD4 (DES?) encryption of > the user's password as the shared secret. The NT server could (as > it does now) save the DES (MD4?) encrypted version of the Unicode > password and use that as the secret for MD5 instead of DES (MD4?). > gurdeep> Your comments above indicate your inability to comprehend plain english - or that you dont have a clue (I'm leaning towards the latter). I suggest you read my email ten times again to understand why your suggestion above will not help interoperability (MD-5 hash of a MD-4 hash of a password is NOT MD-5 hash of a password). In any case most *progressive* vendors interested in supporting seamless dial-up integration are implementing MS-CHAP (based on your responses I'm quite sure SGI is not). > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 20:49:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA13614; Tue, 20 Aug 1996 20:49:48 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 20:49:48 -0400 (EDT) Date: Tue, 20 Aug 1996 18:49:27 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608210049.SAA25637@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"F-yjM3.0.RK3.aqb6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1894 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gurdeep Singh Pall > >---------- > Vernon Schryver writes: > > > >Perhaps that text should be reworded to respond more forcefully to the > >charge that Microsoft doesn't get it: > > > > - Contrary to that text, it is "possible to validate MD-5 derived > > credentials". Microsoft could easily and trivially use MD5 CHAP > > instead of MS CHAP, simply by using the MD4 (DES?) encryption of > > the user's password as the shared secret. The NT server could (as > > it does now) save the DES (MD4?) encrypted version of the Unicode > > password and use that as the secret for MD5 instead of DES (MD4?). > > gurdeep> Your comments above indicate your inability to comprehend plain > english - or that you dont have a clue (I'm leaning towards the latter). > I suggest you read my email ten times again to understand why your > suggestion above will not help interoperability (MD-5 hash of a MD-4 > hash of a password is NOT MD-5 hash of a password). In any case most > *progressive* vendors interested in supporting seamless dial-up > integration are implementing MS-CHAP (based on your responses I'm quite > sure SGI is not). That nonsense presumably intended to distract the discussion from the lack of strength or necessity of MS CHAP. Of course I know that an MD-5 hash of an MD-4 hash is not the same as an MD-5 hash. I stand by my claim Microsoft could trivial switch to using MD-5 CHAP from MS CHAP, simply by changing their client and server PPP software to use MD-5 to digest the challenge, and the same data they now have in the NT file. The state of Microsoft is more interesting than my cluelessness: - Do Microsoft and Gurdeep Singh Pall really not understand that MS CHAP has a fixed, clear text password, albeit something other than the Unicode string the user types? - if they do understand, why do they continue to imply otherwise? - what non-technical, business advtantages are there for Microsoft requiring a proprietary, poorly described protocol that has no technical advantages over the standard protocols? Thank you very much, but I'll decline to state whether Silicon Graphics will implement MS CHAP. I've worked on plenty of silly things before. In fact, I believe in using PPP far more seamlessly than is possible with what I understand of Microsoft products. I use PPP for all of my connections to the Internet and SGI's corporate network. However, I never type any PPP passwords. I usually just open a window to a remote system, and the right things happen underneath. Sometimes the remote system requires a username and password, as in "anonymous"/"vjs@sgi.com". Other systems require other authenticators. Some are set to not require any authenticator for most of the things I do from this keyboard. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 20:52:16 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA13868; Tue, 20 Aug 1996 20:52:16 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 20:52:16 -0400 (EDT) Date: Tue, 20 Aug 1996 18:52:01 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608210052.SAA25654@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Resent-Message-ID: <"Uij5H3.0.QO3.xsb6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/1895 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Brad Wilson" > ... > As I understand it, C2 certification requirements state that the users' > passwords cannot be kept in plain text on the box. Since NT chose to > implement PPP authentication against the user database, they could not What does C2 have to do with PPP or anything else we are talking about? Does Microsoft claim NT or Windows is C2 with PPP running? I thought that as most outfits do, when the computer is connected to a network, Microsoft says all bets on the offficial, certified security of the system are off. > ... > > - in effect, the MS CHAP PPP secret is cleartext. That the constant, > > cleartext MS CHAP secret is derived from some other password using > > MD4 or DES is irrelevant as far as PPP is concerned > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > Despite this being the PPP protocol, and this being the PPP working group, > Microsoft makes its decisions in the context of the entire operating > system, NOT just the PPP protocol. That's a good a to design a system of which PPP is a part, but completely irrelevant. We are talking about PPP and whether there is a cleartext password for MS CHAP. It is clear that if you look past the misunderstandings, there is a cleartext password for MS CHAP. Again, "cleartext" does not mean "ASCII or Unicode." "Cleartext" is simply the obverse of "cyphertext." In this context it is a secret written in the open. > > most people consider deriving one password or secret used for one > > purpose from some other password or secret used for some other > > purpose a serious security problem. > > Should I have a different password for each command I can issue in my > operating system? Exactly at what point do we say "enough is enough"? It > is perfectly reasonable, IMO, to have a single password which logs you onto > a remote system, whether that is via PPP or Ethernet, and allows you to > access that system. That is wrong. In many systems, it is necessary to provide different authenticators (passwords, MAC stuff, etc) to change a file than to view it. Connecting two networks (what PPP does) is far more different from starting a shell account than viewing is from changing a file. In most computer networks, the ability to inject packets into the network does not grant the ability to read or write files or run programs. Equating dialup and logon does exactly that. Worse, because many systems have mechanisms wherein the ability to run programs on one system grants the ability to the same on another system (rhosts is a common albeit bad example), such linking of access rights is a potential catastrophy. SHEESH! The U.S.Government security certifications I've see a little from afar require databases of many thousands of lines to describe the mandatory access rights (MAC). Has the government agreed that it is ok to require using the same password for dialup and logon?--that would be amazing. Or is have I heard correctly that C2 is out the window as soon as PPP is turned on? > > - Contrary to that text, it is "possible to validate MD-5 derived > > credentials". Microsoft could easily and trivially use MD5 CHAP > > instead of MS CHAP, simply by using the MD4 (DES?) encryption of > > the user's password as the shared secret. The NT server could (as > > it does now) save the DES (MD4?) encrypted version of the Unicode > > password and use that as the secret for MD5 instead of DES (MD4?). > > Except that all clients expect MD5 CHAP to be across a plain text password. > If MS started injected MD4 encrypted passwords with MD5 CHAP -- and this > is the important part -- WITHOUT A SEPARATE AUTHENTICATION TYPE SO THAT WE > KNEW AHEAD OF TIME -- you'd be screaming just as loudly. I guess that wrongness is based on the bogus notion that what the user of the PPP client types is necessarily the "password" used by MS CHAP or MD5 CHAP. In fact, the password used by MS CHAP is the hash of what the user types. That hash is the real password, because knowledge of it is sufficient to authenticate a PPP connection. Consider this alternate system based purely on MD5 CHAP (yes, if you've read my other messages, it will look familiar): 1. the operators of the PPP client and server talk on the telephone to choose an ordinary ASCII password such as "JimBob'sPC". 2. the operator of the server types "JimBob'sPC" into a server on the server, but only after having selected "Microsoft Version 8 Password Managenemt." The server tool hashes "JimBob'sPC" using all of MD5, MD4, RC4, RC2, DES, BLOWFISH, and rot13, and saves the result in the server's stable storage (e.g. disk or EEPROM). 3. Jim Bob then tests the connection by starting the Microsoft PPP tool, and types "JimBob'sPC" as his password. The client PPP tool hashes "JimBob'sPC" using all of MD5, MD4, RC4, DES, BLOWFISH, and rot13, and uses the resulting hash as the password or secret to respond to an MD5 CHAP challenge from the PPP server. 4. the server uses its saved hash from step #2 to validate the response, exactly as is now done with MS CHAP. 5. the client PPP tool then logs onto the server to open a shell, using the same or some other hash of "JimBob'sPC". That meets all of the technical goals described for MS CHAP, and does not extend or modify any PPP protocol. (The tools used by the server to track passwords, usernames, and so forth are outside of the scope of PPP standards.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 21:18:22 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA14832; Tue, 20 Aug 1996 21:18:22 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 21:18:22 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'vjs@mica.denver.sgi.com'" Subject: RE: Microsoft Authentication Date: Tue, 20 Aug 1996 18:16:49 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 21 TEXT Resent-Message-ID: <"16h8C3.0.Td3.QFc6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1896 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >---------- >From: vjs@mica.denver.sgi.com[SMTP:vjs@mica.denver.sgi.com] > > - Do Microsoft and Gurdeep Singh Pall really not understand that > MS CHAP has a fixed, clear text password, albeit something other > than the Unicode string the user types? gurdeep> NT Server does *not* store clear text passwords as part of the user account database. Since the password is stored in a MD-4, one way encrypted form, trying to decrypt it to rehash the clear text with MD-5 for standard, interoperable, CHAP is not an option. Using the MD-4 hash as the seed for MD-5 is also not an interoperable option. Vern, if you want me to repeat this again (and again) please let me know OFFLINE. More intelligent people on this list are probably getting sick of seeing the same explanation over and over. > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 21:37:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA15516; Tue, 20 Aug 1996 21:37:29 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 21:37:29 -0400 (EDT) Date: Tue, 20 Aug 1996 19:35:15 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608210135.TAA25765@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: chapexts.txt? Resent-Message-ID: <"dKiYb3.0.Ao3.MXc6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1897 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Is ftp.sgi.com:developr/rfc/chapexts.txt accessible to non-SGI folks? > It sure doesn't work for me as a URL, and I couldn't find it in a few > minutes of poking around on ftp.sgi.com. > > Thanks for any help you can provide, RATS! A little while ago I caught my over-trained fingers typing "ftp.sgi..." instead of "ftp.something.else..." and wondered if I had the same mistake when I mentioned the Microsoft description of MS CHAP in the PPP mailing list. Of course, there is no copy of Microsoft's MS CHAP description on ftp.sgi.com. It is in ftp.microsoft.com:developr/rfc/chapexts.txt ^^^^^^^^^ I'm sorry about that. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 22:19:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA16480; Tue, 20 Aug 1996 22:19:33 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 22:19:33 -0400 (EDT) Date: Tue, 20 Aug 1996 20:19:14 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608210219.UAA25972@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"1O6Z_2.0.D14.k8d6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1898 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gurdeep Singh Pall > >---------- > >From: vjs@mica.denver.sgi.com[SMTP:vjs@mica.denver.sgi.com] > > > > > - Do Microsoft and Gurdeep Singh Pall really not understand that > > MS CHAP has a fixed, clear text password, albeit something other > > than the Unicode string the user types? > > gurdeep> NT Server does *not* store clear text passwords as part of the > user account database. Since the password is stored in a MD-4, one way > encrypted form, trying to decrypt it to rehash the clear text with MD-5 > for standard, interoperable, CHAP is not an option. Using the MD-4 hash > as the seed for MD-5 is also not an interoperable option. Vern, if you > want me to repeat this again (and again) please let me know OFFLINE. > More intelligent people on this list are probably getting sick of seeing > the same explanation over and over. If I were wrong about any of this, instead of calling me stupid and clueless and repeating his assertions without technical explanation, Mr. Pall would offer a technical explanation of why possession of the "MD-4, one way encrypted form" is not sufficient for a bad guy to break into an NT server. I wonder about the motives of Mr. Pall's repeated personal attacks. Why try so hard to distract attention from the nature of MS CHAP and squelch discussion of it? I hope Mr. Pall realizes that not only do many more people read this mailing list than ever speak, but that it is archived in a public place, and that people often search it. I cannot let Mr. Pall's incorrect claims about the security of MS CHAP go unchallenged. Microsoft's NT does have a cleartext PPP password, with all of the security problems that implies, which of course are no worse than the security problems of MD5 CHAP (modulo the special cryptographic problems of MS CHAP that Karl Fox mentioned). Again, the word "cleartext" is not a synonym for ASCII or Unicode. That "stored in a MD-4, one way encrypted form" that Mr. Pall mentions is itself a cleartext password. That the cleartext password was derived from a Unicode string using MD-4 is absolutely and completely irrelevant. It is a cleartext password because of the powers it gives those who know it. A system that knows that string, even if it does not know the original Unicode string, can start a PPP session with MS CHAP. That power is sufficient to make that string a cleartext password. Again, for the zillionth time, there would be absolutely no reason for any PPP server, including NT, to decrypt anything in order to use MD5 CHAP instead of MS CHAP with that MD4 cleartext password. There would obviously be absolutely no interoperability problems. Simply do this: PPP client PPP server computes the "MD-4, one way encrypted form" of the string from the user, just like today sends MD5 CHAP challenge to client compute and send MD5 CHAP response using "MD-4, one way encrypted form" and MD5 CHAP challenge validates MD5 CHAP response using stored "MD-4, one way encrypted form" and MD5 CHAP challenge value The only possible interoperability problems would be minor, purely Microsoft NT problems. It might be necessary for Microsoft to modify NT to optionally use the MD4 hash of the user's Unicode string when using MD5 CHAP depending on the peer's username, instead of whatever NT now does when using MD5 CHAP. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 22:32:13 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA16843; Tue, 20 Aug 1996 22:32:13 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 22:32:13 -0400 (EDT) Message-Id: <199608210233.WAA04465@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: Microsoft Authentication Date: Tue, 20 Aug 1996 22:32:01 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"VDmH_.0.r64.fKd6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1899 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon says... > That nonsense presumably intended to distract the discussion from the > lack of strength or necessity of MS CHAP. Of course I know that an > MD-5 hash of an MD-4 hash is not the same as an MD-5 hash. I stand by > my claim Microsoft could trivial switch to using MD-5 CHAP from MS > CHAP, simply by changing their client and server PPP software to use > MD-5 to digest the challenge, and the same data they now have in the NT > file. As you have stated, CHAP in general has a shared secret. In MD5 CHAP, you hash this shared secret (presumably, for most people, a password) with the given, random challenge and the net result is sent back to the other side to be validated. This presumes that the shared secret on both sides is known and easily accessible (eg, stored on long term storage, or typed by a user). In MS CHAP, the same thing happens, with ONE KEY DIFFERENCE: the shared secret is first run through one of DES or MD4 (depending on whether it's LM or NT style passwords). The reason for this is very, very simple: the only form of the shared secret available is ALREADY HASHED. Users want to remember their passwords. Under NT or LM, they do NOT know their MD4/DES encryption of their secret, nor should they want to. This differs from standard MD5 CHAP (put aside the additional functionality of MS CHAP for a moment) in a significant enough manner that it warrants a new type of authentication. There was question of 0 padded passwords under DES (the old Lan Manager style), but take note that that password style is deprecated for their newer software. There was also question of the strength of MD4; again, take note that the hash that goes over the wire is an MD5 hash of the MD4 hash of the password. > - Do Microsoft and Gurdeep Singh Pall really not understand that > MS CHAP has a fixed, clear text password, albeit something other > than the Unicode string the user types? Of course there is a fixed, clear text password. There is ALWAYS a fixed, clear text password ... it's what both sides have agreed upon. There is a difference, however, in the hash function(s) used before transmitting the data. > - what non-technical, business advtantages are there for Microsoft > requiring a proprietary, poorly described protocol that has no > technical advantages over the standard protocols? Quite simply, they want to store the passwords on the disk in a non-plain text form (in the MD4 or the DES hash form) for C2 Security. Is that enough of a reason for you, or are you intending to second guess a company's marketing needs? One way or another, its ALREADY DONE and been in use for more than a year already, with many, many clients and servers in the field already. Wishing it were done differently isn't going to change that. > In fact, I believe in using PPP far more seamlessly than is possible > with what I understand of Microsoft products. I use PPP for all of my > connections to the Internet and SGI's corporate network. However, I > never type any PPP passwords. Thank you. You must have, on your system then, the plain text shared secrets used to authenticate your PPP connection. How is this BETTER than what Microsoft does (storing DES/MD4 shared secrets)? -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 22:50:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA17309; Tue, 20 Aug 1996 22:50:36 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 22:50:36 -0400 (EDT) Message-Id: <199608210252.WAA04914@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: Unidentified subject! Date: Tue, 20 Aug 1996 22:50:31 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lDZ0f3.0.BE4.ubd6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1900 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon says... > That's a good a to design a system of which PPP is a part, but > completely irrelevant. We are talking about PPP and whether there is a > cleartext password for MS CHAP. It is clear that if you look past the > misunderstandings, there is a cleartext password for MS CHAP. I think I finally understand what you're driving at. Microsoft is NOT claiming that MS CHAP is any more secure than MD5 CHAP (well, if they are, I haven't heard it, and they'd be wrong). They're merely stating that their passwords are committed to long term storage as a hash with MD4, not as plain text. Thus, to utilize a CHAP-like mechanism, a new authentication protocol was required. > That hash is the real password, because knowledge of > it is sufficient to authenticate a PPP connection. Of course, the hash is the 'real' shared secret, even though the user thinks the shared secret is the password (s)he typed. However, the knowledge of hashed shared secret is not possible without knowledge of the secret that was used to generate it, so what's the difference to you? MS stores their passwords encrypted -- smart idea -- and out of the users hands -- another smart idea -- and decided to add an authentication mechanism to allow them to leverage it without forcing the user to use PAP (presumably we agree that an MD5 hash of an MD4 hash is better than the users plain text password on the net). Storing the passwords as MD4 hash instead of plain text is a good idea (requirement?) for C2 security. Yes, network access invalidates C2 security status, but that doesn't change their desire to achieve it when network access is not available. So, we have an NT box with MD4 passwords. Now what? We need PPP. Do we provide a separate list of plain text PPP authenticators, or do we simply use the user accounts (checking, of course, a users designated ability to dial in before allowing them to) that already exist? See, now it's a marketing decision, and a GOOD ONE (IMO). Extraordinarily broken Unix security mechanisms are no good reason to require a user to have two passwords (eg, your rlogin sample). > That meets all of the technical goals described for MS CHAP, and does > not extend or modify any PPP protocol. (The tools used by the server > to track passwords, usernames, and so forth are outside of the scope of > PPP standards.) How does an NT server, then, differentiate between each client's type of authentication used 1. I dial with WFW311, which uses DES style hashing 2. I dial with Win95, which uses MD4 style hashing 3. I dial with Linux, which uses no hashing if all of the clients request MD5 CHAP? Your statement that "tools used by the server to track passwords...are outside the scope of PPP standards" is obviously problematically incorrect here. How do I, without 3 different protocol types, tell if the system can do what I want? The obvious flaw is that MD5 CHAP negotiation does not allow you to agree ahead of time if there will be an additional hash function that takes place before the MD5 hash. Now presume an SGI server with those three clients. What will -it- do, if it doesn't support all 3? Isn't that what the whole 'negotiation' mechanism of PPP is designed for? You want to eliminate MS CHAP, which provides this exact negotiation mechanism, for reasons unstated (exactly why are you fighting so hard against something that is already done and deployed in 8 digit numbers of machines?). -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 20 22:58:05 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA17655; Tue, 20 Aug 1996 22:58:05 -0400 (EDT) Resent-Date: Tue, 20 Aug 1996 22:58:05 -0400 (EDT) Message-Id: <199608210259.WAA05087@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: Microsoft Authentication Date: Tue, 20 Aug 1996 22:57:43 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8zwOq2.0.bJ4.vid6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1901 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon says... > Mr. Pall would offer a technical explanation of why possession of the > "MD-4, one way encrypted form" is not sufficient for a bad guy to break > into an NT server. For the last time, Vernon, in capital letters, here it is: POSESSION OF THE ONE WAY MD4 HASH PASSWORD IS SUFFICIENT FOR A BAD GUY TO GET ACCESS TO THE MACHINE. A BAD GUY CANNOT GET THAT HASH WITHOUT HAVING THE PASSWORD THAT ORIGINATED IT, BECAUSE THE LIST OF PASSWORDS IS NOT ACCESSIBLE TO ANYBODY BUT THE SYSTEM ADMINISTRATOR AND REQUIRES PHYSICAL ACCESS TO THE MACHINE (which is even solved if you follow the rest of the C2 security guidelines), AND THAT PASSWORD IS NEVER SENT OUT ON THE WIRE IN THE CLEAR. Does that make it more clear to you? > I hope Mr. Pall realizes that not only do many more people read this > mailing list than ever speak, but that it is archived in a public > place, and that people often search it. Now this is just silly. Of what purpose is this veiled threat? -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 00:36:26 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA19479; Wed, 21 Aug 1996 00:36:26 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 00:36:26 -0400 (EDT) Date: Tue, 20 Aug 1996 22:34:47 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608210434.WAA26370@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"sSq-W2.0.1m4.39f6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1902 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've had an ugly thought. Is there an NT tool that lets ordinary users look at the NT PPP database, so that ordinary users can view the MD4 hashes? Something equivalent to `cat /etc/passwd` in old UNIX systems before shadow passwords? If there were such a tool, then NT PPP would have absolutely no security. More, if I've read the Microsoft document right, a bad guy could use the MD4 hashes from the file to change both the dialup and logon password, which would mean that NT with PPP would have absolutely no security even for user sessions. Note that I'm not asking about the ever popular attacks that bad guys use to read supposedly secret files. > From: "Brad Wilson" > > Mr. Pall would offer a technical explanation of why possession of the > > "MD-4, one way encrypted form" is not sufficient for a bad guy to break > > into an NT server. > > For the last time, Vernon, in capital letters, here it is: > > POSESSION OF THE ONE WAY MD4 HASH PASSWORD IS SUFFICIENT FOR A BAD GUY TO > GET ACCESS TO THE MACHINE. A BAD GUY CANNOT GET THAT HASH WITHOUT HAVING > THE PASSWORD THAT ORIGINATED IT, BECAUSE THE LIST OF PASSWORDS IS NOT > ACCESSIBLE TO ANYBODY BUT THE SYSTEM ADMINISTRATOR AND REQUIRES PHYSICAL > ACCESS TO THE MACHINE (which is even solved if you follow the rest of the > C2 security guidelines), AND THAT PASSWORD IS NEVER SENT OUT ON THE WIRE IN > THE CLEAR. Exactly the same words apply to any reasonable system using MD5 CHAP. > ... > > I hope Mr. Pall realizes that not only do many more people read this > > mailing list than ever speak, but that it is archived in a public > > place, and that people often search it. > > Now this is just silly. Of what purpose is this veiled threat? What could possibly be threatening about a statement of fact? It seemed to me that Mr. Pall got carried away in his efforts to silence me and had forgotten how publically he was speaking. ] From: "Brad Wilson" ] Microsoft is NOT claiming that MS CHAP is any more secure than MD5 CHAP ] (well, if they are, I haven't heard it, and they'd be wrong). They're ] merely stating that their passwords are committed to long term storage as a ] hash with MD4, not as plain text. Thus, to utilize a CHAP-like mechanism, ] a new authentication protocol was required. Not so! The nonsense MD5 CHAP would not be secure using the MD4 or DES hash is not good enough to require a new protocol. MD5 CHAP works just fine. There are obvious marketing reasons that have nothing to do with technical goals for requiring a proprietary protocol. Did MS CHAP delay the products of any of Microsoft's competators? ] ... ] Of course, the hash is the 'real' shared secret, even though the user ] thinks the shared secret is the password (s)he typed. However, the ] knowledge of hashed shared secret is not possible without knowledge of the ] secret that was used to generate it, so what's the difference to you? On the contrary, knowledge of the real shared MS CHAP secret is possible to any bad guy that manages to read the NT file. That is exactly the same thing as with MD5 CHAP. Or do you think that any reasonable system puts MD5 CHAP secrets where they are easy to read? ] MS ] stores their passwords encrypted -- smart idea -- and out of the users ] hands -- another smart idea Oh, would that were true! The history of operating system security has more than enough examples for why no one says putting a secret in a file not available to ordinary users is enough to keep it secret. Many used supposedly secret files for authentication and were proven vulnerable before UNIX appeared with its mechanism. If you say that NT is the first operating system in history that is invulnerable, then you'd be invalidating the reason for MS CHAP. If you say that unforeseen things happen, and that bad guys might get the contents of the file, then you'd be invalidating the reason for MS CHAP. ] ... ] Storing the passwords as MD4 hash instead of plain text is a good idea ] (requirement?) for C2 security. Yes, that's the famous UNIX scheme for user authentication. It works because the DES hash is not a secret. `cat /etc/passwd` used to display all of the DES hashes. The secret is the original ASCII string. The server never knows the secret, and so cannot be tricked into divulging it. This is competely different from MS CHAP and MD5 CHAP. Both MS CHAP and MD5 CHAP rely on cleartext passwords kept in files that one hopes ordinary users and bad guys cannot read. Using the old UNIX system for logon security is a good idea. It has nothing to do with PPP, except in PAP. ] Yes, network access invalidates C2 ] security status, but that doesn't change their desire to achieve it when ] network access is not available. So, we have an NT box with MD4 passwords. ] Now what? We need PPP. Do we provide a separate list of plain text PPP ] authenticators, or do we simply use the user accounts (checking, of course, ] a users designated ability to dial in before allowing them to) that already ] exist? See, now it's a marketing decision, and a GOOD ONE (IMO). Not so! They are using the MD4 hashes for MS CHAP shared secrets. They could just as easily used the MD4 hashes for MD5 CHAP shared secrets. There was no reason except a mistake or marketing for a new protocol. ] > That meets all of the technical goals described for MS CHAP, and does ] > not extend or modify any PPP protocol. (The tools used by the server ] > to track passwords, usernames, and so forth are outside of the scope of ] > PPP standards.) ] ] How does an NT server, then, differentiate between each client's type of ] authentication used ] ] 1. I dial with WFW311, which uses DES style hashing ] 2. I dial with Win95, which uses MD4 style hashing ] 3. I dial with Linux, which uses no hashing The only differences would be in how you initially configure the MD5 CHAP shared secret. At run time, the server thinks they are all the same. Yes, WFW311 and Win95 could not use a simple text editor to capture the shared secret. You'd need a tool that would compute the DES or MD4 hash of what the remote user mistakenly thinks is the password. That must be how NT works now, with a tool that takes the Unicode password, computes the MD4 or DES hash and puts the result into the NT file. Yes, you'd have to tell the tool "WFW311", "Win95", or "Classic". That is not a CHAP protocol issue, but just a user interface detail explicitly outside the CHAP protocol. ] if all of the clients request MD5 CHAP? Your statement that "tools used by ] the server to track passwords...are outside the scope of PPP standards" is ] obviously problematically incorrect here. How do I, without 3 different ] protocol types, tell if the system can do what I want? The obvious flaw is ] that MD5 CHAP negotiation does not allow you to agree ahead of time if ] there will be an additional hash function that takes place before the MD5 ] hash. That is wrong. The server would use MD5 CHAP identically regardless of the flavor of the client. ] Now presume an SGI server with those three clients. What will -it- do, if ] it doesn't support all 3? Isn't that what the whole 'negotiation' ] mechanism of PPP is designed for? No new negotiating is required. At run time, all 3 clients look the same. ] You want to eliminate MS CHAP, which provides this exact negotiation ] mechanism, for reasons unstated (exactly why are you fighting so hard ] against something that is already done and deployed in 8 digit numbers of ] machines?). I am not trying to eliminate MS CHAP. I am trying to eliminate nonsense that it is somehow necessary or more secure than MD5 CHAP. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 01:07:26 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id BAA20142; Wed, 21 Aug 1996 01:07:26 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 01:07:26 -0400 (EDT) Message-Id: <199608210508.BAA08186@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: Microsoft Authentication Date: Wed, 21 Aug 1996 01:07:25 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AdRx_.0.Sw4.Acf6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1903 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I've had an ugly thought. Is there an NT tool that lets ordinary users > look at the NT PPP database, so that ordinary users can view the MD4 > hashes? Something equivalent to `cat /etc/passwd` in old UNIX systems > before shadow passwords? If there were such a tool, then NT PPP would > have absolutely no security. Of course there is no such tool for 'ordinary users'. SysAdmins, with lots of poking and proding and security changes, could discover this information. Ordinary users, no way. > There are obvious marketing reasons that have nothing to do with > technical goals for requiring a proprietary protocol. Did MS CHAP > delay the products of any of Microsoft's competators? Stop making baseless accusations. Your value to this discussion dimishes every round. > If you say that NT is the first operating system in history that > is invulnerable, then you'd be invalidating the reason for MS CHAP. I said no such thing. I am stating that MS CHAP is no LESS secure than MD5 CHAP. > Both MS CHAP and MD5 CHAP rely on cleartext passwords kept in > files that one hopes ordinary users and bad guys cannot read. Could this be the first valid point you've made today? [ Rest of misunderstandings, re-re-re-re-repeated, deleted] > I am not trying to eliminate MS CHAP. I am trying to eliminate > nonsense that it is somehow necessary or more secure than MD5 CHAP. Nobody said it's more secure. But it EXISTS so arguments of it's usefullness or necessity are moot, since systems that use it (read: as many as 75 million) are ALREADY deployed. -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 05:00:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA23332; Wed, 21 Aug 1996 05:00:17 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 05:00:17 -0400 (EDT) Message-ID: <321ACE3A.2B4F@vbo.dec.com> Date: Wed, 21 Aug 1996 10:52:10 +0200 From: Vincent Berger Organization: Digital Equipment Corporation X-Mailer: Mozilla 2.02I (WinNT; I) MIME-Version: 1.0 To: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication References: <199608210434.WAA26370@mica.denver.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"AGATl3.0.Bi5.R0j6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1904 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Wow, it's getting hot in here! My mailbox was pretty full this morning ;-) (I'm in Europe). Vernon Schryver wrote: > > The only differences would be in how you initially configure the MD5 > CHAP shared secret. At run time, the server thinks they are all the > same. > > Yes, WFW311 and Win95 could not use a simple text editor to capture the > shared secret. You'd need a tool that would compute the DES or MD4 > hash of what the remote user mistakenly thinks is the password. That > must be how NT works now, with a tool that takes the Unicode password, > computes the MD4 or DES hash and puts the result into the NT file. > Yes, you'd have to tell the tool "WFW311", "Win95", or "Classic". That > is not a CHAP protocol issue, but just a user interface detail explicitly > outside the CHAP protocol. > You'd also have to change the "client" so that it knows what to do with the human-entered secret: pre-hash it with MD4 to talk to an NT box, or not pre-hash it to talk to anything else. Or you'd have to require the human to type the MD4 hashed secret which is even worse. In any case, you'd have to have the human know what the box is on the other side. Do most ISPs tell you which hardware they're using ? (I don't think many use NT but who knows ?) That's what PPP negotiation is for, and I guess that's why there is a separate CHAP option to talk to an NT box. Now I don't like this whole MS-CHAP story either. I especially don't like how poorly documented it is with a file hidden on ftp.microsoft.com, I'd much prefer to have it as an informational RFC with the IETF, but that's beyond the technical point. Technically, I think it's there for a real reason and is not worse than anything else. My 2c worth Vincent -- Vincent BERGER E-Mail: berger@vbo.dec.com Digital Equipment Corporation, OSSG-Europe Fax: (+33) 92956235 Principal Software Engineer - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 09:04:08 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA27375; Wed, 21 Aug 1996 09:04:08 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 09:04:08 -0400 (EDT) Message-Id: <27316.9608211302@vulcan.xylogics.com> To: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication In-Reply-To: Your message of "Wed, 21 Aug 1996 10:52:10 +0200." <321ACE3A.2B4F@vbo.dec.com> Date: Wed, 21 Aug 1996 09:02:47 -0400 From: James Carlson Resent-Message-ID: <"0ImJL.0.Fh6.Wam6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1905 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vincent Berger wrote: [...] > You'd also have to change the "client" so that it knows what to do with the > human-entered secret: pre-hash it with MD4 to talk to an NT box, or not > pre-hash it to talk to anything else. Or you'd have to require the human to > type the MD4 hashed secret which is even worse. In any case, you'd have to > have the human know what the box is on the other side. Do most ISPs tell > you which hardware they're using ? (I don't think many use NT but who knows > ?) > That's what PPP negotiation is for, and I guess that's why there is a > separate CHAP option to talk to an NT box. Instead of inventing a new protocol to do *precisely* the same thing that regular CHAP does (modulo some marketing-related hysteria), why not simply define a well-known extension to the regular CHAP protocol? For example, one could send a user name of "joe+MD4" with the response to say to the peer "I ran MD4 digest to generate my shared secret before doing the MD5 hash. I though you'd like to know." This would be a rather trivial extension instead of having to add yet another authentication protocol. We could even extend this to encode the silly MP "endpoint discriminator." (Opps! I didn't say that!) > Now I don't like this whole MS-CHAP story either. I especially don't like > how poorly documented it is with a file hidden on ftp.microsoft.com, I'd > much prefer to have it as an informational RFC with the IETF, but that's > beyond the technical point. Technically, I think it's there for a real > reason and is not worse than anything else. No kidding. Had they done this in the open, they'd be able to draw on the experience and insight of the community to design something simpler and more effective. RFC 1877, another of my favorites, suffers from this same disease. There are good reasons to work within this system, even if you think you know everything. --- James Carlson Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 09:30:58 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA28101; Wed, 21 Aug 1996 09:30:58 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 09:30:58 -0400 (EDT) Message-Id: <199608211332.JAA20080@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: Microsoft Authentication Date: Wed, 21 Aug 1996 09:31:06 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Mk4K_.0.es6.C-m6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1906 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Instead of inventing a new protocol to do *precisely* the same thing that > regular CHAP does (modulo some marketing-related hysteria), why not simply > define a well-known extension to the regular CHAP protocol? Agreed. > No kidding. Had they done this in the open, they'd be able to draw on > the experience and insight of the community to design something simpler > and more effective. Uh, this -did- let everyone know about this when they were doing it. It's old news and old arguments that are being rehashed. They published the documents and told everyone who was interested to go take a look. It wouldn't be too difficult to pushlish them as informational RFCs, but nobody has stepped up to the plate to either say that is MUST be done, or that THEY will do it. -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 12:30:17 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA06419; Wed, 21 Aug 1996 12:30:17 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 12:30:17 -0400 (EDT) Message-ID: From: Glen Zorn To: "'Jonathan.Goodchild@rdl.co.uk'" , "'Larry J. Blunk'" Cc: "'ietf-ppp@MERIT.EDU'" Subject: RE: Microsoft Authentication Date: Wed, 21 Aug 1996 09:10:24 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 57 TEXT Resent-Message-ID: <"WlWgo1.0.bZ1.Gcp6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1907 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Larry J. Blunk (ljb@merit.edu) writes: > >> >> In the Microsoft technet article PSS ID Number Q136634 (09-18-1995), >>PSS >> >> database name: CROSSNET it states that: >> >> "The Windows NT RAS server does not support RSA MD5 because this >> method requires a clear-text password at the server" >> >> I don't follow this at all. Why is this a reason for not implementing >> standard MD5 CHAP, and can anyone enlighten me on how this differs >>from >> MS-CHAP (RSA MD4) ? > > It's because Microsoft is clueless. It may be true that Microsoft is clueless; if so, it's nice of you to demonstrate that we're not alone (see below ;-) >MD5 CHAP does not request you >keep a "clear-text password". It requires that there is a "shared >secret". RFC 1334 does not mandate how this "shared secret" is >stored/generated contrary to Microsoft's assertion. MS-CHAP still >requires a shared secret, just as MD5 CHAP does. MS-CHAP specifies >that the secret is generated by running a one-way has on a password >entered by the user (and storing the hashed value). When the >user enters their password at authentication time, the hash is again >generated and used as the shared secret. This same mechanism could >have been used with MD5 CHAP. While most MD5 CHAP implementations >will use the user's password directly as the secret, the procotol spec >in no way prohibits you from using a hash function on the password to get the >secret. It's just a matter of semantics and didn't require a new >protocol specification. The distinction is that it requires NAS >vendors to modify their PPP implementation to support MS-CHAP. Whereas, >if Microsoft had used MD5 CHAP, all that would have been required is >a change to the secret storage/generation (i.e., on the RADIUS server, >if the NAS can use RADIUS). Your analysis is correct, as far as it goes. The shared secret _could_ be defined to be the MD4 hash of the user's password, which is the same value stored in the NT user database (or the crypt(3)ed unix password - it works the same way). All that would be required is that every RADIUS server (and NAS and...) that stores passwords in plaintext check N ways, one for every form of encryption used. The method is secure on the wire. Suppose, though, that an attacker obtains a copy of the usernames and encrypted passwords (e.g., /etc/passwd). At this point, the adversary doesn't even have to guess passwords -- all (s)he needs is an MD5 function and the right challenge to be able to log in as _anyone_. I suggest that opening such a glaring hole in PPP authentication might be suboptimal. > > -Larry Blunk > Merit -- gwz - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 13:11:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA08387; Wed, 21 Aug 1996 13:11:59 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 13:11:59 -0400 (EDT) Message-Id: <199608211713.NAA25327@router.thebrads.com> From: "Brad Wilson" To: "'ietf-ppp@MERIT.EDU'" Subject: Re: Microsoft Authentication Date: Wed, 21 Aug 1996 13:11:45 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"lY70H3.0.j22.QDq6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1908 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > The method is secure on the > wire. Suppose, though, that an attacker obtains a copy of the usernames > and encrypted passwords (e.g., /etc/passwd). At this point, the > adversary doesn't even have to guess passwords -- all (s)he needs is an > MD5 function and the right challenge to be able to log in as _anyone_. Getting the MD4 hash of the password is just as simple as getting the plain text version that is stored on the NAS. You can't do it, unless you're the sysadmin, if the server is properly administered (and yes, by default, the NT box's security is correct, and will NOT let ANYONE but the sysadmin get the MD4 hash of the password; even then, its a laborous process of unsetting registry security and trying to locate the thing). -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 15:28:27 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA12944; Wed, 21 Aug 1996 15:28:27 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 15:28:27 -0400 (EDT) Date: Wed, 21 Aug 1996 13:27:47 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608211927.NAA27777@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication Resent-Message-ID: <"OOvdk.0.-93.EDs6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1909 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Vincent Berger > ... > > The only differences would be in how you initially configure the MD5 > > CHAP shared secret. At run time, the server thinks they are all the > > same. > > > > Yes, WFW311 and Win95 could not use a simple text editor to capture the > > shared secret. You'd need a tool that would compute the DES or MD4 > > hash of what the remote user mistakenly thinks is the password. ... > You'd also have to change the "client" so that it knows what to do with the > human-entered secret: pre-hash it with MD4 to talk to an NT box, or not > pre-hash it to talk to anything else. Or you'd have to require the human to > type the MD4 hashed secret which is even worse. In any case, you'd have to > have the human know what the box is on the other side. Do most ISPs tell > you which hardware they're using ? (I don't think many use NT but who knows > ?) Why would typing the MD4 hashed secret be so terrible? It would be the same as typing any other 20-character password. It's a little long, but not exceptionally. Look at PGP. Today, isn't the operator of the client PC required to know that the ISP is using NT and so configure MS CHAP? Do PC PPP client implemenations use a single password with whatever authentication protocol the server asks, including PAP? (That would be an eggregious security hole that would demand a CERT bulletin.) Is it really possible that some users of PC's could get shells on their ISP's systems using their PPP password? And someone thinks that is desirable? If no one is using NT at an ISP or the private corporate equivalents, then what is the talk about "75 million" systems with MS CHAP? The only justification offered for MS CHAP has been "NT servers need it." > That's what PPP negotiation is for, and I guess that's why there is a > separate CHAP option to talk to an NT box. Not so. The chatting that happens between the computers need not be the same as the chatting between humans. You do have some kind of GUI for configuring PPP, right? The user just types a password into a box on the screen, right? So let the user type "JimBob'sPC," but store the MD4 hash that is the real shared secret in your client's configuration file. It would be a good idea to do that even when Microsoft products are kept far away, since the MD4 or DES hash of most users' passwords is likely to be a far better MD5 CHAP shared secret than the original password. (Genuine "seamless" use of PPP requires that the shared secret be kept on the disk of the client as well as the server, since otherwise you cannot do demand dialing or bandwidth on demand.) > Now I don't like this whole MS-CHAP story either. I especially don't like > how poorly documented it is with a file hidden on ftp.microsoft.com, I'd > much prefer to have it as an informational RFC with the IETF, but that's > beyond the technical point. Technically, I think it's there for a real > reason and is not worse than anything else. I don't see the real <> reason for the existence MS CHAP. While marketing considerations cannot be ruled out, my guess is that at least some people within Microsoft simply did not and do not understand that the MD4 or DES hash is a cleartext password and that MD5 CHAP would have worked just as well. Without attributing malice to the continuing Microsoft claims about the MD4 and DES hashes and supposed interoperability problems, I see no alternative but fundamental misunderstandings of CHAP and security. As for marketing considerations being "baseless accussations," well, anyone who really thinks that should talk to competant business people, look at the history of patents in business (e.g. firearms in the 19th century or compression in PPP), or what Microsoft and Netscape are saying the other is doing is doing now in the WWW browser and server industries. ] From: "Brad Wilson" ] ... ] > No kidding. Had they done this in the open, they'd be able to draw on ] > the experience and insight of the community to design something simpler ] > and more effective. ] ] Uh, this -did- let everyone know about this when they were doing it. No, as I recall, they presented it only after the fact. ] It's ] old news and old arguments that are being rehashed. It was not until this week that I realized how lame MS CHAP is, that they could have used MD5 CHAP to meet their avowed technical goals. If the arguments are so old, why has it take so many repetitions to convince you that MD5 CHAP would have done exactly as well (modulo perhaps having to type an MD4 hash in addition to a Unicode password) and that the MD4 hash is the real password? Or do you believe that Microsoft understands that MD5 CHAP could have been used just as well as MS CHAP, and if so, how do you explain MS CHAP? The argument over the wisdom of using the same password for PPP and shells is old. The implausible statements that has something to do with C2 are new. ] They published the ] documents and told everyone who was interested to go take a look. It ] wouldn't be too difficult to pushlish them as informational RFCs, but ] nobody has stepped up to the plate to either say that is MUST be done, or ] that THEY will do it. Is there any reason that it "MUST be done"? I think it is self-defeating for Microsoft to not publish now, when their competators understand and only their allies are delayed, but I don't work for Microsoft. As for statements that Microsoft does not bogusly claim that MS CHAP is more secure than MD5 CHAP, read the following: [ From: Glen Zorn [ ... [ Your analysis is correct, as far as it goes. The shared secret _could_ [ be defined to be the MD4 hash of the user's password, which is the same [ value stored in the NT user database (or the crypt(3)ed unix password - [ it works the same way). All that would be required is that every RADIUS [ server (and NAS and...) that stores passwords in plaintext check N ways, [ one for every form of encryption used. The method is secure on the [ wire. Suppose, though, that an attacker obtains a copy of the usernames [ and encrypted passwords (e.g., /etc/passwd). At this point, the [ adversary doesn't even have to guess passwords -- all (s)he needs is an [ MD5 function and the right challenge to be able to log in as _anyone_. [ I suggest that opening such a glaring hole in PPP authentication might [ be suboptimal. Once again, for the umptyzillionth time, MS CHAP has exactly that "glaring hole" and is just as "suboptimal" as MD5 CHAP. That Microsoft does not want to admit that the MD4 hash is the MS CHAP shared secret does not change the fact that the MD4 hash <> the shared secret. MS CHAP does involve storing the real password as plaintext, and the fact the plaintext password happens to be the MD4 or DES hash of some other string is irrelevant. An attacker that "obtains a copy of the usernames and encrypted passwords" stored in the NT server can "log in as _anyone_", albeit getting network connectivity and not a shell. Of course, it is also wrong to say some alternative would require "that every RADIUS server (and NAS and...) that stores passwords in plaintext check N ways". Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 16:10:30 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA14800; Wed, 21 Aug 1996 16:10:30 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 16:10:30 -0400 (EDT) Message-Id: <199608212012.QAA29573@router.thebrads.com> From: "Brad Wilson" To: Subject: MS CHAP, for the last time (I hope) Date: Wed, 21 Aug 1996 16:10:20 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"smjyk1.0.yc3.lqs6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1910 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Here are the facts, for the last time: o MD5 CHAP takes the shared secret, then hashes with MD5 against that. o MS CHAP takes the shared secret, hashes with MD4/DES, then hashes that result with MD5. These two actions are different, given the MD4/DES hash in the middle. Standard MD5 CHAP did -not- give the computers a way to negotiate the types of 'in between' hashing -- whether that be MD4, DES, or none -- and that was the problem that MS CHAP solved. Not all clients need be required to do all encryption methods; that's the fundamental reason for NEGOTIATION. (Take note that PAP is still permissible, if the server is configured to allow PAP authentication, since the plain shared secret can then be DES/MD4 hashed and compared against the NT registry). I whole heartedly agree that a new style of MD5 CHAP, where the type of intermediate hash used, is a much better idea. That's still not out of the question, IMO, but probably a very late suggestion (I did make the suggestion to one of the Microsoft guys at the PPPathon at Microsoft in April of 94; it was dropped somewhere; where, I don't know). I would be willing to write the draft, if desired. On another note, Vernon, you have admitted that you didn't give this any thought when the issue was presented originally; why do you make so much noise now, fully 2 1/2 years later, when the horse is out of proverbial barn? Must we discuss this into the ground -- again -- because you NOW finally got around to reading the draft? -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 16:12:56 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA14985; Wed, 21 Aug 1996 16:12:56 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 16:12:56 -0400 (EDT) Message-ID: <01BB8F7B.854EBD60@arl78235.inhouse.compuserve.com> From: Alan Pitts To: "ietf-ppp@MERIT.EDU" , "'Vernon Schryver'" Subject: RE: Microsoft Authentication Date: Wed, 21 Aug 1996 16:12:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resent-Message-ID: <"M_MUQ2.0.tf3.4ts6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1911 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Would it be acceptable to drop this thread for now and move on to = something else. Wasn't there some discussion of flow-control? Was that = ever concluded ??? -Alan ---------- From: Vernon Schryver[SMTP:vjs@mica.denver.sgi.com] Sent: Wednesday, August 21, 1996 3:27 PM To: ietf-ppp@MERIT.EDU Subject: Re: Microsoft Authentication > Vincent Berger > ... > > The only differences would be in how you initially configure the MD5 > > CHAP shared secret. At run time, the server thinks they are all the > > same. > >=20 > > Yes, WFW311 and Win95 could not use a simple text editor to capture = the > > shared secret. You'd need a tool that would compute the DES or MD4 > > hash of what the remote user mistakenly thinks is the password. ... > You'd also have to change the "client" so that it knows what to do = with the=20 > human-entered secret: pre-hash it with MD4 to talk to an NT box, or = not=20 > pre-hash it to talk to anything else. Or you'd have to require the = human to=20 > type the MD4 hashed secret which is even worse. In any case, you'd = have to=20 > have the human know what the box is on the other side. Do most ISPs = tell=20 > you which hardware they're using ? (I don't think many use NT but who = knows=20 > ?) =20 Why would typing the MD4 hashed secret be so terrible? It would be the same as typing any other 20-character password. It's a little long, but not exceptionally. Look at PGP. Today, isn't the operator of the client PC required to know that the ISP is using NT and so configure MS CHAP? Do PC PPP client implemenations use a single password with whatever authentication protocol the server asks, including PAP? (That would be an eggregious security hole that would demand a CERT bulletin.) Is it really possible that some users of PC's could get shells on their ISP's systems using their PPP password? And someone thinks that is=20 desirable? If no one is using NT at an ISP or the private corporate equivalents, then what is the talk about "75 million" systems with MS CHAP? The only justification offered for MS CHAP has been "NT servers need it." > That's what PPP negotiation is for, and I guess that's why there is a=20 > separate CHAP option to talk to an NT box. Not so. The chatting that happens between the computers need not be the same as the chatting between humans. You do have some kind of GUI for configuring PPP, right? The user just types a password into a box on the screen, right? So let the user type "JimBob'sPC," but store the MD4 hash that is the real shared secret in your client's configuration file. It would be a good idea to do that even when Microsoft products are kept far away, since the MD4 or DES hash of most users' passwords is likely to be a far better MD5 CHAP shared secret than the original password. (Genuine "seamless" use of PPP requires that the shared secret be kept on the disk of the client as well as the server, since otherwise you cannot do demand dialing or bandwidth on demand.) > Now I don't like this whole MS-CHAP story either. I especially don't = like=20 > how poorly documented it is with a file hidden on ftp.microsoft.com, = I'd=20 > much prefer to have it as an informational RFC with the IETF, but = that's=20 > beyond the technical point. Technically, I think it's there for a real = > reason and is not worse than anything else. I don't see the real <> reason for the existence MS CHAP. While marketing considerations cannot be ruled out, my guess is that at least some people within Microsoft simply did not and do not understand that the MD4 or DES hash is a cleartext password and that MD5 CHAP would have worked just as well. Without attributing malice to the continuing Microsoft claims about the MD4 and DES hashes and supposed interoperability problems, I see no alternative but=20 fundamental misunderstandings of CHAP and security. As for marketing considerations being "baseless accussations," well, anyone who really thinks that should talk to competant=20 business people, look at the history of patents in business (e.g. firearms in the 19th century or compression in PPP),=20 or what Microsoft and Netscape are saying the other is doing is doing now in the WWW browser and server industries. ] From: "Brad Wilson" ] ... ] > No kidding. Had they done this in the open, they'd be able to draw = on ] > the experience and insight of the community to design something = simpler ] > and more effective. ]=20 ] Uh, this -did- let everyone know about this when they were doing it. No, as I recall, they presented it only after the fact. ] = It's ] old news and old arguments that are being rehashed. It was not until this week that I realized how lame MS CHAP is, that they could have used MD5 CHAP to meet their avowed technical goals. If the arguments are so old, why has it take so many repetitions to convince you that MD5 CHAP would have done exactly as well (modulo perhaps having to type an MD4 hash in addition to a Unicode password) and that the MD4 hash is the real password? Or do you believe that Microsoft understands that MD5 CHAP could have been used just as well as MS CHAP, and if so, how do you explain MS CHAP? The argument over the wisdom of using the same password for PPP and shells is old. The implausible statements that has something to do with C2 are new. ] They published = the ] documents and told everyone who was interested to go take a look. It ] wouldn't be too difficult to pushlish them as informational RFCs, but ] nobody has stepped up to the plate to either say that is MUST be done, = or ] that THEY will do it. Is there any reason that it "MUST be done"? I think it is = self-defeating for Microsoft to not publish now, when their competators understand and only their allies are delayed, but I don't work for Microsoft. As for statements that Microsoft does not bogusly claim that MS CHAP is more secure than MD5 CHAP, read the following: [ From: Glen Zorn [ ... [ Your analysis is correct, as far as it goes. The shared secret = _could_ [ be defined to be the MD4 hash of the user's password, which is the = same [ value stored in the NT user database (or the crypt(3)ed unix password = - [ it works the same way). All that would be required is that every = RADIUS [ server (and NAS and...) that stores passwords in plaintext check N = ways, [ one for every form of encryption used. The method is secure on the [ wire. Suppose, though, that an attacker obtains a copy of the = usernames [ and encrypted passwords (e.g., /etc/passwd). At this point, the [ adversary doesn't even have to guess passwords -- all (s)he needs is = an [ MD5 function and the right challenge to be able to log in as _anyone_. [ I suggest that opening such a glaring hole in PPP authentication might [ be suboptimal. Once again, for the umptyzillionth time, MS CHAP has exactly that "glaring hole" and is just as "suboptimal" as MD5 CHAP. That Microsoft does not want to admit that the MD4 hash is the MS CHAP shared secret does not change the fact that the MD4 hash <> the shared secret. MS CHAP does involve storing the real password as plaintext, and the fact the plaintext password happens to be the MD4 or DES hash of some other string is irrelevant. An attacker that "obtains a copy of the usernames and encrypted passwords" stored in the NT server can "log in as _anyone_", albeit getting network connectivity and not a shell. Of course, it is also wrong to say some alternative would require "that every RADIUS server (and NAS and...) that stores passwords in plaintext check N ways". Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 17:03:11 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA16812; Wed, 21 Aug 1996 17:03:11 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 17:03:11 -0400 (EDT) X-Sender: stadler@mailhost.catapent.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Aug 1996 14:05:00 -0700 To: ietf-ppp@MERIT.EDU From: stadler@catapent.com (Andrew D. Stadler) Subject: PAP state machine questions Resent-Message-ID: <"-c90a1.0.M64.Bct6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1912 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, I'm working on a very minimal PAP implementation - it handles client-side (login) only because it is running in a small embedded system. In this email, I use the terms "client" and "server" to mean "peer being authenticated" and "peer doing authentication". The reference I'm using is RFC 1334 and I've also studied the PPPd 2.2 sources. I have two questions which are not entirely obvious from the RFC: (1) There's not much discussion about dealing with malformed packets, so I plan to silently discard them and wait for additional correct packets. I will also consider codes other than 1,2,3 to be malformed and silently discard. Does this sound correct? (2) I will never request PAP during LCP (because I am never a server). This menas I should never receive authenticate-request packets. What if I do? I am currently just silently discarding them, but perhaps it would be appropriate to do something more explicit here. (3) Does protocol-reject or code-reject have any role in a PAP exchange? Thanks for your advice, Andy Stadler Catapult Entertainment, Inc. stadler@catapent.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 17:36:32 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA17705; Wed, 21 Aug 1996 17:36:32 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 17:36:32 -0400 (EDT) Date: Wed, 21 Aug 1996 14:36:00 -0700 (PDT) From: Erik Olson To: Brad Wilson Cc: ietf-ppp@MERIT.EDU Subject: Re: MS CHAP, for the last time (I hope) In-Reply-To: <199608212012.QAA29573@router.thebrads.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Tyelo2.0.HK4.O5u6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1913 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 21 Aug 1996, Brad Wilson wrote: > Here are the facts, for the last time: > > o MD5 CHAP takes the shared secret, then hashes with MD5 against that. > > o MS CHAP takes the shared secret, hashes with MD4/DES, then hashes > that result with MD5. Sorry, incorrect. MS-CHAP takes the passowrd, hashes with MD4/DES into the shared secret (which is should be same as what they store on disk), then hashes that result WITH DES (NOT MD5) to get the response. There is no use of MD5 anywhere within MS-CHAP. If they had used MD5 to do the hashing to get the response, then it really would be identical to MD5 CHAP (sans the goofy "NT half/Lan Manager half" that was added for backwards compatibility with Windows 95 & Windows 3.1, so says their document). > Standard MD5 CHAP did -not- give the computers a way to negotiate the types > of 'in between' hashing -- whether that be MD4, DES, or none -- and that > was the problem that MS CHAP solved. This, as I see it, is the ONLY value of MS-CHAP. Had there been a method for specifying "type of shared secret", then Microsoft could have used MD5 CHAP with no problems at all, including the Lan Manager backwards-compatibility issue. Interestingly, nobody has brought up the remote "change password" extensions that have been put into MS-CHAP. Now there's your security breach. Any bad guy who finds out the old NT hash can proceed to change (via MS-CHAP) the password hash to anything they want, i.e. something which they know the unhashed version. - Erik --- Erik D. Olson eriko@wrq.com WRQ, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 18:17:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA18975; Wed, 21 Aug 1996 18:17:51 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 18:17:51 -0400 (EDT) Date: Wed, 21 Aug 1996 16:17:22 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608212217.QAA28420@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: MS CHAP, for the last time (I hope) Resent-Message-ID: <"oFxYL3.0.9e4.7iu6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1914 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Brad Wilson" > Here are the facts, for the last time: > > o MD5 CHAP takes the shared secret, then hashes with MD5 against that. > > o MS CHAP takes the shared secret, hashes with MD4/DES, then hashes > that result with MD5. > > These two actions are different, given the MD4/DES hash in the middle. > > Standard MD5 CHAP did -not- give the computers a way to negotiate the types > of 'in between' hashing -- whether that be MD4, DES, or none -- and that > was the problem that MS CHAP solved. Those are "false facts." 1. that description of MD5 CHAP is wrong. The use of MD5 in MD5 CHAP is significantly different from the "intermediate" use of MD4 or DES in MS CHAP. The verb "hash" cannot mean both. 2. as I read the Microsoft document, that description of MS CHAP is wrong, since MS CHAP does not use MD5 in any way whatsoever. The NT flavor of MS CHAP involves a DES encryption using a shared secret key that is obtained from a disk file on the NT server and by MD4 hashing a string from the user on the client. (See pages 5, 6, and 7 of the Microsoft document.) 3. the MS CHAP shared secret is the output of the MD4/DES hash, not the input. It is the output MD4/DES hash that is necessary and suffecient to get PPP access. That DES or MD4 are used to generate the shared secret from some other string is irrelevant. 4. layering is often abused, but in this case it is good. At the "PPP layer", there is no need for any negotiating of any MD5 or MS or CHAP types. Any "in between hashing" is outside of the scope of PPP. As far as PPP is concerned, how the shared secret is obtained is irrelevant and no negotiating is relevant or needed. The MD4/DES hash is not "in the middle;" it is completely outside PPP. That typical PC PPP clients obtain the MS CHAP shared secret by applying MD4 or DES to an ASCII string typed by the user instead of reading a disk file is irrelevant to PPP. Fetching a shared secret, whether for MS CHAP or MD5 CHAP, from a disk file is about as complicated and takes longer than applying DES or MD5 to a user's string. > Not all clients need be required to > do all encryption methods; that's the fundamental reason for NEGOTIATION. > (Take note that PAP is still permissible, if the server is configured to > allow PAP authentication, since the plain shared secret can then be DES/MD4 > hashed and compared against the NT registry). In no case is it technically necessary for all clients to do all encryption methods. It is necessary only if they want to interoperate with all kinds of peers. The repeated implications that somehow MS CHAP reduces the number of required encryption methods are mind boggling. MS CHAP only increased the number of methods that PPP clients need. Still this is irrelevant, unless there is some PPP system that willy-nillie offers any secret it has in whatever PPP authentication protocol is requested by the peer, including PAP. Again, that would be an eggregious security hole because of the way PAP works. > I whole heartedly agree that a new style of MD5 CHAP, where the type of > intermediate hash used, is a much better idea. That's still not out of the > question, IMO, but probably a very late suggestion (I did make the > suggestion to one of the Microsoft guys at the PPPathon at Microsoft in > April of 94; it was dropped somewhere; where, I don't know). I would be > willing to write the draft, if desired. No draft or any other document to, by or from the IETF is needed or justified for any "intermediate hashing". How the shared secret is obtained and/or stored is outside the scope of CHAP and PPP, and generally in the system's user interface. There are almost as many ways of handling the PPP configuration user interface as there are PPP implementations, and no need for IETF documentation of any of them. Again, if Microsoft understands CHAP and has the will to fix their NT PPP code, then they could easily use MD5 CHAP in addition to MS CHAP, do it with the "NtPasswordHash" stored in the NT username database, interoperabily, upward compatibly, and without any changes to clients. I've described how more than once (not that I said anything except the obvious). > On another note, Vernon, you have admitted that you didn't give this any > thought when the issue was presented originally; why do you make so much > noise now, fully 2 1/2 years later, when the horse is out of proverbial > barn? Must we discuss this into the ground -- again -- because you NOW > finally got around to reading the draft? "2 1/2 years later"? The date on the Microsoft description of MS CHAP is "December 1995." "draft"? In this community, "draft" usually means "Internet Draft," and that is not something found only on a corporate FTP site. Every time someone make statements or implications that are clearly incorrect, such as that MS CHAP is more secure than MD5 CHAP, that using MD5 CHAP involves interoperability problems, or that some kind of additional PPP LCP negotiating would be required to use MD5 CHAP with NT servers, I am duty bound to respond with the facts. [ From: Erik Olson [ ... [ This, as I see it, is the ONLY value of MS-CHAP. Had there been a method [ for specifying "type of shared secret", then Microsoft could have used [ MD5 CHAP with no problems at all, including the Lan Manager [ backwards-compatibility issue. I still think the source of the shared secret has nothing to do with PPP. Whether it comes from a disk file, a 'smart card', a hash of a user string, a user string or mental telepathy is irrelevant to PPP. Layering can be our friend; let's use it. [ Interestingly, nobody has brought up the remote "change password" [ extensions that have been put into MS-CHAP. Now there's your security [ breach. Any bad guy who finds out the old NT hash can proceed to change [ (via MS-CHAP) the password hash to anything they want, i.e. something [ which they know the unhashed version. Yup. Which is to say that I wrote nonsense. An attacker that gets the contents of the NT username database can get not just PPP connectivity, but also a shell, unless Microsoft does not implement that facility. I've been guessing that not even Microsoft would really implement that change password stuff. Am I wrong? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 18:24:59 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA19228; Wed, 21 Aug 1996 18:24:59 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 18:24:59 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'Brad Wilson'" , "'Erik Olson'" Cc: "'ietf-ppp@MERIT.EDU'" Subject: RE: MS CHAP, for the last time (I hope) Date: Wed, 21 Aug 1996 15:23:13 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 14 TEXT Resent-Message-ID: <"oVSg21.0.Ai4.tou6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1916 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >---------- >From: Erik Olson[SMTP:eriko@wrq.com] > >Interestingly, nobody has brought up the remote "change password" >extensions that have been put into MS-CHAP. Now there's your security >breach. Any bad guy who finds out the old NT hash can proceed to change >(via MS-CHAP) the password hash to anything they want, i.e. something >which they know the unhashed version. > gurdeep> the crux of the problem here is "finds out the old NT hash". can you explain how this can be acheived? > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 18:21:46 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA19150; Wed, 21 Aug 1996 18:21:46 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 18:21:46 -0400 (EDT) Date: Wed, 21 Aug 1996 16:21:30 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608212221.QAA28440@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: flow control discussion Resent-Message-ID: <"wHEdU2.0.yg4.tlu6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1915 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Alan Pitts > Would it be acceptable to drop this thread for now and move on to = > something else. Wasn't there some discussion of flow-control? Was that = > ever concluded ??? See the L2TP mailing list, via l2tp-request@newbridge.com However, I think I saw a message from the administrator warning of a short vacation. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 18:32:01 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA19720; Wed, 21 Aug 1996 18:32:01 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 18:32:01 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'vjs@mica.denver.sgi.com'" Subject: RE: Microsoft Authentication Date: Wed, 21 Aug 1996 15:27:13 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 14 TEXT Resent-Message-ID: <"LbXIA1.0.np4.Rvu6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1917 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >---------- >From: vjs@mica.denver.sgi.com[SMTP:vjs@mica.denver.sgi.com] >Why would typing the MD4 hashed secret be so terrible? It would be the >same as typing any other 20-character password. It's a little long, >but not exceptionally. gurdeep> are you suggesting that users type in (for example) "\x67491a011e283747047a4b2a0d1e4c50493d3a1" as the password in their favorite dialer when calling into an NT server? > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 19:36:32 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id TAA21695; Wed, 21 Aug 1996 19:36:32 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 19:36:32 -0400 (EDT) Date: Wed, 21 Aug 1996 16:36:23 -0700 (PDT) From: Erik Olson Cc: "'ietf-ppp@MERIT.EDU'" Subject: RE: MS CHAP, for the last time (I hope) In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"gCckW.0.dI5.xrv6o"@merit.edu> To: ietf-ppp@MERIT.EDU Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1918 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 21 Aug 1996, Gurdeep Singh Pall wrote: > >From: Erik Olson[SMTP:eriko@wrq.com] > > > >Interestingly, nobody has brought up the remote "change password" > >extensions that have been put into MS-CHAP. Now there's your security > >breach. Any bad guy who finds out the old NT hash can proceed to change > >(via MS-CHAP) the password hash to anything they want, i.e. something > >which they know the unhashed version. > > > gurdeep> the crux of the problem here is "finds out the old NT hash". > can you explain how this can be acheived? Oh, I don't know... something that immediately comes to mind is having sysadmin privs on another NT of which the victim has an account and uses identical passwords. But I suppose that would be unlikely. This is going on the assumption made in this forum today that NT's storage system is bullet-proof except to the sysadmin, something I haven't personally tested. The point was that in order to change your password via NT (or Unix) directly, you must know the actual password. There is no way for a bad guy to crack your password by knowing the hash... he must know the actual password. If someone breaks into your NT or Unix box, they end up with some "useless" hashes. But if you can change passwords through PPP by knowing the hashes, then you are not gaining much by storing the hashes instead of the original passwords. --- Erik D. Olson eriko@wrq.com WRQ, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 20:00:19 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA22118; Wed, 21 Aug 1996 20:00:19 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 20:00:19 -0400 (EDT) Date: Wed, 21 Aug 1996 18:00:05 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608220000.SAA28722@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"uHuB33.0.GP5.FCw6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1919 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ] From: Gurdeep Singh Pall ] >Interestingly, nobody has brought up the remote "change password" ] >extensions that have been put into MS-CHAP. Now there's your security ] >breach. Any bad guy who finds out the old NT hash can proceed to change ] >(via MS-CHAP) the password hash to anything they want, i.e. something ] >which they know the unhashed version. ] > ] gurdeep> the crux of the problem here is "finds out the old NT hash". ] can you explain how this can be acheived? The same way that finding an MD5 shared secret would be achieved. If one is (in)vulnerable, then so is the other. Perhaps NT is the first computer system in history that is invulnerable, and there never will be any way for attackers to read files they shouldn't. Perhaps there will never be a CERT advisory warning about misconfiguring anonymous FTP on NT. Maybe people at Princeton will never warn about naughty web pages that bypass security checks in Microsoft Explorer. But if that were true, then there would be no reason to not use the user's original ASCII string as the MD5 shared secret and use standard MD5 CHAP. > From: Gurdeep Singh Pall > >Why would typing the MD4 hashed secret be so terrible? It would be the > >same as typing any other 20-character password. It's a little long, > >but not exceptionally. > > gurdeep> are you suggesting that users type in (for example) > "\x67491a011e283747047a4b2a0d1e4c50493d3a1" as the password in their > favorite dialer when calling into an NT server? Of course not! First, as far as I can tell, the MS CHAP shared secret is 16 bytes, and so would not need more than 21 printable ASCII bytes. But let's just say that someone uses an unusually silly encoding that produces twice as many, like \x67491a011e283747047a4b2a0d1e4c50493d3a1 Genuine "seamless integration" of PPP requires that users not need to type any PPP passwords. Such jobs are for computers. However, when the client user does regularly need to type passwords, something modest should be required. There are several well known methods including: 1. something like the PGP key ring. People who use PGP do not type 2048 bit keys. 2. let the user type "JimBob'sPC" to the PC PPP client, and have the PC client software do the MD4 or DES hashing. If I worked on a PC PPP client, I'd push #2. Again: - the shared secret for MS CHAP is not "JimBob'sPC" but the MD4 or DES hash of that string, \x67491a011e283747047a4b2a0d1e4c50493d3a1 - Fetching "\x67491a011e283747047a4b2a0d1e4c50493d3a1" from a disk file is more complicated and expensive than applying MD4 or DES to a string typed by the user. PPP and MD5 CHAP do not and should not care whether \x67491a011e283747047a4b2a0d1e4c50493d3a1 came from a disk file or via MD4 applied to "JimBob'sPC". - the NT server would be unchanged. It would still (I presume) be told "JimBob'sPC" by the NT operator and would still store the MD4 hash of "JimBob'sPC", \x67491a011e283747047a4b2a0d1e4c50493d3a1 in the NT username database. It is simply that when the NT PPP server got an LCP NAK for MD5 CHAP, it would use the real shared secret, \x67491a011e283747047a4b2a0d1e4c50493d3a1, with standard MD5 CHAP instead of with MS CHAP. You could still do MS CHAP password changes--if you really think they're safe. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 20:40:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA23028; Wed, 21 Aug 1996 20:40:36 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 20:40:36 -0400 (EDT) Message-ID: From: Gurdeep Singh Pall To: "'ietf-ppp@MERIT.EDU'" , "'vjs@mica.denver.sgi.com'" Subject: RE: Microsoft Authentication Date: Wed, 21 Aug 1996 17:31:47 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 28 TEXT Resent-Message-ID: <"WhjgB1.0.Yd5.0ow6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1920 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >---------- >From: vjs@mica.denver.sgi.com[SMTP:vjs@mica.denver.sgi.com] > > 2. let the user type "JimBob'sPC" to the PC PPP client, and have > the PC client software do the MD4 or DES hashing. gurdeep> So you advocate the user consciously selects using the MD4 hash as the secret when calling into an NT server - because for other PPP servers the user should be using the password directly. MS-CHAP achieves this transparent to the user thru PPP negotiation - given that both schemes require changes to the client s/w. >It is simply that when the NT PPP server got an LCP NAK for MD5 CHAP, >it would use the real shared secret, >\x67491a011e283747047a4b2a0d1e4c50493d3a1, >with standard MD5 CHAP instead of with MS CHAP. gurdeep> To recap, you have provided a way thru which NT still doesnt work with *existing* implementations using CHAP, AND it requires users to either type in ridiculous passwords or requires the user to know and configure that she/he is calling into an NT server so that the right form of the secret is used. Imho, MS-CHAP is a better solution. > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 20:56:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA23295; Wed, 21 Aug 1996 20:56:29 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 20:56:29 -0400 (EDT) Date: Wed, 21 Aug 1996 21:00:38 -0400 From: Patrick Klos Message-Id: <199608220100.VAA24802@linux.klos.com> To: ietf-ppp@MERIT.EDU, stadler@catapent.com Subject: Re: PAP state machine questions Resent-Message-ID: <"CMjDo1.0.jh5.v0x6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1921 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >I'm working on a very minimal PAP implementation - it handles client-side >(login) only because it is running in a small embedded system. > >In this email, I use the terms "client" and "server" to mean "peer being >authenticated" and "peer doing authentication". Good enough for me! >The reference I'm using is RFC 1334 and I've also studied the PPPd 2.2 sources. > >I have two questions which are not entirely obvious from the RFC: > >(1) There's not much discussion about dealing with malformed packets, so I >plan to silently discard them and wait for additional correct packets. I >will also consider codes other than 1,2,3 to be malformed and silently >discard. Does this sound correct? Yes. If you have a logging capability, you might want to throw them in, but in general, silently discarding bad or malformed packets is the right way to go. >(2) I will never request PAP during LCP (because I am never a server). >This menas I should never receive authenticate-request packets. What if I >do? I am currently just silently discarding them, but perhaps it would be >appropriate to do something more explicit here. Silently discarding these are fine, especially considering if you ever do get one, you're peer is (by definition) quite broken. Again, you might want to log this or make note somehow, so if the link fails, this might be a clue someone should know. >(3) Does protocol-reject or code-reject have any role in a PAP exchange? Based on a quick perusal of related RFCs, no. A Protocol-Reject for PAP would be inappropriate since you DO support PAP, even though you don't support reception of a PAP Authenticate-Request. A Code-Reject packet type is not even defined for PAP packet type, so there's no way to do that. Of course, in the unlikely event that your server sends you an LCP Configure- Nak adding the Authentication Protocol option (trying to force you to authenticate them), make sure your implementation doesn't accept the option and send it in the next LCP Configure-Request. Let us know if you have any other questions! ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 21:46:36 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id VAA24233; Wed, 21 Aug 1996 21:46:36 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 21:46:36 -0400 (EDT) Message-Id: <199608220148.VAA04880@router.thebrads.com> From: "Brad Wilson" To: Subject: Re: MS CHAP, for the last time (I hope) Date: Wed, 21 Aug 1996 21:46:24 -0400 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_JiBv2.0.Ew5.plx6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1922 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Sorry, incorrect. MS-CHAP takes the passowrd, hashes with MD4/DES into the > shared secret (which is should be same as what they store on disk), then > hashes that result WITH DES (NOT MD5) to get the response. There is no > use of MD5 anywhere within MS-CHAP. You're right, I read the draft incorrectly. > If they had used MD5 to do the hashing to get the response, then it > really would be identical to MD5 CHAP (sans the goofy "NT half/Lan > Manager half" that was added for backwards compatibility with Windows 95 > & Windows 3.1, so says their document). Right, that's because they changed hashing algorithms midstream. > This, as I see it, is the ONLY value of MS-CHAP. Had there been a method > for specifying "type of shared secret", then Microsoft could have used > MD5 CHAP with no problems at all, including the Lan Manager > backwards-compatibility issue. Agreed. -- Brad Wilson Objectivist Philosopher, Software Engineer, Web Designer crucial@pobox.com http://www.thebrads.com/bradw Objectvst@Undernet "I know that you would love to know the answers, but to you the truth is just another lie." - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 21 22:25:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA24911; Wed, 21 Aug 1996 22:25:12 -0400 (EDT) Resent-Date: Wed, 21 Aug 1996 22:25:12 -0400 (EDT) Date: Wed, 21 Aug 1996 20:23:49 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608220223.UAA29121@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: Microsoft Authentication Resent-Message-ID: <"To1GV2.0.z46.4Ky6o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1923 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Gurdeep Singh Pall > > 2. let the user type "JimBob'sPC" to the PC PPP client, and have > > the PC client software do the MD4 or DES hashing. > > gurdeep> So you advocate the user consciously selects using the MD4 hash > as the secret when calling into an NT server - because for other PPP > servers the user should be using the password directly. Not necessarily. Please read what I have written, particulary where I wrote that an MD4 hash of the typical user password is likely to be a better shared secret for MD5 CHAP implementations that have had and will have nothing to do with Microsoft or supporting MS CHAP. > MS-CHAP achieves > this transparent to the user thru PPP negotiation - given that both > schemes require changes to the client s/w. If one is changing client software to support MS CHAP, than one may as well support MD5 CHAP with an MD4 hash of the user's password as the shared MD5 CHAP secret as well as (or instead of) MS CHAP. > >It is simply that when the NT PPP server got an LCP NAK for MD5 CHAP, > >it would use the real shared secret, > >\x67491a011e283747047a4b2a0d1e4c50493d3a1, > >with standard MD5 CHAP instead of with MS CHAP. > > gurdeep> To recap, you have provided a way thru which NT still doesnt > work with *existing* implementations using CHAP, I think that is entirely wrong, and that what I described is completely interoperable with IETF standard MD5 CHAP. Instead of yet again repeating your assertion, please describe how what I have described is in any way not interoperable. > AND it requires users > to either type in ridiculous passwords or requires the user to know and > configure that she/he is calling into an NT server so that the right > form of the secret is used. Imho, MS-CHAP is a better solution. That is based on the false premise that users of reasonable client software need not already know that the server is an NT box that needs special help. Again, reasonable (implying "secure") PPP client software needs to be told which flavors of PPP authentication to expect the server to ask. It would be a very serious security hole for any PPP implementation to use whatever PPP authentication the peer asks. It is absolutely required that it be possible to configure the authentication flavors that are supported. Again, consider the consequences of going along with a request for PAP resulting from an attackers use of any of the several attacks that let the attacker's computer pretend to be the real server. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 04:54:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA03355; Thu, 22 Aug 1996 04:54:49 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 04:54:49 -0400 (EDT) Mime-Version: 1.0 Date: Thu, 22 Aug 1996 09:46:21 +0100 Message-ID: <21c20330@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: PAP state machine questions To: ietf-ppp@MERIT.EDU, stadler@catapent.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"F1laM.0.5q.E127o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1924 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Patrick Klos writes:> > >Andy Stadler wrote:>> > >I'm working on a very minimal PAP implementation - it handles client-side > >(login) only because it is running in a small embedded system. > > > >In this email, I use the terms "client" and "server" to mean "peer being > >authenticated" and "peer doing authentication". > Good enough for me! I'd prefer to use the terms "Authenticatee" and "Authenticator" as they're unambiguous (as used in the MS-CHAP spec, if I dare mention MS-CHAP again!) > >The reference I'm using is RFC 1334 and I've also studied the PPPd 2.2 > > sources. > >I have two questions which are not entirely obvious from the RFC: > > > >(1) There's not much discussion about dealing with malformed packets, so I > >plan to silently discard them and wait for additional correct packets. I > >will also consider codes other than 1,2,3 to be malformed and silently > >discard. Does this sound correct? >Yes. If you have a logging capability, you might want to throw them in, but > in general, silently discarding bad or malformed packets is the right way > to go. Agreed. > >(2) I will never request PAP during LCP (because I am never a server). > >This means I should never receive authenticate-request packets. What if > >I do? I am currently just silently discarding them, but perhaps it would > >be appropriate to do something more explicit here. >Silently discarding these are fine, especially considering if you ever >do get one, your peer is (by definition) quite broken. Again, you >might want to log this or make note somehow, so if the link fails, this >might be a clue someone should know. A more pragmatic approach might be to send an Auth-Ack - if you're not authenticating the peer anyway, it's hardly a security breach. This may allow you to interwork even with a broken peer (as long as it's not broken too badly). > >(3) Does protocol-reject or code-reject have any role in a PAP exchange? >Based on a quick perusal of related RFCs, no. A Protocol-Reject for PAP >would be inappropriate since you DO support PAP, even though you don't >support reception of a PAP Authenticate-Request. >A Code-Reject packet type is not even defined for PAP packet type, so there's >no way to do that. >Of course, in the unlikely event that your server sends you an LCP Configure- >Nak adding the Authentication Protocol option (trying to force you to >authenticate them), make sure your implementation doesn't accept the option >and send it in the next LCP Configure-Request. Maybe, but it wouldn't do any harm to let the server be authenticated (see my point above) if it insists be doing so - the negotiation isn't likely to converge if you remove the Authentication option from the next Configure Request. As a further point it'd be nice to have explicit rules for error conditions in future drafts and RFCs ! Jonathan Goodchild Racal Datacom, Hook, Hampshire, England - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 11:54:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA11616; Thu, 22 Aug 1996 11:54:52 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 11:54:52 -0400 (EDT) Date: Thu, 22 Aug 1996 10:39:36 -0400 Message-Id: <9608221439.AA21021@routeabout.mko.dec.com> From: Shane Hooker To: stadler@catapent.com (Andrew D. Stadler) Cc: ietf-ppp@MERIT.EDU Subject: PAP state machine questions In-Reply-To: References: Reply-To: hooker@mkons1.mko.dec.com Resent-Message-ID: <"YZeO03.0.Ar2.9A87o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1925 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Andrew D. Stadler writes: (1) There's not much discussion about dealing with malformed packets, so I plan to silently discard them and wait for additional correct packets. I will also consider codes other than 1,2,3 to be malformed and silently discard. Does this sound correct? >> yes you can discard them. If your request timer expires >> while waiting for a correct packet then you should terminate >> the connection (2) I will never request PAP during LCP (because I am never a server). This menas I should never receive authenticate-request packets. What if I do? I am currently just silently discarding them, but perhaps it would be appropriate to do something more explicit here. >> well you could send a protocol reject packet back since >> you do not have the information to acknowledge the PAP >> request. Chances are that discarding the request will >> not hurt because if the other side hasn't heard an >> ACK or NAK it may stop trying. Or a worse case it that >> it keeps trying and never shuts up. But the only time >> you should receive a PAP request would be if your client >> had sent PAP in it's LCP request which you have total >> control over. (3) Does protocol-reject or code-reject have any role in a PAP exchange? >> these are used anytime you receive a type of packet that >> you cannot handle. >> Shane Hooker - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 13:24:37 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA14941; Thu, 22 Aug 1996 13:24:37 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 13:24:37 -0400 (EDT) Date: Thu, 22 Aug 1996 13:21:24 -0400 (EDT) From: John Gregg Message-Id: <199608221721.NAA26054@shiva-dev.shiva.com> To: hooker@mkons1.mko.dec.com, stadler@catapent.com Subject: Re: PAP state machine questions Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"UHTE03.0.Bf3.EV97o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1926 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU (2) I will never request PAP during LCP (because I am never a server). This menas I should never receive authenticate-request packets. What if I do? I am currently just silently discarding them, but perhaps it would be appropriate to do something more explicit here. >> well you could send a protocol reject packet back since >> you do not have the information to acknowledge the PAP >> request. Chances are that discarding the request will >> not hurt because if the other side hasn't heard an >> ACK or NAK it may stop trying. Or a worse case it that >> it keeps trying and never shuts up. But the only time >> you should receive a PAP request would be if your client >> had sent PAP in it's LCP request which you have total >> control over. (3) Does protocol-reject or code-reject have any role in a PAP exchange? >> these are used anytime you receive a type of packet that >> you cannot handle. >> Shane Hooker No. An LCP protocol reject (the only kind that exist) could only mean "I do not understand protocol 0xC023 (PAP). Please never send me anything with that protocol ID again." This is not what you want in the scenarios described. There is no such thing as a PAP Code Reject packet, so again, we must be talking about LCP. What would this packet look like, exactly? There is no way to form such a packet that would make any sense. There is no way in PAP to express displeasure with particular packet codes, and based on years of interoperability, and the present and future decline of PAP, I would say there doesn't need to be. You are stuck just discarding the packets silently, unless you want to take down the link. Has this actually happened in real life? The road to Hell (read: CCITT/ITU) is paved with trying to envision all possible error cases and scenarios in a given protocol, and specifying desired behavior for all of them (then, of course, writing test suite specifications that demand all the right behavior in all those cases, then barring access to large markets unless your equipment has been given the green light by a certified tester who ran all those tests . . .) In short, do something in this error case that you think might be a reasonable thing to do and leave it at that. I argue that the proverbial silent discard is the obvious (only?) choice. -John Gregg Shiva Corp. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 14:20:14 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA16965; Thu, 22 Aug 1996 14:20:14 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 14:20:14 -0400 (EDT) Date: Thu, 22 Aug 1996 12:19:50 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608221819.MAA00459@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PAP state machine questions Resent-Message-ID: <"0xOoP2.0.m84.LJA7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1927 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > (2) I will never request PAP during LCP (because I am never a server). Note that the weakness of PAP when requested of the system answering the phone is a special case. Reasonable systems using modems to call other systems often want to use CHAP or something else to authenticate the peer. There are enough decades-old attacks that make it unwise to blindly assume that because your system dialed a phone number it is talking to the system that usually answers that number. > ... > You are stuck just discarding the packets silently, unless you want to > take down the link. Has this actually happened in real life? ... I've seen other systems send unsolicited PAP requests. > In short, do something in this error case that you think might be a > reasonable thing to do and leave it at that. I argue that the proverbial > silent discard is the obvious (only?) choice. Responding to an unsolicited PAP request with an Ack can do no harm and can sometimes help. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 15:06:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA19177; Thu, 22 Aug 1996 15:06:31 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 15:06:31 -0400 (EDT) Message-ID: From: Glen Zorn To: "'Karl Fox'" , "'ljb@merit.edu'" Cc: "'ietf-ppp@merit.edu'" Subject: RE: Microsoft Authentication Date: Thu, 22 Aug 1996 12:05:39 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 26 TEXT Resent-Message-ID: <"lbNzc3.0.Fh4.l-A7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1928 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl Fox (karl@ascend.com) writes: > >Glen Zorn writes: >> Your analysis is correct, as far as it goes. The shared secret _could_ >> be defined to be the MD4 hash of the user's password, which is the same >> value stored in the NT user database >... >> Suppose, though, that an attacker obtains a copy of the usernames >> and encrypted passwords (e.g., /etc/passwd). At this point, the >> adversary doesn't even have to guess passwords -- all (s)he needs is an >> MD5 function and the right challenge to be able to log in as _anyone_. > >I'm confused. Isn't this exactly the situation we have right now with >MS-CHAP on NT? This is similar to a Unix MD5 CHAP where the user gets >a copy of the clear CHAP passwords. Karl -- You're not confused, I am. My response was totally incorrect, based upon an poor recollection of how MS-CHAP worked. I realized this once I actually re-read the MS-CHAP document. That'll teach me (I hope)! Larry -- I apologize for calling you clueless, since it is now apparent that it is I who was truly clueless on this subject. > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 17:56:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA24044; Thu, 22 Aug 1996 17:56:31 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 17:56:31 -0400 (EDT) Date: Thu, 22 Aug 1996 22:00:16 GMT Message-Id: <199608222200.WAA26859@carp.morningstar.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: PPP Extensible Authentication Protocol (EAP) - Working Group Last Call Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"BQYYX1.0.Qt5.8UD7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1929 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU This is last call. I will advise the area director that we want to take the PPP Extensible Authentication Protocol to Proposed Standard on September 6 unless there is substantive comment raised on the list. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 *** NOTE: NEW PHONE NUMBER. Try +1 614 451 1883 ext. 841 if it doesn't work *** - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 22 18:57:03 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA25378; Thu, 22 Aug 1996 18:57:03 -0400 (EDT) Resent-Date: Thu, 22 Aug 1996 18:57:03 -0400 (EDT) Date: Thu, 22 Aug 96 17:50:31 CDT Message-Id: <9608222250.AA14751@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Karl Fox From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working Group Last Call Cc: ietf-ppp@MERIT.EDU X-Mailer: Resent-Message-ID: <"e2FoM.0.GC6.xME7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1930 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >This is last call. I will advise the area director that we want to >take the PPP Extensible Authentication Protocol to Proposed Standard >on September 6 unless there is substantive comment raised on the list. I have raised an issue before but it apparently it was ignored by all. I wanted to suggest that a byte field in the Type-Data field for the Generic Token Card request packets be added. This byte could be encoded as follows: 0 - Display user response in the clear (i.e. 'Username:' prompt response) 1 - Hide user response with no-echo (i.e. 'Password: ' prompt) 2 - Hide user response with echo of *'s 3 - Response should be one character only (i.e. 'Continue (y/n)' prompt) Token card vendors usually don't want some responses like the users PIN to be displayed. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 08:33:05 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA09563; Fri, 23 Aug 1996 08:33:05 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 08:33:05 -0400 (EDT) Date: Fri, 23 Aug 1996 08:37:00 -0400 From: Patrick Klos Message-Id: <199608231237.IAA10923@linux.klos.com> To: ietf-ppp@MERIT.EDU, Jonathan.Goodchild@rdl.co.uk, stadler@catapent.com Subject: Re: Re[2]: PAP state machine questions Resent-Message-ID: <"S_TEg3.0.9L2.jJQ7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1931 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> Good enough for me! > >I'd prefer to use the terms "Authenticatee" and "Authenticator" as they're >unambiguous (as used in the MS-CHAP spec, if I dare mention MS-CHAP again!) Sure, but in the context of the original poster's question, the terms were unambiguous enough. >> >(2) I will never request PAP during LCP (because I am never a server). >> >This means I should never receive authenticate-request packets. What if >> >I do? I am currently just silently discarding them, but perhaps it would >> >be appropriate to do something more explicit here. > >>Silently discarding these are fine, especially considering if you ever >>do get one, your peer is (by definition) quite broken. Again, you >>might want to log this or make note somehow, so if the link fails, this >>might be a clue someone should know. > >A more pragmatic approach might be to send an Auth-Ack - if you're not >authenticating the peer anyway, it's hardly a security breach. This may >allow you to interwork even with a broken peer (as long as it's not >broken too badly). My only opposition to this is that it would tend to encourage broken implementations. Usually, implementors like to find out pretty early on that they did something wrong. Letting someone do something which is wrong (by definition) could do them more harm than good. >As a further point it'd be nice to have explicit rules for error conditions in >future drafts and RFCs ! True. ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 08:51:04 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id IAA10125; Fri, 23 Aug 1996 08:51:04 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 08:51:04 -0400 (EDT) Date: Fri, 23 Aug 1996 08:55:21 -0400 From: Patrick Klos Message-Id: <199608231255.IAA11432@linux.klos.com> To: ietf-ppp@MERIT.EDU, vjs@mica.denver.sgi.com Subject: Re: PAP state machine questions Resent-Message-ID: <"B7dpJ3.0.tT2.qaQ7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1932 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >> (2) I will never request PAP during LCP (because I am never a server). > >Note that the weakness of PAP when requested of the system answering the >phone is a special case. >Reasonable systems using modems to call other systems often want to use >CHAP or something else to authenticate the peer. There are enough >decades-old attacks that make it unwise to blindly assume that because >your system dialed a phone number it is talking to the system that >usually answers that number. This has nothing to do with the question. >> You are stuck just discarding the packets silently, unless you want to >> take down the link. Has this actually happened in real life? ... > >I've seen other systems send unsolicited PAP requests. Did you let the "other systems" vendors know about this so they could fix thier problem? >> In short, do something in this error case that you think might be a >> reasonable thing to do and leave it at that. I argue that the proverbial >> silent discard is the obvious (only?) choice. > >Responding to an unsolicited PAP request with an Ack can do no harm >and can sometimes help. I disagree. As I said in another response, by letting someone do something wrong (like this), thier bug may go undetected by them for too long. When they do finally find out what they did wrong, thier product could be sitting on many more machines than they had hoped to have to upgrade. Logging bad behavior and not letting them "get away" with it is the best way to promote real interoperability. (just my opinion) ============================================================================ Patrick Klos Email: klos@klos.com Klos Technologies, Inc. Voice: (603) 424-8300 604 Daniel Webster Highway FAX: (603) 424-9300 Merrimack, New Hampshire 03054 Web: http://web.klos.com/ ============================================================================ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 09:30:37 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA11603; Fri, 23 Aug 1996 09:30:37 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 09:30:37 -0400 (EDT) From: Manas Barooah Message-Id: <199608231404.TAA18137@comm10> Subject: Protocol Spoofing Control Protocol To: ietf-ppp@MERIT.EDU Date: Fri, 23 Aug 1996 19:04:25 +0500 (GMT+0500) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ps16u.0.uq2.u9R7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1933 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU After going through the PSCP draft have certain doubts regarding CALL COLLISION when resuming a Connection. The draft says the following. >4.4. Call Collision when Resuming a Connection > > Under certain circumstances, there could be a possibility that both > ends might decide that a suspended connection is to be resumed at the > same time. This could result in calls being issued in both directions > for the same connection (i.e. "call collision"). If both the sides decide to start a resumption at the same time, then both of them will try to dial each other at the same time and hence the link will never come up, for a BUSY response will come from the modem for both of them. I am considering Modem dial up. > The call collision situation is resolved by the use of the "Magic > Number" configuration option negotiated by LCP. A device which > detects such a call collision MUST terminate LCP on the call which > was issued by the end with the smaller magic number. The above description will be possible when one end of the link decided earlier about resuming the session. Now I am a bit in grey regarding terminating LCP on the call which was issued by the end with the smaller magic number. Does it mean we have to send terminate request packets to the peer with smaller magic number. And when we get the terminate Ack from the peer we sent LCP configuration req packets again. Bye Manas Barooah manas@wipinfo.soft.net - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 10:08:30 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA12449; Fri, 23 Aug 1996 10:08:30 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 10:08:30 -0400 (EDT) Mime-Version: 1.0 Date: Fri, 23 Aug 1996 15:00:10 +0100 Message-ID: <21dbb370@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: Protocol Spoofing Control Protocol To: ietf-ppp@MERIT.EDU, manas@wipinfo.soft.net Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"bQdDG2.0.E23.QjR7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1934 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Manas Barooah writes:> >After going through the PSCP draft have certain doubts regarding CALL COLLISION when resuming a >connection. The draft says the following. > >4.4. Call Collision when Resuming a Connection > > > Under certain circumstances, there could be a possibility that both > > ends might decide that a suspended connection is to be resumed at the > > same time. This could result in calls being issued in both directions > > for the same connection (i.e. "call collision"). > If both the sides decide to start a resumption at the same time, > then both of them will try to dial each other at the same time > and hence the link will never come up, for a BUSY response will > come from the modem for both of them. I am considering Modem dial up. I think the spec is talking about the case where both calls are successful - this won't happen with modem dial-up if you've only got one modem, but is quite possible with ISDN. The spec should include something about what to do in the event of a call failure due to a busy condition. How about a retry after a random backoff time, or something based on the magic numbers ? Maybe the backoff time should be negotiated explicitly by PSCP ? > > The call collision situation is resolved by the use of the "Magic > > Number" configuration option negotiated by LCP. A device which > > detects such a call collision MUST terminate LCP on the call which > > was issued by the end with the smaller magic number. > The above description will be possible when one end of the link > decided earlier about resuming the session. Now I am a bit > in grey regarding terminating LCP on the call which was issued > by the end with the smaller magic number. Does it mean we > have to send terminate request packets to the peer with smaller > magic number. And when we get the terminate Ack from the peer > we sent LCP configuration req packets again. No - disconnect the ISDN B channel (or other dial-up link). You will have another ISDN B channel already active - that's how call collision was detected in the first place. By the way, does anyone know if there are any assigned numbers yet for PSCP ? Jonathan Goodchild - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 10:56:50 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA13443; Fri, 23 Aug 1996 10:56:50 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 10:56:50 -0400 (EDT) Date: Fri, 23 Aug 1996 08:55:07 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608231455.IAA03332@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PAP state machine questions Resent-Message-ID: <"f7HP71.0.mH3.iQS7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1935 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Patrick Klos > To: ietf-ppp@MERIT.EDU, vjs > ... > >Reasonable systems using modems to call other systems often want to use > >CHAP or something else to authenticate the peer. ... > This has nothing to do with the question. Not directly, but the wording of the question suggested the original author is among the many people, especially in the PC and dedicated-box worlds, who mistakenly think that authentication is a one-way street between "client" and "server," and do not realize the serious security holes that result. In general, they are the many who do not realize or refuse to admit that the words "client" and "server" are bogus applied to PPP peers. PPP is a protocol between equivalent systems, which is why we use the word "peer." > >> You are stuck just discarding the packets silently, unless you want to > >> take down the link. Has this actually happened in real life? ... > > > >I've seen other systems send unsolicited PAP requests. > > Did you let the "other systems" vendors know about this so they could fix > thier problem? I've long since forgotten the specific cases. In general, if they ask, or I have a contact, I tell far more than anyone would want to hear. However, my job is to see that my code interoperates, not test or diagnose other vendor's code. If they can't check or understand their own packet traces, I'm unlikely to be able to convince them. Even when I do find someone who listens, I must still work around the bug, since by the time they can release a fix and get some of their customers to install it, months to years will have elapsed. Even after they release a fix, my code must continue to tolerate installations of their old code. > >> In short, do something in this error case that you think might be a > >> reasonable thing to do and leave it at that. I argue that the proverbial > >> silent discard is the obvious (only?) choice. > > > >Responding to an unsolicited PAP request with an Ack can do no harm > >and can sometimes help. > > I disagree. As I said in another response, by letting someone do something > wrong (like this), thier bug may go undetected by them for too long. When > they do finally find out what they did wrong, thier product could be sitting > on many more machines than they had hoped to have to upgrade. Logging bad > behavior and not letting them "get away" with it is the best way to promote > real interoperability. (just my opinion) If we were in a bake-off or a school project, that would be fine. Otherwise, it's not worth much effort. I tried doing exactly as suggested for that abused LCP CR option number zero, logging the occurrance of the error in my logs, telling the vendor, including in bake-offs, and telling others. As a reward, I was vilified when I was not ignored. Of far more significance, those log messages cost SGI money for support calls from customers worried that something was not working. Consider the recent, fruitless discussion of MS CHAP or the problem many reported concerning LCP Rejects and Naks for authentication flavors. Only when you cannot easily work around the other vendor's mistake is the effort more than masochism. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 11:15:47 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA14146; Fri, 23 Aug 1996 11:15:47 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 11:15:47 -0400 (EDT) Date: Fri, 23 Aug 1996 09:15:31 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608231515.JAA03506@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Protocol Spoofing Control Protocol Resent-Message-ID: <"tcyJh1.0.mS3.TiS7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1936 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > If both the sides decide to start a resumption at the same time, > > then both of them will try to dial each other at the same time > > and hence the link will never come up, for a BUSY response will > > come from the modem for both of them. I am considering Modem dial up. > > I think the spec is talking about the case where both calls are successful - > this won't happen with modem dial-up if you've only got one modem, but is > quite possible with ISDN. > > The spec should include something about what to do in the event of a call > failure due to a busy condition. How about a retry after a random backoff > time, or something based on the magic numbers ? Maybe the backoff time > should be negotiated explicitly by PSCP ? For many years SGI has been shipping PPP and SLIP that support symmetric demand dialing and (for PPP) what is now called "bandwidth on demand" (i.e. dynamic multilink). They use binary exponential random backoffs and work fine. No negotiating is needed. It also solves dealing with peers that have more peers than phone lines, and users and dumb peers don't realize what's happening. The rate of backoff increase ought to depend on the link. It generally takes only a second or two to know an ISDN peer is busy, but at least 5 or 10 seconds to know that a v.32 or v.34 modem peer is busy. > Maybe the backoff time > should be negotiated explicitly by PSCP ? To negotiate something when you don't have a link (e.g. on the first phone call) might need some new technology, such as telepathy. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 11:29:00 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA14460; Fri, 23 Aug 1996 11:29:00 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 11:29:00 -0400 (EDT) Message-ID: <01BB9110.2385DBE0@localhost> From: Ian Puleston To: "ietf-ppp@MERIT.EDU" Subject: RE: Protocol Spoofing Control Protocol Date: Fri, 23 Aug 1996 16:28:56 +-100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Kw8Jc2.0.gX3.uuS7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1937 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Jonathan Goodchild[SMTP:Jonathan.Goodchild@rdl.co.uk] > Sent: 23 August 1996 15:47 > To: ietf-ppp@MERIT.EDU; manas@wipinfo.soft.net > Subject: Re: Protocol Spoofing Control Protocol > > > Under certain circumstances, there could be a possibility that both > > > ends might decide that a suspended connection is to be resumed at the > > > same time. This could result in calls being issued in both directions > > > for the same connection (i.e. "call collision"). > > If both the sides decide to start a resumption at the same time, > > then both of them will try to dial each other at the same time > > and hence the link will never come up, for a BUSY response will > > come from the modem for both of them. I am considering Modem dial up. > I think the spec is talking about the case where both calls are successful - > this won't happen with modem dial-up if you've only got one modem, but is > quite possible with ISDN. That is correct. > The spec should include something about what to do in the event of a call > failure due to a busy condition. How about a retry after a random backoff > time, or something based on the magic numbers ? Maybe the backoff time > should be negotiated explicitly by PSCP ? Busy failures due to call collision should be pretty rare, so it probably isn't worth over-complicating the spec. to deal with them too cleverly. Also, the busy condition may be due to the ISDN channel/phone line getting re-used by another call (some implementations may allow this). I would therefore be in favour of leaving it up to the implementor, and having the spec. advise a simple random backoff. > > > The call collision situation is resolved by the use of the "Magic > > > Number" configuration option negotiated by LCP. A device which > > > detects such a call collision MUST terminate LCP on the call which > > > was issued by the end with the smaller magic number. > > The above description will be possible when one end of the link > > decided earlier about resuming the session. Now I am a bit > > in grey regarding terminating LCP on the call which was issued > > by the end with the smaller magic number. Does it mean we > > have to send terminate request packets to the peer with smaller > > magic number. And when we get the terminate Ack from the peer > > we sent LCP configuration req packets again. > No - disconnect the ISDN B channel (or other dial-up link). You will have > another ISDN B channel already active - that's how call collision was detected > in the first place. Yes. The wording of the paragraph proably isn't too clear. The following may be better: In a call collision situation there will be two calls established between the two peers, and one must be cleared down. Since both peers will probably detect the call collision, and hence simultaneously clear one call, it is important that they both select the same call to clear. This selection is based on the "Magic Number" configuration option negotiated by LCP. The call which was issued by the peer with the smaller magic number should be the one cleared. It can be cleared by either peer (or both peers) terminating LCP on it. > By the way, does anyone know if there are any assigned numbers yet for PSCP ? No, not yet. My company (which was KNX) has been taken over by Global Village Inc, and our development priorities have changed a bit. Therefore, having written the PSCP spec. I have not been able to do any work on it since. Hopefully, I should be able to start on an implementation before too long. If anyone is interested enough in this to start doing some work on it (I believe that Novell may have already started) then let me know and I will apply to get some numbers assigned. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 16:25:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id QAA20934; Fri, 23 Aug 1996 16:25:20 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 16:25:20 -0400 (EDT) Message-Id: <199608232024.QAA09035@muir-woods.american.com> X-Authentication-Warning: muir-woods.american.com: Host localhost [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.7 5/3/96 To: Craig Fox cc: jay@gordian.com (Jay Laefer), ietf-ppp@MERIT.EDU, brad@american.com Subject: Re: ATCP status? In-reply-to: Your message of "Mon, 12 Aug 1996 03:42:59 PDT." <199608121042.DAA07218@greatdane.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 23 Aug 1996 16:24:26 -0400 From: Brad Parker Resent-Message-ID: <"cC7jo1.0.m65.aEX7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1938 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Karl Fox writes: > > >Jay Laefer writes: > > >> Two years ago, draft-ietf-pppext-atcp2-00.txt was released which > > >> contained some clarifications and at least one major change to ATCP. > > > > > >I don't have a copy of that draft--did Brad Parker write it? Brad, > > >are you out there? If not, does anyone know what his e-mail address > > >is? > > > > Yes, Brad Parker wrote it. The date on the draft is July 1994, and > > the author's address is listed as brad@fcr.com. The address appears > > to be current. Who me? :-) I've asked the guys at FCR (Bill Kirtley, kirtley@fcr.com and Paul Couto, couto@fcr.com) to pick this up and "do the right thing", what ever that might be. They're both doing lots with PPP on a daily basis and have implemented multilink, ATCP, etc... While I *use* PPP every day (doesn't everyone? :-) I'm not doing any development of it these days so it mades more sense for them to run with the draft. -brad - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 23 18:07:05 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id SAA23084; Fri, 23 Aug 1996 18:07:05 -0400 (EDT) Resent-Date: Fri, 23 Aug 1996 18:07:05 -0400 (EDT) X-Sender: stadler@mailhost.catapent.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 23 Aug 1996 15:09:07 -0700 To: ietf-ppp@MERIT.EDU From: stadler@catapent.com (Andrew D. Stadler) Subject: Re: PAP state machine questions Cc: vjs@mica.denver.sgi.com (Vernon Schryver) Resent-Message-ID: <"H-Een.0.Ne5.5kY7o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1939 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Not directly, but the wording of the question suggested the original >author is among the many people, especially in the PC and dedicated-box >worlds, who mistakenly think that authentication is a one-way street >between "client" and "server," and do not realize the serious security >holes that result. In general, they are the many who do not realize or >refuse to admit that the words "client" and "server" are bogus applied >to PPP peers. PPP is a protocol between equivalent systems, which is >why we use the word "peer." (1) I of course completely agree that PPP is a completely symmetric protocol between peers. However, the *configuration* of *most* systems - which peer requests which options - is clearly a client-server relationship. I apologize for ruffling any semantic feathers, but it seemed to be a useful shorthand for the configuration we have. (2) I agree that two-way authentication is useful for highest security, but to be honest, I have yet to run across a dial-in node (commonly called a "terminal server") which even provides self-authentication. I would be happy to put the authenticate-peer code into my box, but in my application, I truly don't have anything to authenticate. Instead of using words like "bogus" and "mistaken", how about writing a note providing some positive direction or recommendation here. Andy Stadler stadler@catapent.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 26 07:29:33 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA01304; Mon, 26 Aug 1996 07:29:33 -0400 (EDT) Resent-Date: Mon, 26 Aug 1996 07:29:33 -0400 (EDT) Message-Id: <26192.9608261128@vulcan.xylogics.com> To: stadler@catapent.com (Andrew D. Stadler) Cc: ietf-ppp@MERIT.EDU Subject: Re: PAP state machine questions In-Reply-To: Your message of "Fri, 23 Aug 1996 15:09:07 PDT." Date: Mon, 26 Aug 1996 07:28:37 -0400 From: James Carlson Resent-Message-ID: <"V_3As3.0.6K.tfO8o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1940 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Andy Stadler writes: > (1) I of course completely agree that PPP is a completely symmetric > protocol between peers. However, the *configuration* of *most* systems - > which peer requests which options - is clearly a client-server > relationship. I apologize for ruffling any semantic feathers, but it > seemed to be a useful shorthand for the configuration we have. Most? Hmm. Perhaps by numbers of owners of the equipment involved, but probably not by volume of data carried. > (2) I agree that two-way authentication is useful for highest security, > but to be honest, I have yet to run across a dial-in node (commonly called > a "terminal server") which even provides self-authentication. Ours do; that's what ppp_username_remote and ppp_password_remote are for. I agree that most dial-up providers don't use this feature, but it is an important part of the protocol. > Instead of using words like "bogus" and "mistaken", how about writing a > note providing some positive direction or recommendation here. Vernon's comment was not off the mark -- distinctions between "client" and "server" in a completely symmetric protocol like PPP are simply false. They reflect a rather narrow and erroneous view of the protocol, and one which is likely to lead to bad decisions. As for a positive statement, how about "all PPP implementors are encouraged to create interfaces that support authentication in both directions"? --- James Carlson Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 26 09:37:49 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA03472; Mon, 26 Aug 1996 09:37:49 -0400 (EDT) Resent-Date: Mon, 26 Aug 1996 09:37:49 -0400 (EDT) Date: Mon, 26 Aug 1996 07:37:30 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608261337.HAA09069@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: PAP state machine questions Resent-Message-ID: <"z0aYt2.0.wr.fYQ8o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1941 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: James Carlson > ... > Vernon's comment was not off the mark -- distinctions between "client" and > "server" in a completely symmetric protocol like PPP are simply false. > They reflect a rather narrow and erroneous view of the protocol, and one > which is likely to lead to bad decisions. As a possible example of such 'not quite optimal' decisions resulting from that 'not entirely fortunate' distinction, consider the very large software vendor that its built PPP code so that it could be configured either as a "server" or as a "client" but not both, and allowed only "servers" to require the peer authentication and only "clients" to provide authentication. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Aug 26 22:05:05 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id WAA17208; Mon, 26 Aug 1996 22:05:05 -0400 (EDT) Resent-Date: Mon, 26 Aug 1996 22:05:05 -0400 (EDT) Message-Id: <2.2.32.19960827020243.006959e0@tiac.net> X-Sender: ksiegel@tiac.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 1996 22:02:43 -0400 To: Brad Parker , Craig Fox From: Ken Siegel Subject: Re: ATCP status? Cc: ietf-ppp@MERIT.EDU, kirtley@fcr.com, couto@fcr.com Resent-Message-ID: <"2qLj6.0.YC4.7Vb8o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1942 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 04:24 PM 8/23/96 -0400, Brad Parker wrote: > > >I've asked the guys at FCR (Bill Kirtley, kirtley@fcr.com and Paul Couto, >couto@fcr.com) to pick this up and "do the right thing", what ever that >might be. They're both doing lots with PPP on a daily basis and have >implemented multilink, ATCP, etc... I'd like to throw my hat in the ring to help out with this effort. I have just gotten done implementing ATCP for ES-IS and IS-IS connectivity and had several interesting go rounds with several ATCP client software implementations. Besides, Brad, myself and the guys at FCR used to all work together back at Cayman. As a start, I would like to see the following issues addressed (I would be more than willing to contribute text) in the next ATCP draft (should one come to fruition) : 1) Non-seed versus seed router configuration negotiation 2) DDP filter vector negotiation is broken. If you don't support filtering DDP broadcasts then you cannot NAK the request with a null vector because this means that you only support filtering ALL DDP broadcasts. Clearly this is not exactly what you want. 3) Tightening up text on ES-IS negotiations versus IS-IS negotations, in particular, how to handle the case where an end station tries to dial into the port you have configured for another router to dial into and vice versa. 4) How to handle the all too common case where an end system negotiates an appletalk address with a server and then completely ignores it and uses a different address. Ken Ken Siegel Switchblade Networks, Inc. 6 Lisa Drive Nashua, NH 03062 Phone: (603) 891-1500 (603) 888-6818 Internet: ksiegel@switchblade.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Aug 27 09:44:37 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id JAA23861; Tue, 27 Aug 1996 09:44:37 -0400 (EDT) Resent-Date: Tue, 27 Aug 1996 09:44:37 -0400 (EDT) Message-Id: <2.2.32.19960827134114.006994b0@tiac.net> X-Sender: ksiegel@tiac.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 09:41:14 -0400 To: ietf-ppp@MERIT.EDU From: Ken Siegel Subject: Error in my previous post on ATCP Resent-Message-ID: <"TGDkW3.0.Oq5.mjl8o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1943 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Folks, In throwing my hat in the ring for some ATCP rewrite work I proposed the following as a problem: " 2) DDP filter vector negotiation is broken. If you don't support filtering DDP broadcasts then you cannot NAK the request with a null vector because this means that you only support filtering ALL DDP broadcasts. Clearly this is not exactly what you want." The way I phrased this is incorrect. What I meant to say is broken is that if you request a single DDP type for broadcast filtering and the server does not filter THAT TYPE but DOES do DDP broadcast filtering then there is no way to NAK the request properly. Sorry for the confusion. Ken Ken Siegel Switchblade Networks, Inc. 6 Lisa Drive Nashua, NH 03062 Phone: (603) 891-1500 (603) 888-6818 Internet: ksiegel@switchblade.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 28 07:28:08 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id HAA12378; Wed, 28 Aug 1996 07:28:08 -0400 (EDT) Resent-Date: Wed, 28 Aug 1996 07:28:08 -0400 (EDT) Message-Id: <1.5.4.32.19960828122520.00666fac@radmail.rad.co.il> X-Sender: rongil@radmail.rad.co.il X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Aug 1996 14:25:20 +0200 To: ietf-ppp@MERIT.EDU From: Ron Gilaad Subject: PPP BACP - undefined issues Cc: mickrap@radmail.rad.co.il Resent-Message-ID: <"GEAfw3.0.413.gq29o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1944 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Dir Sir/Madam, Our company develop frame relay equipment and looking for a way to transfer frame relay over the ISDN BRI and PRI line in MLPPP. As i understand from the PPP BACP internet draft(MAY 1996), when an application decides to add a link to an MLPPP bundle, it first negotiates BACP (Send BACP CALL REQUEST) and only then tries to establish a physical connection. Afterwards a CALL STATUS INDICATION is sent to the peer. In case the application fails in establishing the physical connection, it sets the call status option of the CALL STATUS INDICATION as follows: - The status octet is set with the failure code. - The Action octet is set with a Retry indication. My questions are: 1. How does the peer react and what shall it do with each one of these setting. 2. In case the application decides to execute the retries mechanism. Why shall it inform the peer about it? Why not just keep on trying till link is established or a pre defined number of retries and inform the peer with the final decision if the physical link has been established or not. Sincerely, Ron Gilaad. =================================================================== | Ron Gilaad | FAX: 972-3-6475924,6498393 | | RAD data communications ltd. | PHONE: 972-3-6455432 (Office) | | 31 Habarzel St. | PHONE: 972-3-6040056 (Home) | | Tel-Aviv 69710 | E-mail: rongil@radmail.rad.co.il | | Israel | Finger: rongil@radmail.rad.co.il | =================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 28 14:13:25 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA19849; Wed, 28 Aug 1996 14:13:25 -0400 (EDT) Resent-Date: Wed, 28 Aug 1996 14:13:25 -0400 (EDT) To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-ppp@MERIT.EDU From: The IESG Subject: Protocol Action: The PPP Internetwork Packet Exchange Control Protocol (IPXCP) to Draft Standard Date: Wed, 28 Aug 1996 11:01:22 -0400 Sender: scoya@ietf.org Message-ID: <9608281101.aa17464@ietf.org> Resent-Message-ID: <"Oq9xu3.0.sr4.ym89o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1945 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IESG has approved The PPP Internetwork Packet Exchange Control Protocol (IPXCP) as a Draft Standard. This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Frank Kastenholz and Jeffrey Burgan. Technical Summary This protocol is a PPP Network Control Protocol. It is used to establish and configure a PPP link to carry the Novell IPX protocol. Working Group Summary This protocol is a product of the PPPEXT working group. There was no dissent in the working group, or the IETF Last call. Protocol Quality This protocol has been reviewed by Frank Kastenholz. There are many independent, interoperable implementations (demonstrated at several PPP bakeoffs). - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 28 20:21:41 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id UAA26009; Wed, 28 Aug 1996 20:21:41 -0400 (EDT) Resent-Date: Wed, 28 Aug 1996 20:21:41 -0400 (EDT) Message-ID: From: Steve Cobb To: "'Erik Olson'" Cc: "'ietf-ppp@merit.edu'" Subject: MS CHAP change password Date: Wed, 28 Aug 1996 17:20:13 -0700 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 Encoding: 35 TEXT Resent-Message-ID: <"GytSC1.0.7M6.EAE9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1946 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >ErikOlson in previous post> Interestingly, nobody has brought up the remote >"change password" >extensions that have been put into MS-CHAP. Now there's your security >breach. Any bad guy who finds out the old NT hash can proceed to change >(via MS-CHAP) the password hash to anything they want, i.e. something >which they know the unhashed version. SteveCobb> Note however that the change-password extensions cannot be initiated by the client, but only by the authenticating server. (The NT server initiates based on the expiration period set by the administrator.) So, it is not as easy as somehow figuring out the current hash and immediately changing the password. Hacker would have to intercede after user's password expires and before the true user logs on. Even if hacker pulls this off, he's no farther along than if he'd cracked the clear password in the first place, and at least true user will get a clue that his account's been monkeyed with when his old password doesn't work. The standard CHAP alternative is "remote user's password typically does not change" which I feel is far more dangerous. We do not dispute that in pure terms both the hashed and clear passwords represent a shared secret, nor do we claim it is any harder to determine a hashed secret than a clear secret. However, as a practical matter it requires less time, effort, and sophistication to abuse a clear password than a hashed one. If forced to choose, I would certainly rather have my password hash posted on a BBS than my clear text password. At least hackers would have to install some sleazy software to abuse it. Further, whether advisable or not, most people change passwords in a pattern, from say "mypassword96" to "mypassword97", thus knowledge of the clear password often helps hacker guess what the true user might choose for future passwords. However, knowledge of the current hash does not make it much easier to guess the next hash. > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Aug 28 23:28:47 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id XAA28756; Wed, 28 Aug 1996 23:28:47 -0400 (EDT) Resent-Date: Wed, 28 Aug 1996 23:28:47 -0400 (EDT) Date: Wed, 28 Aug 1996 21:28:26 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608290328.VAA17998@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: MS CHAP change password Resent-Message-ID: <"YFbsw2.0.017.bvG9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1947 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Steve Cobb > ... > We do not dispute that in pure terms both the hashed and clear passwords > represent a shared secret, nor do we claim it is any harder to determine > a hashed secret than a clear secret. However, as a practical matter it > requires less time, effort, and sophistication to abuse a clear password > than a hashed one. If forced to choose, I would certainly rather have > my password hash posted on a BBS than my clear text password. At least > hackers would have to install some sleazy software to abuse it. > Some of those premises may be right, but the implicit conclusion that there is some virtue in MS CHAP is wrong. It is reasonable, although not a significant security improvement, to keep the shared secret as obscure as possible, to use an MD5, MD4, or DES hash of whatever the user of a PPP "client" types, but that does not imply anything about the need or justification for MS CHAP. As I've written before, instead of forcing "clients" to use the weaker MD4 to digest the secret and challenge during the CHAP exchange, MicroSoft could instead have simply required clients MD4-hash an ASCII password, and then use that hash in standard MD5 CHAP. MicroSoft-smart clients could work just fine using MD5 CHAP to prove they know the same secret as NT servers. With a trivial change to utility software that must already exist on the NT "server" code, that would also have been 100% interoperable with non-MicroSoft-smart clients. Even people who do not agree with me that no negotiating would be necessary, must admit that Microsoft would have done better to define MS CHAP to be the same as MD5 CHAP except with the secret pre-hashed with DES or MD4. That would have been far easier to implement in clients. Insisting on MD4 for the challenge/response both delayed the appearance of PPP clients from Microsoft competators and reduced the security of the systems. (I don't know, but suspect those delays actually hurt Microsoft's business as much or more than its PPP implementing competators.) MS CHAP has no feature that is not already available in MD5 CHAP, or present by trivial modifications to user PPP "client" user interfaces. No changes to the LCP authentication negotiation or to CHAP itself were necessary to get exactly the same set of features implicitly claimed for MS CHAP. > Further, whether advisable or not, most people change passwords in a > pattern, from say "mypassword96" to "mypassword97", thus knowledge of > the clear password often helps hacker guess what the true user might > choose for future passwords. However, knowledge of the current hash > does not make it much easier to guess the next hash. That is wrong, except when attackers are incredibly stupid. While people often choose bad passwords, which makes dictionary attacks effective, a dictionary attack on a system that uses MD4(MD4(ASCII passwd),challenge)) is just as easy as a dictionary attack on a system that uses MD5(ASCII passwd,challenge). Only attackers that refuse to read the Microsoft description of MS CHAP might be slowed down. If I wanted to mount a dictionary attack on an NT PPP server, I'd start with one of the freely available dictionary attack software packages designed to hit DES passwords such as used by some kinds of UNIX (and I think some varieties of NT) authentication, and modify it to use MD4 instead of DES. (Isn't computing MD4(passwd) faster than the classic UNIX DES(passwd) because of the many iterations of DES?) The bad guy that knows or guesses the previous password was "mypassword96" can try "mypassword97" just as easily regardless of whether MS CHAP and so MD4(MD4(passwd),challenge)) is used (with MD4(passwd) pre-computed and stored on the "server" and so used as the shared secret). MS CHAP is fundamentally weaker than MD5 chap because it uses MD4, and because there are two "secrets" that an attacker can seak. The attacker can try to get the MD4(ASCII) secret stored on the NT server using any of the standard attacks from network or user-account security holes in NT to bribery or breaking and entering. The attacker can also use dictionary attacks to look for the ASCII secret that is stored nowhere but is just as powerful as the MD4 hash. Note that outside the PC world, people try to not give general users have accounts on firewall, keyservers, and PPP "servers". That is because for every security hole that can be exploited by bad guys over the net (e.g. by WWW browsers), there are 100's that are available to attackers who can run programs. Compare the number of CERT advisories about network attacks to the number of advisories about native attacks. Anyone who really cares about the security of the PPP server will not let people log onto it, or at least severely restrict what they can do on the system, removing all tools such as debugggers, compilers, profilers, and GUI system administration tools. This is not just a UNIX thing, but wisdom learned the hard way by people who have run popular operating systems throughout history. Weren't almost all of the CERT advisories on VMS about things that could be done only by running programs on the system instead of just sending packets? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 00:30:42 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id AAA29638; Thu, 29 Aug 1996 00:30:42 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 00:30:42 -0400 (EDT) Date: Wed, 28 Aug 1996 22:30:29 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199608290430.WAA18065@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: MS CHAP change password Resent-Message-ID: <"KhMtW.0.nE7.kpH9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1948 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I wrote: > ... Insisting on MD4 for the challenge/response both delayed > the appearance of PPP clients from Microsoft competators and reduced > the security of the systems. (I don't know, but suspect those delays > actually hurt Microsoft's business as much or more than its PPP > implementing competators.) Of course, my point was that I don't think the creation or requirement of MS CHAP involved malice, premediation, or even acceptance today of the fact that the bad effects were unnecessary. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 04:47:06 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA02294; Thu, 29 Aug 1996 04:47:06 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 04:47:06 -0400 (EDT) Message-Id: <1.5.4.32.19960829094451.006683cc@radmail.rad.co.il> X-Sender: rongil@radmail.rad.co.il X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 1996 11:44:51 +0200 To: ietf-ppp@MERIT.EDU, crich@shiva.com, karl@ascend.com, mpd@casc.com, kevin@ascend.com From: Ron Gilaad Subject: PPP BACP - unclear issue Resent-Message-ID: <"RA0803.0.aZ.6aL9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1949 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Dir Sirs/Madams, There is an unclear issue in the BACP draft. Consider the following scenario: An application decides to add a link to an MLPPP bundle. It send a BACP CALL REQUEST and receives OK by BACP CALL RESPONSE. The application tries to establish a physical connection, fails and sends a CALL STATUS INDICATION to the peer with a Retry indication. 1. Does the application MUST wait for the CALL STATUS RESPONSE before attempting to establish the connection, again? 2. If so, what happens in case the CALL STATUS RESPONSE is not received in a pre defined period of time? What is this period of time? Shall the application repeat sending CALL STATUS INDICATION? For how long? Sincerely, Ron Gilaad. =================================================================== | Ron Gilaad | FAX: 972-3-6475924,6498393 | | RAD data communications ltd. | PHONE: 972-3-6455432 (Office) | | 31 Habarzel St. | 972-3-6040056 (Home) | | Tel-Aviv 69710 | E-mail: rongil@radmail.rad.co.il | | Israel | | =================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 05:56:50 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id FAA03219; Thu, 29 Aug 1996 05:56:50 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 05:56:50 -0400 (EDT) Mime-Version: 1.0 Date: Thu, 29 Aug 1996 10:48:08 +0100 Message-ID: <22569210@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: PPP BACP - unclear issue To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"kMRno1.0.0o.oaM9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1950 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ron Gilaad writes:> >There is an unclear issue in the BACP draft. > >Consider the following scenario: > >An application decides to add a link to an MLPPP bundle. It send a BACP CALL >REQUEST and receives OK by BACP CALL RESPONSE. The application tries to >establish a physical connection, fails and sends a CALL STATUS INDICATION to >the peer with a Retry indication. > >1. Does the application MUST wait for the CALL STATUS RESPONSE before >attempting to establish the connection, again? > >2. If so, what happens in case the CALL STATUS RESPONSE is not received in >a pre defined period of time? What is this period of time? Shall the >application repeat sending CALL STATUS INDICATION? For how long? My interpretation is: 1) No - retry the call regardless of whether the Call response is Received. 2) The Call Status Indication should be retransmitted with the information about the most recent call attempt in the event of failing to receive the Call Status response. Am I correct ? I am beginning to wonder whether the use of the Ident field in the Call Status Indication is ideal - would it be better to include the Ident from the original call/callback request as a separate field within the Call Status Indication ? The ident could then be used to distinguish between retransmissions and a new call status after a retry. On the other hand, it may not be necessary to tell the difference. Jonathan Goodchild - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 10:21:48 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id KAA06305; Thu, 29 Aug 1996 10:21:48 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 10:21:48 -0400 (EDT) Message-Id: <9608291720.AA4723@SMTP.shiva.com> To: Ron Gilaad Cc: ietf-ppp , crich , karl , mpd , kevin From: Robert Webster/Shiva Corporation Date: 29 Aug 96 10:20:24 EDT Subject: Re: PPP BACP - unclear issue Mime-Version: 1.0 Content-Type: Text/Plain Resent-Message-ID: <"13EuZ2.0.9Y1.hTQ9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1951 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >Dir Sirs/Madams, > >There is an unclear issue in the BACP draft. > >Consider the following scenario: > >An application decides to add a link to an MLPPP bundle. It send a BACP CALL >REQUEST and receives OK by BACP CALL RESPONSE. The application tries to >establish a physical connection, fails and sends a CALL STATUS INDICATION to >the peer with a Retry indication. > >1. Does the application MUST wait for the CALL STATUS RESPONSE before >attempting to establish the connection, again? The application should wait for the CALL STATUS RESPONSE for a short time, and then try to establish the connection again. The CALL STATUS RESPONSE might have been lost, so the Caller shouldn't wait forever before retrying. >2. If so, what happens in case the CALL STATUS RESPONSE is not received in a >pre defined period of time? What is this period of time? Shall the >application repeat sending CALL STATUS INDICATION? For how long? If the CALL STATUS RESPONSE is not received after a timeout, the CALL STATUS INDICATION should be resent. The timeout should vary depending on the link type being used. In ShivaPPP, I retry sending the CALL STATUS INDICATION five times. Some implementations retry this 10 times, I believe. Rob Webster Shiva Corp. >Sincerely, >Ron Gilaad. >=================================================================== > Ron Gilaad | FAX: 972-3-6475924,6498393 | >| RAD data communications ltd. | PHONE: 972-3-6455432 (Office) | >| 31 Habarzel St. | 972-3-6040056 (Home) | >| Tel-Aviv 69710 | E-mail: rongil@radmail.rad.co.il | >| Israel | | >=================================================================== - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 11:37:52 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA08065; Thu, 29 Aug 1996 11:37:52 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 11:37:52 -0400 (EDT) X-Sender: kirtleypop@fcr.fcr.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 1996 11:38:21 -0400 To: Ken Siegel From: kirtley@fcr.com (Bill Kirtley) Subject: Re: ATCP status? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"2jQ4x.0.hz1.AbR9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1952 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi Ken- Thanks for the offer. Your experiences should be helpful. At 10:02 PM 8/26/96, Ken Siegel wrote: > >I'd like to throw my hat in the ring to help out with this effort. >I have just gotten done implementing ATCP for ES-IS and IS-IS >connectivity and had several interesting go rounds with several >ATCP client software implementations. Besides, Brad, myself and >the guys at FCR used to all work together back at Cayman. > >As a start, I would like to see the following issues addressed >(I would be more than willing to contribute text) in the next >ATCP draft (should one come to fruition) : > >1) Non-seed versus seed router configuration negotiation Are you suggesting an option where each peer would negotiate whether it would behave as a seed router? Is this something a router with multiple interfaces is going to want to reconfigure as links come and go? >2) DDP filter vector negotiation is broken. If you don't >support filtering DDP broadcasts then you cannot NAK the >request with a null vector because this means that you >only support filtering ALL DDP broadcasts. Clearly this >is not exactly what you want. Why would you support filtering some types but not others? If you don't support filtering at all, you can REJ the option. Otherwise, if the peer asks you to filter ZIP broadcasts, it's his nickel, do it for him. Is there a situation where filtering some types would be harder than others? >3) Tightening up text on ES-IS negotiations versus IS-IS >negotations, in particular, how to handle the case where >an end station tries to dial into the port you have configured >for another router to dial into and vice versa. First, is this a situation where you find it convenient to distinguish between "dialup" and "WAN" ports before connection time? Is it a port allocation issue, or a configuration issue? Assuming so, couldn't you setup authentication on a per port basis, and have a distinction between dialup and WAN accounts? Here you could say that only dialup users would be rejected on ports reserved for WAN connections. >4) How to handle the all too common case where an end system >negotiates an appletalk address with a server and then completely >ignores it and uses a different address. I presume you're talking about a broken implementation. Once an address has been agreed upon it should be used, shouldn't it? Can't this be handled the same way an invalid "from" address is handled on any other port? I would expect to silently discard such, possibly noting them in a diagnostics log. Regards, Bill ....................................................................... Bill Kirtley : FCR Software, Inc. kirtley@fcr.com : 222 Third Street, Suite 3130, Cambridge, MA 02142 http://www.fcr.com : Tel: (617) 494-1300 Fax: (617) 494-9592 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 11:51:07 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id LAA08334; Thu, 29 Aug 1996 11:51:07 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 11:51:07 -0400 (EDT) Date: Thu, 29 Aug 96 16:49:35 BST From: georgew@spider.co.uk (George Wilkie) Message-Id: <9608291549.AA03236@queenbee.spider.co.uk> To: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU Subject: Re: PPP BACP - unclear issue Newsgroups: from.ietf-ppp In-Reply-To: <29Aug9610031718672@crab.spider.co.uk> Organization: Shiva Europe Limited Resent-Message-ID: <"BQzi.0.y12.enR9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1953 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In article <29Aug9610031718672@crab.spider.co.uk> you write: >Ron Gilaad writes:> >>There is an unclear issue in the BACP draft. >> >>Consider the following scenario: >> >>An application decides to add a link to an MLPPP bundle. It send a BACP CALL >>REQUEST and receives OK by BACP CALL RESPONSE. The application tries to >>establish a physical connection, fails and sends a CALL STATUS INDICATION to >>the peer with a Retry indication. >> >>1. Does the application MUST wait for the CALL STATUS RESPONSE before >>attempting to establish the connection, again? >> >>2. If so, what happens in case the CALL STATUS RESPONSE is not received in >>a pre defined period of time? What is this period of time? Shall the >>application repeat sending CALL STATUS INDICATION? For how long? > >My interpretation is: > >1) No - retry the call regardless of whether the Call response is Received. > >2) The Call Status Indication should be retransmitted with the information >about the most recent call attempt in the event of failing to receive the >Call Status response. > >Am I correct ? I agree. My implementation does it this way. > >I am beginning to wonder whether the use of the Ident field in the Call >Status Indication is ideal - would it be better to include the Ident from >the original call/callback request as a separate field within the Call >Status Indication ? The ident could then be used to distinguish between >retransmissions and a new call status after a retry. On the other hand, it >may not be necessary to tell the difference. > I don't think it matters. All the peer needs to know is when you have stopped retrying. -- George Wilkie georgew@europe.shiva.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 12:12:20 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA08872; Thu, 29 Aug 1996 12:12:20 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 12:12:20 -0400 (EDT) From: jgardner@BayNetworks.com (Jim Gardner) Message-Id: <9608291611.AA02507@pobox.BayNetworks.com> Subject: Re: PPP BACP - unclear issue To: georgew@spider.co.uk (George Wilkie) Date: Thu, 29 Aug 1996 12:23:44 -0400 (EDT) Cc: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU In-Reply-To: <9608291549.AA03236@queenbee.spider.co.uk> from "George Wilkie" at Aug 29, 96 04:49:35 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Resent-Message-ID: <"WoJPG3.0.LA2.W5S9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1954 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > >I am beginning to wonder whether the use of the Ident field in the Call > >Status Indication is ideal - would it be better to include the Ident from > >the original call/callback request as a separate field within the Call > >Status Indication ? The ident could then be used to distinguish between > >retransmissions and a new call status after a retry. On the other hand, it > >may not be necessary to tell the difference. > > > > I don't think it matters. > All the peer needs to know is when you have stopped retrying. > -- If this is really the case, why not hold off sending a CALL STATUS INDICATION until the retries have been attempted? It seems simpler, with less messaging. Jim Gardner - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 12:59:51 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id MAA09934; Thu, 29 Aug 1996 12:59:51 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 12:59:51 -0400 (EDT) From: Scott Jackson Message-Id: <199608291659.JAA04050@puli.cisco.com> Subject: Re: PPP BACP - unclear issue To: ietf-ppp@MERIT.EDU Date: Thu, 29 Aug 1996 09:59:09 -0700 (PDT) In-Reply-To: <9608291611.AA02507@pobox.BayNetworks.com> from "Jim Gardner" at Aug 29, 96 12:23:44 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"CIeGp2.0.rQ2._nS9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1955 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > >I am beginning to wonder whether the use of the Ident field in the Call > > >Status Indication is ideal - would it be better to include the Ident from > > >the original call/callback request as a separate field within the Call > > >Status Indication ? The ident could then be used to distinguish between > > >retransmissions and a new call status after a retry. On the other hand, it > > >may not be necessary to tell the difference. > > > > > > > I don't think it matters. > > All the peer needs to know is when you have stopped retrying. > > -- > > If this is really the case, why not hold off sending a CALL STATUS INDICATION > until the retries have been attempted? It seems simpler, with less > messaging. While it may indeed result in less messaging, the use of the CallStatusIndication after each call attempt provides ones peer with possible information as to why a call failed. Also, a peer attempting to dial may decide to give up and offer no further retries if a response is not obtained for a CallStatusIndication. Scott Jackson - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 13:39:10 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id NAA10878; Thu, 29 Aug 1996 13:39:10 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 13:39:10 -0400 (EDT) Date: Thu, 29 Aug 1996 18:38:46 +0100 (BST) From: Resham Message-Id: <199608291738.SAA01222@asterix.ftel.co.uk> To: ietf-ppp@MERIT.EDU Subject: PPP over ATM X-Sun-Charset: US-ASCII Resent-Message-ID: <"KmHCN.0.hf2.wMT9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1956 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU ----- Begin Included Message ----- From R.Hayre@ftel.co.uk Thu Aug 29 18:33 BST 1996 Date: Thu, 29 Aug 1996 18:33:15 +0100 (BST) From: Resham To: fbaker@acc.com Subject: PPP over ATM Cc: resham@ftel.co.uk After reading RFC 1619, I was wondering whether anybody had looked at PPP over ATM. I have not come across any standards of PPP over ATM. I was considering a problem where we provide access to residential customers to the Internet over ATM. There are two ways of doing this either through Permamnet Virtual Circuits (PVCs) or Switched Virtual Circuits (SVCs). I was planning on intialy doing this over PVCs that could use PPP to negoiate IP addresses for each customer. Then Clear the address down when it was not used, simliar to the way PCs do it. e.g. ___________ | IP | |___________| | PPP | |___________| | AAL5 | |___________| | ATM | |___________| But I haven't come across any standards that provide this form of access. The PPP could be provided transparently and sent over the ATM Network to an Internet Service Provider (ISP) who can basicaly put the message back together. The PPP layer could be implemented as part of the Service Specific Convergence Sub-layer in ATM. If you have any information I would appreciate it. Regards Resham ----- End Included Message ----- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 14:08:31 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id OAA11766; Thu, 29 Aug 1996 14:08:31 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 14:08:31 -0400 (EDT) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <9608291807.AA23019@hobbit> Subject: Re: PPP over ATM To: R.Hayre@ftel.co.uk (Resham) Date: Thu, 29 Aug 1996 14:07:22 -0400 (EDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199608291738.SAA01222@asterix.ftel.co.uk> from "Resham" at Aug 29, 96 06:38:46 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"6A0yK2.0.at2.PoT9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1957 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU :-) After reading RFC 1619, I was wondering whether anybody had :-) looked at PPP over ATM. I have not come across any standards of PPP over ATM. At one time I could have used something like PPP/ML/BACP for managing ATM circuits. Please note though that the link speed parameter of BACP is a 16-bit number in Kbps, so it is limited to 64Mbps. Not much call for PPPMLPing big pipes these days, but in future, who knows? -Chris Sullivan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 15:39:35 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA14800; Thu, 29 Aug 1996 15:39:35 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 15:39:35 -0400 (EDT) From: jgardner@BayNetworks.com (Jim Gardner) Message-Id: <9608291938.AA10517@pobox.BayNetworks.com> Subject: Re: PPP BACP - unclear issue To: sjackson@cisco.com (Scott Jackson) Date: Thu, 29 Aug 1996 15:51:03 -0400 (EDT) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199608291659.JAA04050@puli.cisco.com> from "Scott Jackson" at Aug 29, 96 09:59:09 am X-Mailer: ELM [version 2.4 PL21] Content-Type: text Resent-Message-ID: <"owoTO2.0.sc3.o7V9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1958 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > > >I am beginning to wonder whether the use of the Ident field in the Call > > > >Status Indication is ideal - would it be better to include the Ident from > > > >the original call/callback request as a separate field within the Call > > > >Status Indication ? The ident could then be used to distinguish between > > > >retransmissions and a new call status after a retry. On the other hand, it > > > >may not be necessary to tell the difference. > > > > > > > > > > I don't think it matters. > > > All the peer needs to know is when you have stopped retrying. > > > -- > > > > If this is really the case, why not hold off sending a CALL STATUS INDICATION > > until the retries have been attempted? It seems simpler, with less > > messaging. > > While it may indeed result in less messaging, the use of the > CallStatusIndication after each call attempt provides ones peer with possible > information as to why a call failed. > > Also, a peer attempting to dial may decide to give up and offer no further > retries if a response is not obtained for a CallStatusIndication. > It just seems the time spent sending separate CallStatusIndication msgs would be better spent attempting retries...It has already been agreed that more bandwidth is needed, the faster it is provided, the better. The CallStatusIndication could be permitted to contain multiple Call-Status options to indicate the Status of each attempt. Jim Gardner - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 15:48:11 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id PAA15076; Thu, 29 Aug 1996 15:48:11 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 15:48:11 -0400 (EDT) Message-Id: <2.2.32.19960829194605.0068aab8@tiac.net> X-Sender: ksiegel@tiac.net X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 1996 15:46:05 -0400 To: kirtley@FCR.COM (Bill Kirtley) From: Ken Siegel Subject: Re: ATCP status? Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"S7aHh.0.Ih3.tFV9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1959 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:38 AM 8/29/96 -0400, Bill Kirtley wrote: >> >>I'd like to throw my hat in the ring to help out with this effort. >>I have just gotten done implementing ATCP for ES-IS and IS-IS >>connectivity and had several interesting go rounds with several >>ATCP client software implementations. Besides, Brad, myself and >>the guys at FCR used to all work together back at Cayman. >> >>As a start, I would like to see the following issues addressed >>(I would be more than willing to contribute text) in the next >>ATCP draft (should one come to fruition) : >> >>1) Non-seed versus seed router configuration negotiation > >Are you suggesting an option where each peer would negotiate whether it >would behave as a seed router? Is this something a router with multiple >interfaces is going to want to reconfigure as links come and go? Well, there are a number of ways one can envision doing this. One specific way to tell is by looking at the address passed in the address option. If it is 0, then you may presume you have an end station. What do you pass if you are a non-seed router? You don't really "know" the network at that point but you also don't want to "look" like an end system by passing a 0 for the appletalk address. A separate option is one candidate to negotiate this. An alternative is to use the address passed to the peer you are connecting to to communicate this. A non-seed router could pick a node number and a network in the startup range. A seed router would pick a node number and a network number NOT in the startup range. This has been implemented and is working in at least one implementation. > >>2) DDP filter vector negotiation is broken. If you don't >>support filtering DDP broadcasts then you cannot NAK the >>request with a null vector because this means that you >>only support filtering ALL DDP broadcasts. Clearly this >>is not exactly what you want. > >Why would you support filtering some types but not others? If you don't >support filtering at all, you can REJ the option. Otherwise, if the peer >asks you to filter ZIP broadcasts, it's his nickel, do it for him. > >Is there a situation where filtering some types would be harder than others? > No. A specific example might illustrate where this came up. A particular ATCP client wanted to negotiate RTMP filtering. Now, if a client does not get RTMP's after the initial ZIP queries it thinks that there is no router out there. It can get around this by doing the queries itself. What we wanted to do was to filter out extraneous RTMP broadcast frames from going down the PPP link so that the client always had the address of the designated router on that link but did not have to generate RTMP requests on its own. Basically we just filtered out all broadcast RTMP frames from any router that was not the designated router on this link. So we wanted to NAK the request to filter RTMP broadcasts so we could allow just the designated router broadcasts down the link. Unfortunately, there is no way to do this given that NAKing a request for a single DDP type in the broadcast filter would require returning an empty vector and, hence, tells the client you really want to filter ALL DDP broadcasts. >>3) Tightening up text on ES-IS negotiations versus IS-IS >>negotations, in particular, how to handle the case where >>an end station tries to dial into the port you have configured >>for another router to dial into and vice versa. > >First, is this a situation where you find it convenient to distinguish >between "dialup" and "WAN" ports before connection time? Is it a port >allocation issue, or a configuration issue? > Well, the problem is, if you allow multiple routers to dial into a single port to another router then this means that there must be some phone line that an end station could dial into. How would we distinguish that we are not talking to an end-station instead of a non-seed router? Right now, end stations pass an address of 0 in address configuration which gets NAKed with the "correct" address. A seed router can request a specific network number and address to another seed router. But, once again, what about the non-seed router which does not know its net? If this dial-in port is a port we want to reserve for router only dial in, how do we distinguish it from an end station. >Assuming so, couldn't you setup authentication on a per port basis, and >have a distinction between dialup and WAN accounts? Here you could say >that only dialup users would be rejected on ports reserved for WAN >connections. > What is the difference between a dial-up account and a WAN account? If the connections are permanent (which is what you may mean) then the negotiation is a non-issue because no other PPP peer could ever use the link. This only applies to dial-up. The specific example is a bunch of satellite office routers dialing up to a home office router to get information to or from one or more servers for database updates and then hanging up. We want the satellite routers seeded from the main office so that the link can be used by more than one satellite office. >>4) How to handle the all too common case where an end system >>negotiates an appletalk address with a server and then completely >>ignores it and uses a different address. > >I presume you're talking about a broken implementation. Once an address >has been agreed upon it should be used, shouldn't it? > Yes, agreed, it should be but this is not what is happening in practice. We could try and be rigid and just reject frames that are not from the address we assigned but that will not make customers happy. >Can't this be handled the same way an invalid "from" address is handled on >any other port? I would expect to silently discard such, possibly noting >them in a diagnostics log. No, because some commonly used ATCP implementations do this. Customers would not be happy about this at all. I wish it were not so. Whether or not it is right or wrong, the behavior and how to handle it properly should be documented in the ATCP spec (IMHO). Ken Ken Siegel Switchblade Networks, Inc. 6 Lisa Drive Nashua, NH 03062 Phone: (603) 891-1500 Internet: ksiegel@switchblade.com URL: www.switchblade.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Aug 29 17:28:12 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id RAA17395; Thu, 29 Aug 1996 17:28:12 -0400 (EDT) Resent-Date: Thu, 29 Aug 1996 17:28:12 -0400 (EDT) Date: Thu, 29 Aug 1996 14:33:31 -0700 (PDT) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1969 PPP - DES Encryption Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"vCWNF.0.XF4.ejW9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1960 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I am sorry to use this forum for this request, but I do not know a better method to use. We are interested in testing with folks who have implemented RFC1669 over ISDN. If so could you e-mail at pmr@flowpoint.com. In additon, does anyone know an RFC that should be used with 1969 to manage the DES keys. Philip Rakity FlowPoint - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Aug 30 04:15:29 1996 Received: (from slist@localhost) by merit.edu (8.7.5/merit-2.0) id EAA23837; Fri, 30 Aug 1996 04:15:29 -0400 (EDT) Resent-Date: Fri, 30 Aug 1996 04:15:29 -0400 (EDT) Date: Fri, 30 Aug 96 09:14:28 BST From: georgew@spider.co.uk (George Wilkie) Message-Id: <9608300814.AA04415@queenbee.spider.co.uk> To: jgardner@BayNetworks.com, ietf-ppp@MERIT.EDU Subject: Re: PPP BACP - unclear issue Newsgroups: from.ietf-ppp In-Reply-To: <29Aug961945488742@crab.spider.co.uk> Organization: Shiva Europe Limited Resent-Message-ID: <"mODlk.0.Bq5.PCg9o"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/1961 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In article <29Aug961945488742@crab.spider.co.uk> you write: >> >> > > >I am beginning to wonder whether the use of the Ident field in the Call >> > > >Status Indication is ideal - would it be better to include the Ident from >> > > >the original call/callback request as a separate field within the Call >> > > >Status Indication ? The ident could then be used to distinguish between >> > > >retransmissions and a new call status after a retry. On the other hand, it >> > > >may not be necessary to tell the difference. >> > > > >> > > >> > > I don't think it matters. >> > > All the peer needs to know is when you have stopped retrying. >> > > -- >> > >> > If this is really the case, why not hold off sending a CALL STATUS INDICATION >> > until the retries have been attempted? It seems simpler, with less >> > messaging. >> >> While it may indeed result in less messaging, the use of the >> CallStatusIndication after each call attempt provides ones peer with possible >> information as to why a call failed. >> >> Also, a peer attempting to dial may decide to give up and offer no further >> retries if a response is not obtained for a CallStatusIndication. >> > >It just seems the time spent sending separate CallStatusIndication msgs >would be better spent attempting retries...It has already been agreed >that more bandwidth is needed, the faster it is provided, the better. > >The CallStatusIndication could be permitted to contain multiple >Call-Status options to indicate the Status of each attempt. > The problem with that is that the peer doesn't know how long it should wait for a status indication before assuming the caller has given up trying to call and any status indications sent have been lost. So I think it is important to send a status indication after every attempt. It doesn't need to hold up trying another call. If there is no response to the previous indication when the next call fails, I just start sending the next indication, while immediately trying the next again call if appropriate. There may be an argument for putting in the status of both failed calls in this case, but that is probably overkill. -- George Wilkie georgew@europe.shiva.com - - - - - - - - - - - - - - - - -