From owner-ietf-ppp-outgoing@merit.edu Sun Oct 3 00:40:52 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1A5415DDE4; Sun, 3 Oct 1999 00:40:52 -0400 (EDT) Received: from intra0.extant.net (unknown [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 7D78B5DDB4 for ; Sun, 3 Oct 1999 00:40:50 -0400 (EDT) Received: from karl ([209.116.97.137]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA4234; Sun, 3 Oct 1999 00:40:40 -0400 Message-Id: <4.2.0.58.19991003003646.041f52a0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 03 Oct 1999 00:40:35 -0400 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: L2TP Working Group Cc: l2tp@ipsec.org, Thomas Narten , Erik Nordmark Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The PPPEXT Working Group is splitting. All L2TP-related issues will now be handled by the new L2TP Extensions (L2TPEXT) Working Group, chaired by Mark Townsley. Karl Fox PPPEXT Chair Here's the new group's charter: >Layer 2 Tunneling Protocol Extensions (l2tpext) > >Chair: >W. Mark Townsley >Townsley@cisco.com > >Email list: > >To send mail to the entire list: l2tp@ipsec.org >To subscribe: l2tp-request@ipsec.org >Archive: http://www.ipsec.org/email/l2tp/ > >Description of Working Group: > >The Layer 2 Tunneling Protocol (L2TP, RFC 2661) is a protocol for >tunneling PPP (RFC 1661) sessions over various network types. The group >will provide a forum for discussion and development of extensions to >L2TP, and actively advance the L2TP base protocol to Internet Standard. > >The group will: > >Define and advance standard MIB for L2TP management. > >Produce documents describing how L2TP operates over link types other >than IP (e.g., ATM, Frame Relay, etc.) > >Identify and define specific parameters and modes of IPsec in order to >aid interoperability when IPsec is used to secure L2TP traffic. > >Define and review the definition of any additional IETF AVPs which are >of interest to the group. > >Milestones: > >Oct 99 - Advance L2TP MIB to Proposed Standard > (already requested in pppext) >Feb 00 - Advance L2TP Security to Proposed Standard >May 00 - Advance L2TP over ATM and Frame Relay to Proposed Standard >Sept 00 - Advance L2TP to Draft Standard > >Internet-Drafts: > >1. http URL:draft-ietf-radius-tunnel-imp-05.txt > Title: Implementation of L2TP Compulsory Tunneling via RADIUS >2. http URL:draft-ietf-pppext-l2tp-mib-05.txt > Title: Layer Two Tunneling Protocol 'L2TP' Management Information >3. http URL:draft-ietf-pppext-l2tp-atm-02.txt > Title: L2TP Over AAL5 and FUNI >4. http URL:draft-ietf-pppext-mppp-01.txt > Title: Mobile PPP (MPPP) >5. http URL:draft-ietf-pppext-l2tp-atmext-01.txt > Title: Layer Two Tunneling Protocol : > ATM access network extensions. >6. http URL:draft-ietf-pppext-l2tp-security-04.txt > Title: Securing L2TP using IPSEC >7. http URL:draft-ietf-pppext-l2tp-mpls-02.txt > Title: Layer Two Tunneling Protocol ''L2TP'' Multi-Protocol Label > Switchi... >8. http URL:draft-ietf-pppext-l2tp-fr-02.txt > Title: Layer Two Tunneling Protocol (L2TP) over Frame Relay >9. http URL:draft-ietf-pppext-l2tp-ds-03.txt > Title: Layer Two Tunneling Protocol ''L2TP'' IP Differential > Services E... Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Tue Oct 5 12:01:27 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5B4EB5DE89; Tue, 5 Oct 1999 12:01:27 -0400 (EDT) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by segue.merit.edu (Postfix) with ESMTP id D72FE5DEB2 for ; Tue, 5 Oct 1999 12:01:23 -0400 (EDT) Received: from vies194a.sie.siemens.at (root@firix-hme0 [10.1.140.1]) by zwei.siemens.at with ESMTP id SAA24968 for ; Tue, 5 Oct 1999 18:02:41 +0200 (MET DST) Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2448.0) id <4BLV9SA7>; Tue, 5 Oct 1999 18:01:19 +0200 Message-ID: From: Klausberger Walter To: ietf-ppp@merit.edu Subject: PPP MS Callback Date: Tue, 5 Oct 1999 18:01:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > Hi, > > I tried to get some information on MS Callback, but all I found was an old > Draft from the PPP extension working group, which seems to be quite > outdated. > > Proposal for Callback Control Protocol (CBCP) > draft-ietf-pppext-callback-cp-02.txt > > Is there a newer version of this paper, or is there something better? > Is anything new implemented in Windows 2000 regarding Callback? > > Please help me to find the answers > with best regards > Walter > > ----------------------------------- > D.I. Walter Klausberger > Siemens AG Austria PSE EZE CN > A-1194 Vienna, Boschstrasse 10 > Tel.: +43(1)1707-42683 > Fax.: +43(1)1707-55265 > Mail: walter.klausberger@siemens.at > ----------------------------------- > From owner-ietf-ppp-outgoing@merit.edu Tue Oct 5 15:37:11 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 926F15DEC3; Tue, 5 Oct 1999 15:37:10 -0400 (EDT) Received: from pinky.rte.microsoft.com (unknown [131.107.152.16]) by segue.merit.edu (Postfix) with ESMTP id 41B455DEC0 for ; Tue, 5 Oct 1999 15:36:24 -0400 (EDT) Received: from localhost (gwz@localhost) by pinky.rte.microsoft.com (8.7.6/8.7.3) with SMTP id MAA07598; Tue, 5 Oct 1999 12:25:15 -0700 (PDT) X-Authentication-Warning: pinky.rte.microsoft.com: gwz owned process doing -bs Date: Tue, 5 Oct 1999 12:25:15 -0700 (PDT) From: Glen Zorn To: Klausberger Walter Cc: ietf-ppp@merit.edu Subject: Re: PPP MS Callback In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Tue, 5 Oct 1999, Klausberger Walter wrote: > > Hi, > > > > I tried to get some information on MS Callback, but all I found was an old > > Draft from the PPP extension working group, which seems to be quite > > outdated. > > > > Proposal for Callback Control Protocol (CBCP) > > draft-ietf-pppext-callback-cp-02.txt > > > > Is there a newer version of this paper, or is there something better? No. > > Is anything new implemented in Windows 2000 regarding Callback? No. BTW, this isn't really the right forum: a better place to ask these kinds of questions would be the vendor in question. > > > > Please help me to find the answers > > with best regards > > Walter > > > > ----------------------------------- > > D.I. Walter Klausberger > > Siemens AG Austria PSE EZE CN > > A-1194 Vienna, Boschstrasse 10 > > Tel.: +43(1)1707-42683 > > Fax.: +43(1)1707-55265 > > Mail: walter.klausberger@siemens.at > > ----------------------------------- > > > > From owner-ietf-ppp-outgoing@merit.edu Fri Oct 8 06:53:07 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1082B5DDBB; Fri, 8 Oct 1999 06:53:06 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 6A6525DDB9 for ; Fri, 8 Oct 1999 06:53:05 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14401; Fri, 8 Oct 1999 06:53:04 -0400 (EDT) Message-Id: <199910081053.GAA14401@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mschap-v2-04.txt Date: Fri, 08 Oct 1999 06:53:04 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Microsoft PPP CHAP Extensions, Version 2 Author(s) : G. Zorn Filename : draft-ietf-pppext-mschap-v2-04.txt Pages : 21 Date : 07-Oct-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS- CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication. The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-mschap-v2-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-mschap-v2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mschap-v2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991007081913.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mschap-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mschap-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991007081913.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Fri Oct 8 10:44:44 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 120565DF05; Fri, 8 Oct 1999 10:41:01 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 290D75DF0B for ; Fri, 8 Oct 1999 10:39:13 -0400 (EDT) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAABE8; Fri, 8 Oct 1999 10:39:13 -0400 Message-Id: <4.2.0.58.19991008103611.042807f0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 08 Oct 1999 10:38:55 -0400 To: Thomas Narten , Erik Nordmark From: "Karl Fox" Subject: Microsoft PPP CHAP Extensions, Version 2 to Informational Cc: ietf-ppp@merit.edu, Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that Microsoft PPP CHAP Extensions, Version 2, draft-ietf-pppext-mschap-v2-04.txt, be advanced to Informational. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Fri Oct 8 17:30:10 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 378B45DD9D; Fri, 8 Oct 1999 17:30:10 -0400 (EDT) Received: from abraham.cs.berkeley.edu (abraham.CS.Berkeley.EDU [128.32.37.121]) by segue.merit.edu (Postfix) with ESMTP id 4CEFF5DDA2 for ; Fri, 8 Oct 1999 17:29:56 -0400 (EDT) Received: from blowfish.isaac.cs.berkeley.edu (blowfish.isaac.cs.berkeley.edu [169.229.3.195]) by abraham.cs.berkeley.edu (8.8.6/8.8.6) with ESMTP id OAA13126 for ; Fri, 8 Oct 1999 14:29:27 -0700 Received: (from daw@localhost) by blowfish.isaac.cs.berkeley.edu (8.8.7/8.8.7) id OAA00290; Fri, 8 Oct 1999 14:07:03 -0700 From: David Wagner Message-Id: <199910082107.OAA00290@blowfish.isaac.cs.berkeley.edu> Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt To: ietf-ppp@merit.edu Date: Fri, 8 Oct 1999 21:06:59 +0000 () In-Reply-To: <199909220309.UAA13186@blowfish.isaac.cs.berkeley.edu> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu In article , Glen Zorn wrote: > On Wed, 22 Sep 1999, David Wagner wrote: > > The MPPE key derivation process uses a fixed prefix, 0xD1269E, to > > derive 40-bit RC4 session keys. > > > > I find this use of a "magic number" very suspicious. Where did > > this value come from? > > Nobody knows where it came from. It's been suggested that it was picked > out of thin air by someone who left the company a long time ago. As far > as anyone knows there are no "special properties". On the contrary, my preliminary statistical tests show two "special properties" for the class of RC4 keys starting with prefix 0xD1269E: * The first byte of output takes on the value 0x09 with prob. 0.0054, which is noticeably higher than the 1/256 = 0.0039 probability you get for a secure cipher (or for RC4 with a random prefix). * The RC4 key schedule mixes some entries in the state table poorly, for this class of keys. For instance, S[1] = 0xF8 holds with prob. 1/e = 0.38, and S[2] = 0x98 holds with a similarly large probability. Neither of these seem directly usable in any practical attack on the cipher. Still, I find them suspicious, and perhaps indicative of more subtle flaws. It is these special properties of the 0xD1269E prefix which raises a red flag in my mind. From owner-ietf-ppp-outgoing@merit.edu Fri Oct 8 22:48:13 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 63CA05DDA8; Fri, 8 Oct 1999 22:48:13 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 90A805DD9D for ; Fri, 8 Oct 1999 22:48:11 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id UAA24864 for ietf-ppp@merit.edu env-from ; Fri, 8 Oct 1999 20:48:10 -0600 (MDT) Date: Fri, 8 Oct 1999 20:48:10 -0600 (MDT) From: Vernon Schryver Message-Id: <199910090248.UAA24864@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: David Wagner > On the contrary, my preliminary statistical tests show two "special properties" > for the class of RC4 keys starting with prefix 0xD1269E: > > * The first byte of output takes on the value 0x09 with prob. 0.0054, > which is noticeably higher than the 1/256 = 0.0039 probability you > get for a secure cipher (or for RC4 with a random prefix). > > * The RC4 key schedule mixes some entries in the state table poorly, > for this class of keys. For instance, S[1] = 0xF8 holds with prob. > 1/e = 0.38, and S[2] = 0x98 holds with a similarly large probability. > > Neither of these seem directly usable in any practical attack on the cipher. > Still, I find them suspicious, and perhaps indicative of more subtle flaws. > > It is these special properties of the 0xD1269E prefix which raises a red flag > in my mind. That's interesting in an academic sense. (Not pejoratively "academic," since such "special properties" of major cyphers like RC4 are important.) (I assume the implication that RC4 with reasonably sized keys is insecure in the phrase "for a secure cipher (or for RC4" was not intended.) However, what about Greg Zorn's overriding point? How can it be of more than historical, sociological, or political interest whether someone at Microsoft chose especially weak 40-bit keys for MPPE, instead of someone's birthday or the next value from some random process? In both theory and in practical demonstrations, 40-bit RC4 has such poor security that it is almost a joke. Isn't the expected time to brute-force 40-bit RC4 less than a dozen hours if you have a gross or two of mid-1990's workstations, and only a week or two if you're limited to a single machine? Given the increase in CPU clock speeds for small cheap, computers since the 40-bit RC4 brute forcing excitement of 1996, or Deepcrack, it seems safe to assume that anyone who really cares about cracking 40-bit RC4 keys doesn't care what prefix might be used and can crack 40-bit RC4 key in real time. Deepcrack breaks 56-bit DES in 56 hours. An RC4-Deepcrack version as fast could break 40-bit RC4 in 36 hours/256=10 minutes. With a couple dozen RC4-Deepcracks you could break any 40-bit RC4 session key quickly enough to modify packets as they fly by, regardless of any special properties of the non-key bits. Let's assume that the prefix makes cracking 40-bit RC4 100 times quicker for those who know the secret, and forget about it here where network technical instead of cryptoanalytic, historical, political, commercial and other issues are paramount. The sci.crypt newsgroup might be an appropriate forum. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Mon Oct 11 03:15:37 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 204EC5DDC1; Mon, 11 Oct 1999 03:15:29 -0400 (EDT) Received: from abraham.cs.berkeley.edu (abraham.CS.Berkeley.EDU [128.32.37.121]) by segue.merit.edu (Postfix) with ESMTP id 059485DDBD for ; Mon, 11 Oct 1999 03:15:24 -0400 (EDT) Received: from blowfish.isaac.cs.berkeley.edu (blowfish.isaac.cs.berkeley.edu [169.229.3.195]) by abraham.cs.berkeley.edu (8.8.6/8.8.6) with ESMTP id AAA22729; Mon, 11 Oct 1999 00:14:53 -0700 Received: (from daw@localhost) by blowfish.isaac.cs.berkeley.edu (8.8.7/8.8.7) id XAA02337; Sun, 10 Oct 1999 23:52:24 -0700 From: David Wagner Message-Id: <199910110652.XAA02337@blowfish.isaac.cs.berkeley.edu> Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt To: vjs@calcite.rhyolite.com Date: Mon, 11 Oct 1999 06:52:24 +0000 () Cc: ietf-ppp@merit.edu In-Reply-To: <199910090248.UAA24864@calcite.rhyolite.com> from "Vernon Schryver" at Oct 8, 99 08:48:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Vernon Schryver wrote: > However, what about Greg Zorn's overriding point? How can it be of more > than historical, sociological, or political interest whether someone at > Microsoft chose especially weak 40-bit keys for MPPE, instead of someone's > birthday or the next value from some random process? In both theory and > in practical demonstrations, 40-bit RC4 has such poor security that it is > almost a joke. [..] > > Let's assume that the prefix makes cracking 40-bit RC4 100 times quicker > for those who know the secret, and forget about it here where network > technical instead of cryptoanalytic, historical, political, commercial > and other issues are paramount. The sci.crypt newsgroup might be an > appropriate forum. As others have noted, the 40-bit keylength is just short enough that targeted keysearch attacks are trivial, but just long enough that indiscriminate large-scale traffic decryption is rendered quite a bit more painful than some would probably like. Thus, anything that can help reduce the cost of exhaustive keysearch, even by a constant factor, is going to be of great interest to large-scale eavesdroppers. If the special prefix makes cracking 40-bit keys 100x easier, that will make a huge difference to anyone involved in vacuum-cleaner-style interception of PPTP traffic, and might just tip the scales in the favor of making such large-scale attacks practical. Surely this can't be a desired feature of the protocol! If you mean that security issues aren't appropriate for this forum, then I agree that this is off-topic. I don't mean to be a pest, but I do believe that security was a stated goal of the drafts under consideration. (I have specifically avoided discussing any historical, sociological, political, or commercial issues, so I don't know why you brought it up.) Maybe I'm naive, but if there's a security flaw -- or a credible possibility of a security flaw -- in the protocol, shouldn't it be fixed with all due speed? From owner-ietf-ppp-outgoing@merit.edu Mon Oct 11 11:38:52 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3DCF25DDB8; Mon, 11 Oct 1999 11:38:52 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id 6B8005DDB5 for ; Mon, 11 Oct 1999 11:38:50 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA08259 for ietf-ppp@merit.edu env-from ; Mon, 11 Oct 1999 09:38:49 -0600 (MDT) Date: Mon, 11 Oct 1999 09:38:49 -0600 (MDT) From: Vernon Schryver Message-Id: <199910111538.JAA08259@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: David Wagner > ... > If the special prefix makes cracking 40-bit keys 100x easier, that > will make a huge difference to anyone involved in vacuum-cleaner-style > interception of PPTP traffic, and might just tip the scales in the > favor of making such large-scale attacks practical. Surely this > can't be a desired feature of the protocol! If we had standing to discuss MPPE, I bet we could come up with far worse things to say about it than interesting but not compelling oddities of its RC4 keying. Even if we restricted ourselves to talking about its security, MPPE is not what I would call wonderful. > If you mean that security issues aren't appropriate for this forum, > then I agree that this is off-topic. I don't mean to be a pest, > but I do believe that security was a stated goal of the drafts under > consideration. Nothing to do with MPPE is a stated or unstated goal for this working group. The MPPE document is merely one of the least offensive examples of the use of the IETF printing press for unrelated work and the theft of the IETF's imprimatur. (More offensive or at least illuminating examples of that problem are draft-terrell-math-ipaddr-ipv4-02.txt and draft-terrell-ip-spec-ipv7-ipv8-addr-cls-02.txt) > (I have specifically avoided discussing any historical, sociological, > political, or commercial issues, so I don't know why you brought it up.) > > Maybe I'm naive, but if there's a security flaw -- or a credible > possibility of a security flaw -- in the protocol, shouldn't it be > fixed with all due speed? As you and I have discussed before, MPPE is a proprietary protocol that that not even Microsoft could change, even if it wanted to, not to mention whether it were willing to pay attention to concerns or suggestions from the IETF. (See the new version of MS-CHAP current evidence of Microsoft's interest in playing with the IETF instead of continuing it's de facto if perhaps unintentional embrace-and-extend strategy.) Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Oct 12 13:50:42 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9B40E5DDD3; Tue, 12 Oct 1999 13:50:41 -0400 (EDT) Received: from pinky.rte.microsoft.com (unknown [131.107.152.16]) by segue.merit.edu (Postfix) with ESMTP id E71595DD8E for ; Tue, 12 Oct 1999 13:50:39 -0400 (EDT) Received: from localhost (gwz@localhost) by pinky.rte.microsoft.com (8.7.6/8.7.3) with SMTP id KAA17713; Tue, 12 Oct 1999 10:38:25 -0700 (PDT) X-Authentication-Warning: pinky.rte.microsoft.com: gwz owned process doing -bs Date: Tue, 12 Oct 1999 10:38:25 -0700 (PDT) From: Glen Zorn To: David Wagner Cc: ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt In-Reply-To: <199910082107.OAA00290@blowfish.isaac.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Fri, 8 Oct 1999, David Wagner wrote: > In article , > Glen Zorn wrote: > > On Wed, 22 Sep 1999, David Wagner wrote: > > > The MPPE key derivation process uses a fixed prefix, 0xD1269E, to > > > derive 40-bit RC4 session keys. > > > > > > I find this use of a "magic number" very suspicious. Where did > > > this value come from? > > > > Nobody knows where it came from. It's been suggested that it was picked > > out of thin air by someone who left the company a long time ago. As far > > as anyone knows there are no "special properties". > > On the contrary, my preliminary statistical tests show two "special properties" > for the class of RC4 keys starting with prefix 0xD1269E: Perhaps I was unclear: what I _meant_ was that no one here at Microsoft knows of any "special properties" imparted by this choice of constants. > > * The first byte of output takes on the value 0x09 with prob. 0.0054, > which is noticeably higher than the 1/256 = 0.0039 probability you > get for a secure cipher (or for RC4 with a random prefix). > > * The RC4 key schedule mixes some entries in the state table poorly, > for this class of keys. For instance, S[1] = 0xF8 holds with prob. > 1/e = 0.38, and S[2] = 0x98 holds with a similarly large probability. > > Neither of these seem directly usable in any practical attack on the cipher. > Still, I find them suspicious, and perhaps indicative of more subtle flaws. > > It is these special properties of the 0xD1269E prefix which raises a red flag > in my mind. > Are these "properties" unique to the prefix in question or might similar properties acrue from any constant prefix? > From owner-ietf-ppp-outgoing@merit.edu Tue Oct 12 19:21:00 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B563F5DDA1; Tue, 12 Oct 1999 19:20:59 -0400 (EDT) Received: from pinky.rte.microsoft.com (unknown [131.107.152.16]) by segue.merit.edu (Postfix) with ESMTP id 060B35DDA0 for ; Tue, 12 Oct 1999 19:20:58 -0400 (EDT) Received: from localhost (gwz@localhost) by pinky.rte.microsoft.com (8.7.6/8.7.3) with SMTP id QAA17969; Tue, 12 Oct 1999 16:06:21 -0700 (PDT) X-Authentication-Warning: pinky.rte.microsoft.com: gwz owned process doing -bs Date: Tue, 12 Oct 1999 16:06:21 -0700 (PDT) From: Glen Zorn To: David Wagner Cc: vjs@calcite.rhyolite.com, ietf-ppp@merit.edu Subject: Re: I-D ACTION:draft-ietf-pppext-mppe-keys-01.txt In-Reply-To: <199910110652.XAA02337@blowfish.isaac.cs.berkeley.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Mon, 11 Oct 1999, David Wagner wrote: > Vernon Schryver wrote: > > However, what about Greg Zorn's overriding point? How can it be of more > > than historical, sociological, or political interest whether someone at > > Microsoft chose especially weak 40-bit keys for MPPE, instead of someone's > > birthday or the next value from some random process? In both theory and > > in practical demonstrations, 40-bit RC4 has such poor security that it is > > almost a joke. [..] > > > > Let's assume that the prefix makes cracking 40-bit RC4 100 times quicker > > for those who know the secret, and forget about it here where network > > technical instead of cryptoanalytic, historical, political, commercial > > and other issues are paramount. The sci.crypt newsgroup might be an > > appropriate forum. > > > As others have noted, the 40-bit keylength is just short enough that > targeted keysearch attacks are trivial, but just long enough that > indiscriminate large-scale traffic decryption is rendered quite a bit > more painful than some would probably like. Thus, anything that can > help reduce the cost of exhaustive keysearch, even by a constant > factor, is going to be of great interest to large-scale eavesdroppers. > > If the special prefix makes cracking 40-bit keys 100x easier, that > will make a huge difference to anyone involved in vacuum-cleaner-style > interception of PPTP traffic, and might just tip the scales in the > favor of making such large-scale attacks practical. Surely this > can't be a desired feature of the protocol! I think you're missing the point: 40-bit RC4 is obsolete, don't use it! > > If you mean that security issues aren't appropriate for this forum, > then I agree that this is off-topic. I don't mean to be a pest, > but I do believe that security was a stated goal of the drafts under > consideration. Security issues are certainly appropriate for this forum. However, the draft in question is informational, not standards-track (as I believe others have pointed out). To be completely blunt, MPPE is a proprietary Microsoft protocol and the purpose of the document is _only_ to provide information on how it works, so that other vendors can implement if they want to. No technical comments are solicited, only comments on clarity, understandability, etc. If you can't understand the document well enough to implement it, I want to hear about that; if you just think it sucks, I don't care. Note that if this _was_ a standards-track document, it would be a completely different story: any and all technical comments would be welcome. > > (I have specifically avoided discussing any historical, sociological, > political, or commercial issues, so I don't know why you brought it up.) > > Maybe I'm naive, Maybe. > but if there's a security flaw -- or a credible > possibility of a security flaw -- in the protocol, shouldn't it be > fixed with all due speed? > Just to level-check, are you seriously suggesting that I tell my boss that we need to force the update of a couple hundred million PCs because the 'preliminary analysis' of a (no offense intended) Berkeley grad student makes him 'nervous'? From owner-ietf-ppp-outgoing@merit.edu Sat Oct 16 03:13:07 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9C50D5DDF2; Sat, 16 Oct 1999 03:13:07 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by segue.merit.edu (Postfix) with ESMTP id 991ED5DDEC for ; Sat, 16 Oct 1999 03:13:05 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id KAA07472; Sat, 16 Oct 1999 10:13:04 +0300 Date: Sat, 16 Oct 1999 10:13:04 +0300 Message-Id: <199910160713.KAA07472@lohi.eng.telia.fi> From: Juha Heinanen To: ietf-ppp@merit.edu Subject: ppp multiplexing over p-to-p links Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu when a ras is connected to an isp router over a point-to-point link such as a tdm circuit or an atm or fr vc, using l2tp for multiplexing several ppp sessions over this link seems like a big overkill. has there been any discussion on defining a simple ppp multiplexing protocol for that purpose? what would be the arguments for not doing so? -- juha From owner-ietf-ppp-outgoing@merit.edu Sat Oct 16 10:11:02 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3FEF75DE2C; Sat, 16 Oct 1999 10:10:56 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 3077E5DE00 for ; Sat, 16 Oct 1999 10:00:09 -0400 (EDT) Received: from karl ([209.116.97.141]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA2E80; Sat, 16 Oct 1999 08:00:08 -0600 Message-Id: <4.2.1.10.19991016095946.043ab180@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Sat, 16 Oct 1999 10:00:03 -0400 To: Juha Heinanen , ietf-ppp@merit.edu From: "Karl Fox" Subject: Re: ppp multiplexing over p-to-p links In-Reply-To: <199910160713.KAA07472@lohi.eng.telia.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 03:13 AM 10/16/99 , Juha Heinanen wrote: >when a ras is connected to an isp router over a point-to-point link such >as a tdm circuit or an atm or fr vc, using l2tp for multiplexing several >ppp sessions over this link seems like a big overkill. has there been >any discussion on defining a simple ppp multiplexing protocol for that >purpose? what would be the arguments for not doing so? > >-- juha One would be that we already have something that works. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Sat Oct 16 11:10:37 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3E81B5DEFA; Sat, 16 Oct 1999 11:10:27 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id E46255DF42 for ; Sat, 16 Oct 1999 11:04:59 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA22477 env-from ; Sat, 16 Oct 1999 09:04:58 -0600 (MDT) Date: Sat, 16 Oct 1999 09:04:58 -0600 (MDT) From: Vernon Schryver Message-Id: <199910161504.JAA22477@calcite.rhyolite.com> To: ietf-ppp@merit.edu, jh@lohi.eng.telia.fi, karl@extant.net Subject: Re: ppp multiplexing over p-to-p links Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > To: Juha Heinanen , ietf-ppp@merit.edu > From: "Karl Fox" > At 03:13 AM 10/16/99 , Juha Heinanen wrote: > >when a ras is connected to an isp router over a point-to-point link such > >as a tdm circuit or an atm or fr vc, using l2tp for multiplexing several > >ppp sessions over this link seems like a big overkill. has there been > >any discussion on defining a simple ppp multiplexing protocol for that > >purpose? what would be the arguments for not doing so? > One would be that we already have something that works. Why would you use L2TP? Why not the old standby of IP encapsulated in the old familiar ways in ATM or FR circuits? Isn't IP exactly a "simple multiplexing protocol"? (I'm assuming that the ultimate user traffic is also IP.) Or if the idea is use a simple PPP multiplexing protocol to get the component PPP links of a multilink PPP bundle to the ISP, the sad truth is that is exactly the design goal of L2TP. That L2TP is not very simple is testimony to the usual effects, both good (dealing with reality) and otherwise (freaping creaturism and committee politics). You can be confident that a new IETF version of L2TP would be simpler in the same way that SNMPv2 is simpler than SNMPv1, ESMTP is simpler than SMTP, SSH is simpler than rlogin, BGP4 is simpler than EGP, and so on. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Sat Oct 16 12:20:01 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B0F315DEDA; Sat, 16 Oct 1999 12:15:12 -0400 (EDT) Received: from calcite.rhyolite.com (calcite.rhyolite.com [38.159.140.3]) by segue.merit.edu (Postfix) with ESMTP id C88015DF19 for ; Sat, 16 Oct 1999 11:46:29 -0400 (EDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.9.3/calcite) id JAA23404 for ietf-ppp@merit.edu env-from ; Sat, 16 Oct 1999 09:46:29 -0600 (MDT) Date: Sat, 16 Oct 1999 09:46:29 -0600 (MDT) From: Vernon Schryver Message-Id: <199910161546.JAA23404@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: ppp multiplexing over p-to-p links Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "Karl Fox" > > > >when a ras is connected to an isp router over a point-to-point link such > > > >as a tdm circuit or an atm or fr vc, using l2tp for multiplexing several > > > >ppp sessions over this link seems like a big overkill. has there been > > > >any discussion on defining a simple ppp multiplexing protocol for that > > > >purpose? what would be the arguments for not doing so? > ... > >Why would you use L2TP? Why not the old standby of IP encapsulated in > >the old familiar ways in ATM or FR circuits? > > Oh. Of course, that would be simpler. I was assuming a single VC was all > that was available. As some salescritters like to shout, "We Have The Technology" to run IP over single VC's. If you don't like the classic x.25 scheme, you could always run a single TCP/IP connnection over that single ATM or FR VC in the modern mode, and in that TCP stream just happen to have PPP, as in IP/PPP/{rlogin,telnet,SSH}/TCP/IP/{ATM,FR} Common PPP implementations are intended to and do work just fine in rlogin or telnet. It is a little perverse and not especially efficient, but it works. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Sat Oct 16 12:26:13 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 485275DF15; Sat, 16 Oct 1999 12:15:08 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 77B505DE1E for ; Sat, 16 Oct 1999 11:37:08 -0400 (EDT) Received: from karl ([209.116.97.141]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA2FD7; Sat, 16 Oct 1999 09:37:08 -0600 Message-Id: <4.2.1.10.19991016113612.043ab560@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Sat, 16 Oct 1999 11:37:02 -0400 To: Vernon Schryver , ietf-ppp@merit.edu, jh@lohi.eng.telia.fi From: "Karl Fox" Subject: Re: ppp multiplexing over p-to-p links In-Reply-To: <199910161504.JAA22477@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 11:04 AM 10/16/99 , Vernon Schryver wrote: > > To: Juha Heinanen , ietf-ppp@merit.edu > > From: "Karl Fox" > > > At 03:13 AM 10/16/99 , Juha Heinanen wrote: > > >when a ras is connected to an isp router over a point-to-point link such > > >as a tdm circuit or an atm or fr vc, using l2tp for multiplexing several > > >ppp sessions over this link seems like a big overkill. has there been > > >any discussion on defining a simple ppp multiplexing protocol for that > > >purpose? what would be the arguments for not doing so? > > > One would be that we already have something that works. > >Why would you use L2TP? Why not the old standby of IP encapsulated in >the old familiar ways in ATM or FR circuits? Oh. Of course, that would be simpler. I was assuming a single VC was all that was available. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Sun Oct 17 02:30:05 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E2DD5DE4F; Sun, 17 Oct 1999 02:00:09 -0400 (EDT) Received: from lohi.eng.telia.fi (lohi.eng.telia.fi [195.10.149.18]) by segue.merit.edu (Postfix) with ESMTP id C9C955DF5F for ; Sun, 17 Oct 1999 01:18:25 -0400 (EDT) Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian/GNU) id IAA15573; Sun, 17 Oct 1999 08:18:23 +0300 From: Juha Heinanen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14345.23583.171932.959628@lohi.eng.telia.fi> Date: Sun, 17 Oct 1999 08:18:23 +0300 (EEST) To: "Karl Fox" Cc: Vernon Schryver , ietf-ppp@merit.edu Subject: Re: ppp multiplexing over p-to-p links In-Reply-To: <4.2.1.10.19991016113612.043ab560@mail.extant.net> References: <199910161504.JAA22477@calcite.rhyolite.com> <4.2.1.10.19991016113612.043ab560@mail.extant.net> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Karl Fox writes: > Oh. Of course, that would be simpler. I was assuming a single VC was all > that was available. yes, single vc carrying multiple parallel ppp sessions, one per dialup user. none of capabilities of l2tp apart from multiplexing are not needed in this application. also ip sunneling is unnecessary, since the ras and the isp router are directly connected over the vc. if you take all the discovery and service selection stuff out from pppoe you pretty much get what would be needed. -- juha From owner-ietf-ppp-outgoing@merit.edu Mon Oct 18 05:07:53 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D36A5DEA1; Mon, 18 Oct 1999 05:07:36 -0400 (EDT) Received: from mail.totalise.co.uk (mail.totalise.co.uk [212.1.130.20]) by segue.merit.edu (Postfix) with ESMTP id 7FD5C5DDAD for ; Mon, 18 Oct 1999 05:00:33 -0400 (EDT) X-WM-Posted-At: mail.totalise.co.uk; Mon, 18 Oct 99 10:02:59 +0100 Date: Mon, 18 Oct 1999 10:02:59 +0100 From: Kelvin Lawson To: ietf-ppp@merit.edu X-EXP32-SerialNo: 50000112 Subject: DESE implementations of ECP Message-ID: <38163402@mail.totalise.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: InterChange (Hydra) SMTP v3.51.03 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu All, I have recently spent time implementing DESE and DESE-bis as ECP options, however I am unable to test the results with any other PPP implementations. I cannot find any equipment or software which supports these options. Is anyone aware of PPP implementations that do support these ? MPPE seems to be the only ECP protocol which is paid any attention. Thanks for your comments, Kelvin. Totalise - the Users ISP ---------------------- To become a member and a shareholder - visit the site at www.totalise.co.uk From owner-ietf-ppp-outgoing@merit.edu Wed Oct 20 06:58:37 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5EB835DE1D; Wed, 20 Oct 1999 06:58:36 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 57ED65DE1A for ; Wed, 20 Oct 1999 06:58:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24412; Wed, 20 Oct 1999 06:58:33 -0400 (EDT) Message-Id: <199910201058.GAA24412@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-sdl-05.txt Date: Wed, 20 Oct 1999 06:58:32 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing Author(s) : J. Carlson, P. Langner, E. Hernandez Valencia, J. Manchester Filename : draft-ietf-pppext-sdl-05.txt Pages : 29 Date : 19-Oct-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links, and RFCs 1662 [2] and 1619 [3] provide a means to carry PPP over Synchronous Optical Network (SONET) [4] and Synchronous Digital Hierarchy (SDH) [5] circuits. This document extends these standards to include a new encapsulation for PPP called Simple Data Link (SDL) [6]. SDL provides a very low overhead alternative to standard HDLC encapsulation, and can also be used on SONET/SDH links. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-sdl-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-sdl-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-sdl-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991019144340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-sdl-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-sdl-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991019144340.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Wed Oct 20 10:34:10 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A44ED5DDDC; Wed, 20 Oct 1999 10:34:06 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id D89975DD98 for ; Wed, 20 Oct 1999 10:34:04 -0400 (EDT) Received: from karl ([209.116.97.157]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA6F6A; Wed, 20 Oct 1999 08:34:06 -0600 Message-Id: <4.2.1.10.19991020102752.04567940@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Wed, 20 Oct 1999 10:33:21 -0400 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: Call for PPPEXT Agenda Items for the 46th IETF in Washington, D.C. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The PPPEXT Working Group is scheduled to meet Monday, November 8, from 1930-2200, opposite webdav, anycast, dnsop, isis, xmldsig, diffserv and iptel. Note that L2TPEXT is now a separate working group and is meeting Thursday afternoon from 1530-1730. Please send me requests to make presentations. Be sure to include all of the below: 1) Name of presenter, including e-mail address 2) Title of presentation 3) Internet draft name, if applicable 4) Amount of time requested Thanks, Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Oct 20 12:51:02 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC22A5DDA4; Wed, 20 Oct 1999 12:51:01 -0400 (EDT) Received: from procyon.pmc-sierra.bc.ca (procyon.pmc-sierra.bc.ca [134.87.115.1]) by segue.merit.edu (Postfix) with ESMTP id A46D85DE31 for ; Wed, 20 Oct 1999 12:50:59 -0400 (EDT) Received: from nt-exchange1.pmc-sierra.bc.ca (nt-exchange1.pmc-sierra.bc.ca [134.87.116.183]) by procyon.pmc-sierra.bc.ca (6.6.6/6.6.6) with ESMTP id JAA03207; Wed, 20 Oct 1999 09:50:53 -0700 (PDT) Received: by nt-exchange1.pmc-sierra.bc.ca with Internet Mail Service (5.5.2448.0) id ; Wed, 20 Oct 1999 09:50:53 -0700 Message-ID: From: Shahram Davari To: "'Karl Fox'" Cc: ietf-ppp@merit.edu Subject: RE: Call for PPPEXT Agenda Items for the 46th IETF in Washington, D.C. Date: Wed, 20 Oct 1999 09:50:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Hi Carl, Since most IETF participants are interested in Diffserv and MPLS, can you schedule the PPPext meeting to a time which is not opposite of these two WGs. Thanks, Shahram Davari PMC-Sierra > -----Original Message----- > From: Karl Fox [mailto:karl@extant.net] > Sent: Wednesday, October 20, 1999 7:33 AM > To: ietf-ppp@merit.edu > Subject: Call for PPPEXT Agenda Items for the 46th IETF in Washington, > D.C. > > > The PPPEXT Working Group is scheduled to meet Monday, > November 8, from > 1930-2200, opposite webdav, anycast, dnsop, isis, xmldsig, > diffserv and > iptel. Note that L2TPEXT is now a separate working group and > is meeting > Thursday afternoon from 1530-1730. > > Please send me requests to make presentations. Be sure to > include all of > the below: > > 1) Name of presenter, including e-mail address > 2) Title of presentation > 3) Internet draft name, if applicable > 4) Amount of time requested > > Thanks, > > Karl Fox > Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 > > From owner-ietf-ppp-outgoing@merit.edu Wed Oct 20 19:45:18 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C4CB25DF06; Wed, 20 Oct 1999 19:45:05 -0400 (EDT) Received: from pinky.rte.microsoft.com (unknown [131.107.152.16]) by segue.merit.edu (Postfix) with ESMTP id E43B35DF61 for ; Wed, 20 Oct 1999 19:02:49 -0400 (EDT) Received: from localhost (gwz@localhost) by pinky.rte.microsoft.com (8.7.6/8.7.3) with SMTP id PAA29371; Wed, 20 Oct 1999 15:50:07 -0700 (PDT) X-Authentication-Warning: pinky.rte.microsoft.com: gwz owned process doing -bs Date: Wed, 20 Oct 1999 15:50:07 -0700 (PDT) From: Glen Zorn To: Karl Fox Cc: ietf-ppp@merit.edu Subject: Re: Call for PPPEXT Agenda Items for the 46th IETF in Washington, D.C. In-Reply-To: <4.2.1.10.19991020102752.04567940@mail.extant.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu On Wed, 20 Oct 1999, Karl Fox wrote: > The PPPEXT Working Group is scheduled to meet Monday, November 8, from > 1930-2200, opposite webdav, anycast, dnsop, isis, xmldsig, diffserv and > iptel. Note that L2TPEXT is now a separate working group and is meeting > Thursday afternoon from 1530-1730. What does this mean WRT the existing L2TP-related documents? Do they have to be resubmitted as draft-ietf-l2tpext-*-00? > > Please send me requests to make presentations. Be sure to include all of > the below: > > 1) Name of presenter, including e-mail address > 2) Title of presentation > 3) Internet draft name, if applicable > 4) Amount of time requested > > Thanks, > > Karl Fox > Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 > > > From owner-ietf-ppp-outgoing@merit.edu Wed Oct 20 23:32:36 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A4A645DE0E; Wed, 20 Oct 1999 23:32:35 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id BD5935DDDE for ; Wed, 20 Oct 1999 23:32:33 -0400 (EDT) Received: from karl ([209.116.97.136]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA1914; Wed, 20 Oct 1999 21:32:35 -0600 Message-Id: <4.2.1.10.19991020233152.0456a2d0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Wed, 20 Oct 1999 23:32:24 -0400 To: Glen Zorn From: "Karl Fox" Subject: Re: Call for PPPEXT Agenda Items for the 46th IETF in Washington, D.C. Cc: ietf-ppp@merit.edu In-Reply-To: References: <4.2.1.10.19991020102752.04567940@mail.extant.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 06:50 PM 10/20/99 , Glen Zorn wrote: >On Wed, 20 Oct 1999, Karl Fox wrote: > > > The PPPEXT Working Group is scheduled to meet Monday, November 8, from > > 1930-2200, opposite webdav, anycast, dnsop, isis, xmldsig, diffserv and > > iptel. Note that L2TPEXT is now a separate working group and is meeting > > Thursday afternoon from 1530-1730. > >What does this mean WRT the existing L2TP-related documents? Do they have >to be resubmitted as draft-ietf-l2tpext-*-00? No; the names of the documents are not important. Where they are handled is. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Oct 20 23:34:09 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 401B75DE35; Wed, 20 Oct 1999 23:34:08 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id 5B6285DE0E for ; Wed, 20 Oct 1999 23:34:06 -0400 (EDT) Received: from karl ([209.116.97.136]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA191F; Wed, 20 Oct 1999 21:34:07 -0600 Message-Id: <4.2.1.10.19991020233321.0456a150@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Wed, 20 Oct 1999 23:34:01 -0400 To: Shahram Davari From: "Karl Fox" Subject: RE: Call for PPPEXT Agenda Items for the 46th IETF in Washington, D.C. Cc: ietf-ppp@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu It's too late for this meeting, but I can add those groups to the list I always ask for. This is the first request I've had to avoid those groups. Karl At 12:50 PM 10/20/99 , Shahram Davari wrote: >Hi Carl, > >Since most IETF participants are interested in Diffserv and MPLS, can you >schedule the PPPext meeting to a time which is not opposite of these two >WGs. > >Thanks, >Shahram Davari >PMC-Sierra > > > > -----Original Message----- > > From: Karl Fox [mailto:karl@extant.net] > > Sent: Wednesday, October 20, 1999 7:33 AM > > To: ietf-ppp@merit.edu > > Subject: Call for PPPEXT Agenda Items for the 46th IETF in Washington, > > D.C. > > > > > > The PPPEXT Working Group is scheduled to meet Monday, > > November 8, from > > 1930-2200, opposite webdav, anycast, dnsop, isis, xmldsig, > > diffserv and > > iptel. Note that L2TPEXT is now a separate working group and > > is meeting > > Thursday afternoon from 1530-1730. > > > > Please send me requests to make presentations. Be sure to > > include all of > > the below: > > > > 1) Name of presenter, including e-mail address > > 2) Title of presentation > > 3) Internet draft name, if applicable > > 4) Amount of time requested > > > > Thanks, > > > > Karl Fox > > Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 > > > > Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Thu Oct 21 06:55:12 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1CDA65DDB1; Thu, 21 Oct 1999 06:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id D81395DDE4 for ; Thu, 21 Oct 1999 06:52:52 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13974; Thu, 21 Oct 1999 06:52:52 -0400 (EDT) Message-Id: <199910211052.GAA13974@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mppe-04.txt Date: Thu, 21 Oct 1999 06:52:51 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Microsoft Point-To-Point Encryption (MPPE) Protocol Author(s) : G. Pall, G. Zorn Filename : draft-ietf-pppext-mppe-04.txt Pages : 12 Date : 20-Oct-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to Point Encryp- tion (MPPE) to enhance the confidentiality of encrypted PPP-encapsulated packets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-mppe-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mppe-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991020134053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mppe-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mppe-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991020134053.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Wed Oct 27 14:38:57 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 74C855DDF2; Wed, 27 Oct 1999 14:38:56 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id AB8DA5DDF4 for ; Wed, 27 Oct 1999 14:38:32 -0400 (EDT) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA3905; Wed, 27 Oct 1999 12:38:37 -0600 Message-Id: <4.2.1.10.19991027143323.051875e0@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Wed, 27 Oct 1999 14:38:29 -0400 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: draft-simpson-des-as-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The Internet Draft, "DES Applicability Statement for Historic Status" (draft-simpson-des-as-01.txt) says: Abstract "The PPP DES Encryption Protocol" [RFC-2419], "The ESP DES-CBC Cipher Algorithm With Explicit IV" [RFC-2405], and "The ESP DES-CBC Transform" [RFC-1829] have been re-classified to Historic status, and implementation is Not Recommended. "The PPP Triple-DES Encryption Protocol (3DESE)" [RFC-2420] and "The ESP Triple-DES Transform" [RFC-xxxx] are now classified as mandatory to implement for Standards Track interoperability. This Applicability Statement provides the supporting motivation for that classification. The primary reason is that DES alone provides insufficient strength for the protection of moderate value information for any length of time. Do you agree with this? Is declaring single DES as historic the right thing to do given deployment and where it is used? Please make your opinion known. Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Oct 27 15:07:04 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 566AC5DDFE; Wed, 27 Oct 1999 15:05:19 -0400 (EDT) Received: from intra0.extant.net (intra0.lvp.extant.net [216.28.121.11]) by segue.merit.edu (Postfix) with ESMTP id E8D6E5DE52 for ; Wed, 27 Oct 1999 15:03:15 -0400 (EDT) Received: from karl ([216.28.121.202]) by intra0.extant.net (Netscape Messaging Server 3.6) with ESMTP id AAA3A9E; Wed, 27 Oct 1999 13:03:21 -0600 Message-Id: <4.2.1.10.19991027145939.045d4100@mail.extant.net> X-Sender: kfox@mail.extant.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1.10 (Beta) Date: Wed, 27 Oct 1999 15:03:05 -0400 To: ietf-ppp@merit.edu From: "Karl Fox" Subject: Washington PPPEXT Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Here's the current agenda for Washington. Please send me any additions or changes as soon as possible. Karl PPP Extensions Working Group Agenda 46th IETF-Washington, D.C. Monday, November 8, 1999, 1930-2200 Discussion of PPPEXT Standards Track Document Status Karl Fox [20 minutes] VPN Interoperability Announcement Anita Freeman [5 minutes] PPP Bridge Control Protocol draft-ietf-pppext-bcp-01.txt Mitsuru Higashiyama [10 minutes] PPP Multiplexing draft-ietf-pppext-pppmux-00.txt Irfan Ali [20 minutes] Secure Remote Access with L2TP draft-ietf-pppext-secure-ra-00.txt Pyda Srisuresh [10 minutes] Karl Fox Key fingerprint = 5B15 7260 D55E D680 0B93 4953 8A3B AB0E C05D 77A3 From owner-ietf-ppp-outgoing@merit.edu Wed Oct 27 15:55:47 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 715555DDE1; Wed, 27 Oct 1999 15:55:46 -0400 (EDT) Received: from viper.columbus.rr.com (viper.columbus.rr.com [204.210.252.254]) by segue.merit.edu (Postfix) with ESMTP id C7FC95DDD8 for ; Wed, 27 Oct 1999 15:55:39 -0400 (EDT) Received: from pavilion (dhcp93126062.columbus.rr.com [24.93.126.62]) by viper.columbus.rr.com (8.9.3/8.9.3) with SMTP id PAA11893; Wed, 27 Oct 1999 15:52:23 -0400 (EDT) From: "Mark Anthony Beadles" To: "'Karl Fox'" , Subject: RE: draft-simpson-des-as-01.txt Date: Wed, 27 Oct 1999 15:58:09 -0400 Message-ID: <003501bf20b5$98ab5d40$3e7e5d18@pavilion.columbus.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <4.2.1.10.19991027143323.051875e0@mail.extant.net> Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu A simple extrapolation of the crack times given in this document shows that on approximately 1 December of this year (1999), technology should exist that can crack DES in 1 hour. By 1 January 2001, the crack should take under two minutes. The data fit a logarithmic curve quite well: Crack Date Time (Hrs.) 17 Jun 97 3360.00 23-Feb-98 960.00 16-Jul-98 56.00 19-Jan-99 22.25 01-Dec-99 1.07 01-Jan-01 0.03 This projection assumes only that technology will continue to improve at the current rate - any "breakthroughs" will move the timetable up. So the conclusion of the authors: "Adversaries with relatively small budgets will soon have the capability to recover 56-bit keys in hours or minutes. Well-financed adversaries have or will soon have the capability to recover any DES key within seconds." is not unreasonable. + Mark Anthony Beadles + + mark.beadles@columbus.rr.com + + Vox 614.565.1308 Pager 888.660.8427 + From owner-ietf-ppp-outgoing@merit.edu Thu Oct 28 07:10:22 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8139D5DDAA; Thu, 28 Oct 1999 07:10:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 1A55E5DD8F for ; Thu, 28 Oct 1999 07:10:18 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14141; Thu, 28 Oct 1999 07:10:16 -0400 (EDT) Message-Id: <199910281110.HAA14141@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-mppe-keys-02.txt Date: Thu, 28 Oct 1999 07:10:16 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : MPPE Key Derivation Author(s) : G. Zorn Filename : draft-ietf-pppext-mppe-keys-02.txt Pages : 20 Date : 27-Oct-99 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. Microsoft Point to Point Encryption (MPPE) [4] is a means of representing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit, 56-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive initial MPPE session keys from a variety of credential types. It is expected that this memo will be updated whenever Microsoft defines a new key derivation method for MPPE, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. The algorithm used to change session keys during a session is described in [4]. The algorithm used to change session keys during a session is described in [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-mppe-keys-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-mppe-keys-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-mppe-keys-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991027140637.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-mppe-keys-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-mppe-keys-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027140637.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Oct 28 11:28:07 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6DF1F5DDE9; Thu, 28 Oct 1999 11:28:06 -0400 (EDT) Received: from sj-mailhub-3.cisco.com (sj-mailhub-3.cisco.com [171.68.224.215]) by segue.merit.edu (Postfix) with ESMTP id 3DF2D5DDD1 for ; Thu, 28 Oct 1999 11:28:04 -0400 (EDT) Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.69.63.148]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA11275 for ; Thu, 28 Oct 1999 08:33:24 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA25672 for ietf-ppp@merit.edu; Thu, 28 Oct 1999 08:27:22 -0700 (PDT) Date: Thu, 28 Oct 1999 08:27:22 -0700 (PDT) Message-Id: <199910281527.IAA25672@irp-view7.cisco.com> To: ietf-ppp@merit.edu Subject: ftp://ftpeng.cisco.com/fred/ppp/draft-ietf-ppp-bcp-01.txt Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The new BCP draft is located at the URL in the subject line. We didn't make it in under the wire, sorry. From owner-ietf-ppp-outgoing@merit.edu Fri Oct 29 08:48:55 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 297B65DDF2; Fri, 29 Oct 1999 08:48:50 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 1AC325DDEE for ; Fri, 29 Oct 1999 08:48:47 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21916; Fri, 29 Oct 1999 08:48:44 -0400 (EDT) Message-Id: <199910291248.IAA21916@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-l2tp-security-05.txt Date: Fri, 29 Oct 1999 08:48:43 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Securing L2TP using IPSEC Author(s) : B. Patel, B. Aboba, W. Dixon, G. Zorn Filename : draft-ietf-pppext-l2tp-security-05.txt Pages : 14 Date : 28-Oct-99 This document discusses how L2TP may utilize IPSEC to provide for tunnel authentication, privacy, and integrity and replay protection. Both the voluntary and compulsory tunneling cases are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-l2tp-security-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-l2tp-security-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-security-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991028142307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-security-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-security-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991028142307.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Fri Oct 29 15:27:33 1999 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 74E275DE0C; Fri, 29 Oct 1999 15:27:32 -0400 (EDT) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by segue.merit.edu (Postfix) with ESMTP id 82F9F5DE0B for ; Fri, 29 Oct 1999 15:27:30 -0400 (EDT) Received: from anfreema-pc.cisco.com (dhcp-f-249.cisco.com [171.68.234.249]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with SMTP id MAA13682; Fri, 29 Oct 1999 12:26:57 -0700 (PDT) Message-Id: <4.1.19991029121401.00b83480@sj-email> X-Sender: anfreema@sj-email X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 29 Oct 1999 12:25:49 -0700 To: l2tp@ipsec.org, ietf-ppp@merit.edu, ipsec@lists.tislabs.com From: Anita Freeman Subject: VPN Interoperability Workshop Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu The next VPN Interoperability Workshop will be held January 9-14, 2000, at the Paradise Point Resort in San Diego, California. The Workshop is being sponsored by Cisco. The protocols being tested are: IPSec- IKE- CA IPComp L2TP over Transport-Mode IPSec CCP with MPPC and MPPE MS CHAP V2 EAP PPTP PPPoE PPPoATM L2TPoATM Another email will be sent to the mailing lists when the workshop application is available on the CIUG web site (www.ciug.org). Hotel reservations may be made by calling Paradise Point Resort at 800-344-2626. Please register under the Cisco VPN Workshop room block for the discounted rate of $140 per night (plus tax). Thanks, Anita