From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 2 14:15:50 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12631; Tue, 2 Jul 91 14:00:18 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA12405; Tue, 2 Jul 91 13:47:44 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910618) id AA26759; Tue, 2 Jul 91 13:42:49 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA20374 to ietf-ppp@ucdavis.edu; Tue, 2 Jul 91 13:36:57 PDT Date: Tue, 2 Jul 91 13:36:57 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107022036.AA20374@napa.TELEBIT.COM> To: Ilan_Raab.ENGINTWO@engtwomac.synoptics.com Cc: ietf-ppp@ucdavis.edu In-Reply-To: Ilan Raab's message of 1 Jul 91 17:40:10 <9107020033.AA29049@mvis1.synoptics.com> Subject: RE>PPP Authentication proto Date: 1 Jul 91 17:40:10 From: Ilan Raab Reply to: RE>PPP Authentication protocol Did you think about enetering a time delay so as not to make it too simple for repititive tries? /Ilan -------------------------------------- Date: 7/1/91 To: Ilan Raab From: brian@napa.Telebit.COM When I described CHAP to Bill I proposed that the response to a failed crypto handshake was to close the link. I did not see any reason to even bother with the ACK or NAK. Since then the presence of an ACK or NAK might be useful if you are dealing with more than one key. A NAK might indicate that you should try again with a different key (and the challenger should send a new challenge). Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 No, I did not consider adding a time delay. We have two machines talking to each other, not a human talking to a computer. The exchange should proceed a full speed. Since the frames have a CRC for catching bit errors I saw no reason not to drop the link if the peer did not respond correctly to the challenge. Since he responded we know that he received the challenge correctly (that his CRC check was OK) and we know that he responded correctly (the CRC check was good for his response). If the authentication algorithm then rejects the response it can be for one reason; the key used to permute the challenge was not the correct key. Hence my suggestion to drop the link (with a termination-request, of course, just to be nice). Why bother with retries? Now if you want to try it using several different keys you can just keep sending configure requests with the crypto challenge until you are satisfied. In addition, since this part of the protocol is stateless (send a challenge, get a response) you can send challenges periodically if you like. This provides some security against "bait and switch" attacks. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 2 16:34:59 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15258; Tue, 2 Jul 91 16:17:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [131.108.2.50] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15008; Tue, 2 Jul 91 16:04:41 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Tue, 2 Jul 91 15:59:15 -0700 Message-Id: <9107022259.AA17810@wolf.cisco.com> To: katz@merit.edu Cc: bsimpson@vela.acs.oakland.edu, fbaker@acc.com, ietf-ppp@ucdavis.edu Subject: Re: CLNS draft In-Reply-To: Your message of "Tue, 02 Jul 91 15:43:53 EDT." <9107021943.AA04076@home.merit.edu> Date: Tue, 02 Jul 91 16:01:02 MDT From: Jim Forster >> I guess the bottom line is that I have no particularly strong feelings >> on how to position it. I struggled, but finally came up with a reason to prefer one or the other. I think that OSI CLNP should be a full-fledged NCP. The reason is that this is the only way to take advantage of Protocol-specific configuration options. Dave didn't specify any in his initial CLNP over PPP draft, and in fact, none are essential, but some might be nice along the way. Address assignment or verification might be one that's useful, especially in a circuit-switched (dialup) environment. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 2 17:48:50 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16299; Tue, 2 Jul 91 17:15:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [143.137.50.1] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16225; Tue, 2 Jul 91 17:11:33 -0700 Received: from caicos.engineering ([143.137.50.9]) by cayman.Cayman.COM (4.1/SMI-4.0) id AA27551; Tue, 2 Jul 91 20:10:54 EDT Received: from localhost by caicos.engineering (4.1/SMI-4.1) id AA08883; Tue, 2 Jul 91 20:10:57 EDT Message-Id: <9107030010.AA08883@caicos.engineering> To: fbaker@acc.com (Fred Baker) Cc: ietf-ppp@ucdavis.edu, apple-ip@apple.com Subject: Re: AppleTalk PPP In-Reply-To: Mail from fbaker@acc.com (Fred Baker) dated Tue, 02 Jul 91 11:11:32 PDT <9107021811.AA05248@emerald.acc.com> Date: Tue, 02 Jul 91 20:10:55 -0400 From: brad@Cayman.COM >> It seems to me, first that you have essentially copied the IP Address >> Exchange from the IP NCP, in the address exchange option. Well and >> good, but I thought that Appletalk had a random address - how do I know >> the address of my neighbor before he tells me? Why am I not just >> telling him _my_ proposed address? You are correct that on LANs a mac will "probe" for a free address with a random seed if no saved seed is available. With PPP, it may be the case that one end has no idea (and does not care) what the network number is or what it's node number will be. Since the connection is point-to-point, the value of a "plug and play so I guess my node id" is diminished. I wanted to allow for dial-in end nodes which need to be "told" what their netword and node address is. Certainly the two devices negotiating need to agree on the network number and make sure their node id's do not conflict. >> Is this option intended to be the way the random address negotiation >> (as in, I'll send you one, if you don't like it, I'll send you another) >> is performed? If so, some verbiage on the subject is in order, I >> think. No, it is intended to work just like the IP negotiation; you can reject the supplied address and supply you own, or accept the address provided. If you reject the given address, I would expect the other end to supply and valid address. >> Routing Protocol: >> >> I think it would be of value to have an assigned number for RTMP. >> >> 1 - no routing information >> 2 - RTMP Yes, I agree. >> Suppress Broadcasts: >> >> Once again, I could be wrong, but it seems to me that the Name Binding >> Protocol requires broadcasts as well. Without Name Binding, you can't >> find your neighboring services. Without neighboring services, the >> value of connectivity is lost. Actually, across a point-to-point link the NBP is sent with a "bridge request" or a "forward request", neither of which is a broadcast. The "exploder", or destination router actually turns the request in a local broadcast (like a directed broadcast in IP). Note the phase 1 and phase 2 have different concepts of how the final broadcast is generated. (phase 1 sends directed broadcasts, phase 2 sends forward requests) The "suppress broadcasts" is useful if one end is not a router (so the ppp link is more like a long cable and the "router" is actually a "node forwarding agent" if you will). It also can be used to suppress RTMP broadcasts. This was added by the Shiva folks, perhaps they could explain the idea better. I can see a case where you would suppress broadcasts and use an alternate, private routing protocol, but not "disable" rtmp explicitly. I think that "suppress broadcast" would only break NBP in the case where an end-node was talking to a node-forwarder and the end-node did not believe there was a router on the network. I have to admit that I did not implement the "suppress broadcast" option. Humm. I think this generality is designed to support router-to-router, router-to-endnode, and endnode-to-forwarder type links. Hope this helps. If not, please send more questions/comments. -brad From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 2 21:02:30 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19587; Tue, 2 Jul 91 20:45:17 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from [129.77.1.13] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19401; Tue, 2 Jul 91 20:31:41 -0700 Received: by crane.aa.ox.com (/\=-/\ Smail3.1.18.1 #18.26) id ; Tue, 2 Jul 91 23:31 EDT Message-Id: To: ietf-ppp@ucdavis.edu Subject: call for votes: usenet newsgroup "comp.protocols.ppp" Date: Tue, 02 Jul 91 23:31:05 EDT From: Edward Vielmetti [as originally seen in news.announce.newgroups. --Ed] This is a call for votes for the newsgroup comp.protocols.ppp, as discussed in news.groups, comp.dcom.lans, comp.dcom.modems, the ietf-ppp mailing list, the ppp-interest mailing list, and in various and sundry other places on the net. Please repost and cross-post as needed. Those of you with long memories will recall a call for discussion on this topic several months ago; it got widespread interest, some discussion, some of the obligatory arguments about the name, and then it petered out. Since then discussion about PPP has extended to even more lists; the pubnet list has periodic discussion, it shows up in tcp-group, etc et al ad nauseum. I don't have the energy to track all of the discussions in all of the groups any more, so it's clearly time to go after a new one. PPP, the Point to Point Protocol, is an internet standard for the transmission of multiprotocol datagrams over serial lines. It is widely seen as a successor to SLIP for dial-up asynch IP, and there's some experience in using it as an alternative to UUCP for low-speed ad hoc network connectivity. PPP is available in the products of several commercial vendors, including Telebit's "Netblazer", Cisco routers, and no doubt several others; one of the projects for the newsgroup would be to compile a list. It's also available for free from several locations, again that deserves a list. The terms of the vote are as follows. The vote will last until 23:59 GMT on 30 July 1991. The mailbox for yes votes is ppp-yes@msen.com The mailbox for no votes is ppp-no@msen.com The mailbox for administrivia, requests, supplementary materials, or to volunteer as a repository for PPP materials and information, is ppp-request@msen.com There is reason to believe that for effective distribution of this newsgroup, it will be good to gateway it to an Internet mailing list; in that event, there will be a listserv set up so that joins and deletes can be done. If you're not able to get usenet news, but are still interested in these discussions, drop a line to ppp-request mentioning this so that I can gauge interest. Further information about this group, until the point in time where it actually starts to exist, will be put in the newsgroups news.groups,comp.dcom.modems,comp.dcom.lans so if you can track those you won't be too far off. - --Ed Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com ------- End of Forwarded Message From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 3 12:15:20 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02314; Wed, 3 Jul 91 11:31:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from merit.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA02049; Wed, 3 Jul 91 11:24:33 -0700 Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA04776; Wed, 3 Jul 91 14:23:57 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA08686; Wed, 3 Jul 91 14:23:56 EDT Date: Wed, 3 Jul 91 14:23:56 EDT From: katz@merit.edu Message-Id: <9107031823.AA08686@home.merit.edu> To: forster@cisco.com, katz@merit.edu Subject: Re: CLNS draft Cc: bsimpson@vela.acs.oakland.edu, fbaker@acc.com, ietf-ppp@ucdavis.edu As I spec'ed in the draft, the NCP should be for the whole OSI Network Layer, not just CLNP. Address assignment should be done with ES-IS... but I guess I agree. From ietf-ppp-request@ucdavis.edu Wed Jul 3 03:45:53 1991 Received: from ucdavis.ucdavis.edu by merit.edu (5.65/1123-1.0) id AA00749; Wed, 3 Jul 91 03:45:50 -0400 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15258; Tue, 2 Jul 91 16:17:33 -0700 Sender: ietf-ppp-request@ucdavis.edu Received: from [131.108.2.50] by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA15008; Tue, 2 Jul 91 16:04:41 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Tue, 2 Jul 91 15:59:15 -0700 Message-Id: <9107022259.AA17810@wolf.cisco.com> To: katz@merit.edu Cc: bsimpson@vela.acs.oakland.edu, fbaker@acc.com, ietf-ppp@ucdavis.edu Subject: Re: CLNS draft In-Reply-To: Your message of "Tue, 02 Jul 91 15:43:53 EDT." <9107021943.AA04076@home.merit.edu> Date: Tue, 02 Jul 91 16:01:02 MDT From: Jim Forster Status: R >> I guess the bottom line is that I have no particularly strong feelings >> on how to position it. I struggled, but finally came up with a reason to prefer one or the other. I think that OSI CLNP should be a full-fledged NCP. The reason is that this is the only way to take advantage of Protocol-specific configuration options. Dave didn't specify any in his initial CLNP over PPP draft, and in fact, none are essential, but some might be nice along the way. Address assignment or verification might be one that's useful, especially in a circuit-switched (dialup) environment. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 3 18:17:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09798; Wed, 3 Jul 91 18:01:02 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09781; Wed, 3 Jul 91 17:58:32 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Wed, 3 Jul 91 17:44:37 -0700 Message-Id: <9107040044.AA07874@wolf.cisco.com> To: katz@merit.edu Cc: bsimpson@vela.acs.oakland.edu, fbaker@acc.com, ietf-ppp@ucdavis.edu Subject: Re: CLNS draft In-Reply-To: Your message of "Wed, 03 Jul 91 14:23:56 EDT." <9107031823.AA08686@home.merit.edu> Date: Wed, 03 Jul 91 17:46:20 MDT From: Jim Forster >> As I spec'ed in the draft, the NCP should be for the whole OSI Network >> Layer, not just CLNP. Address assignment should be done with ES-IS... >> but I guess I agree. Yes, I oversimplified. Rather than address assignment, perhaps a better term would be address verification. This seems to be very useful for a circuit-switched (dialup) enviroment, where you want to be sure you've reached the point you think you have, by verifying that the address at the other end is what you're expecting. Arguably, this could be handled by LCP-level authentication just as well. OK, how bout this one: if someone comes up with VJ-Style header compression for OSI this would be nice to negotiate in an option. But I belabor the point; it looks like we're agreed that OSI CLNP should be a full-fledged NCP by itself. Enough talk. On to the action items Fred has called for. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 3 19:16:07 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10768; Wed, 3 Jul 91 19:00:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ALLSPICE.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10613; Wed, 3 Jul 91 18:49:20 -0700 Received: by PTT.LCS.MIT.EDU id AA02631; Wed, 3 Jul 91 21:48:54 EDT Date: Wed, 3 Jul 91 21:48:54 EDT From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Message-Id: <9107040148.AA02631@PTT.LCS.MIT.EDU> To: ietf-ppp@ucdavis.edu Subject: WG Activities Cc: jnc@PTT.LCS.MIT.EDU Guys, I have spoken to Stev Knowles, and he indicates that he is unable to give the PPP activity the attention it deserves. That being the case, we need to find a new chair; I'm not sure if that will be possible prior to the next IETF (in Atlanta), but I'll try. I will serve as a temporary chair in the meantime; I asked for a time slot at the IETF since there seems (from the mailing list over the last two weeks at any rate) like there is enough going on that a meeting was useful. I put in for Tuesday morning, on the grounds that if the debate overran the morning it could be extended into the afternoon. (Tuesday was picked to minimize conflicts with other WG's). Do people think there is enough going on that more time slots on Tuesday should be scheduled at this point? Do people think no meeting is needed at all? (Do *not* email me personally; call me at 804-898-8183 between 11AM-5PM EDT.) I will try and get all the documents done up to now pushed through the I-D process to RFC's and into the appropriate stage of the standards process (DS for the LCP and IPCP, PS for the others such as DN-IV, etc). I have pulled *all* the PPP stuff (including the multiple archaic versions) down from the I-D directory, and will read up on it to bring myself up to speed. I will look at the stuff that was submitted to the mailing list, or me, after that. If everyone could stop submitting stuff to I-D for a few days I would really appreciate it (I'm over my head in drafts :-). Also, I would like to make sure that a) all drafts say to send comments to the PPP mailing list (not the chair), so that the comments will be i) seen and ii) archived, and b) that where appropriate, drafts indicate that the protocols are soon to advance in standards status. A paragraph of the form below needs to be inserted where appropriate. (I will probably have to get the two that were just submitted modified.) "Comments on this memo should be submitted to the IETF Point-to-Point Protocol Working Group mailing list (ietf-ppp@ucdavis.edu) by July 23, 1991. Comments will be reviewed at the July/August 1991 IETF meeting, with the goal of advancing XXX to {Proposed/Draft} Standard status." However, I need to check with the IESG to see if it is too soon before the IETF to try and move these things onto/along the standards track at the IETF. If it is, they can still go out as RFC's/standards between IETF's, hopefully shortly after the IETF. Speaking of which, according the guidelines for a standard to advance from Proposed to Draft, to go to DS there has to be experience with several interoperable implementations of the latest version. For both the LCP and IPCP (which are currently at PS), do we have that experience for the latest I-D versions? I'm aware there are two communities using this, the high speed sync guys and the lower speed async guys; can someone from each community summarize to the list what implementations exist of each that match the latest I-D? If everyone was waiting on them to go out as I-D's (which just happened), then I guess the answer is no, but not being closely connected to the serial community (and having not yet read back through the list archives to see what I missed) I must apologize for not knowing. Noel From ietf-ppp-request@ucdavis.ucdavis.edu Sat Jul 6 08:30:04 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25472; Sat, 6 Jul 91 08:00:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from cs.utexas.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25456; Sat, 6 Jul 91 07:57:59 -0700 From: ibmchs!uucp@cs.utexas.edu Received: from ibmchs by cs.utexas.edu (5.64/1.104) with UUCP id AA11834; Sat, 6 Jul 91 08:24:22 -0500 Received: by ibmchs (AIX 2.1 2/4.03) id AA21706; Fri, 5 Jul 91 01:50:08 CDT Date: Fri, 5 Jul 91 01:50:08 CDT Message-Id: <9107050650.AA21706@ibmchs> To: ucdavis.edu!ietf-ppp@cs.utexas.edu Subject: Warning From uucp We have been unable to contact machine 'auschs' since you queued your job. auschs!mail keung.austin.ibm.com!keung (Date 07/03) The job will be deleted in several days if the problem is not corrected. If you care to kill the job, execute the following command: uustat -kauschsCd78e Sincerely, ibmchs!uucp ############################################# ##### Data File: ############################ From cs.utexas.edu!ucdavis.edu!ietf-ppp-request Wed Jul 3 21:17:10 1991 remote from ibmchs Received: by ibmchs (AIX 2.1 2/4.03) id AA14316; Wed, 3 Jul 91 21:17:10 CDT Received: from ucdavis.ucdavis.edu by cs.utexas.edu (5.64/1.104) with SMTP id AA07336; Wed, 3 Jul 91 20:49:55 -0500 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09798; Wed, 3 Jul 91 18:01:02 -0700 Sender: ibmchs!ietf-ppp-request@ucdavis.edu Received: from wolf.cisco.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA09781; Wed, 3 Jul 91 17:58:32 -0700 Received: from lager.cisco.com by wolf.cisco.com with TCP; Wed, 3 Jul 91 17:44:37 -0700 Message-Id: <9107040044.AA07874@wolf.cisco.com> To: katz@merit.edu Cc: bsimpson@vela.acs.oakland.edu, fbaker@acc.com, ietf-ppp@ucdavis.edu Subject: Re: CLNS draft In-Reply-To: Your message of "Wed, 03 Jul 91 14:23:56 EDT." <9107031823.AA08686@home.merit.edu> Date: Wed, 03 Jul 91 17:46:20 MDT From: Jim Forster >> As I spec'ed in the draft, the NCP should be for the whole OSI Network >> Layer, not just CLNP. Address assignment should be done with ES-IS... >> but I guess I agree. Yes, I oversimplified. Rather than address assignment, perhaps a better term would be address verification. This seems to be very useful for a circuit-switched (dialup) enviroment, where you want to be sure you've reached the point you think you have, by verifying that the address at the other end is what you're expecting. Arguably, this could be handled by LCP-level authentication just as well. OK, how bout this one: if someone comes up with VJ-Style header compression for OSI this would be nice to negotiate in an option. But I belabor the point; it looks like we're agreed that OSI CLNP should be a full-fledged NCP by itself. Enough talk. On to the action items Fred has called for. -- Jim From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 8 09:45:34 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23013; Mon, 8 Jul 91 09:00:34 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22863; Mon, 8 Jul 91 08:50:05 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA08844; Mon, 8 Jul 91 11:49:31 EDT Message-Id: <9107081549.AA08844@TIS.COM> To: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu, crocker@TIS.COM, bsimpson@vela.acs.oakland.edu (Bill Simpson), brian@telebit.com Subject: Re: PPP Authentication protocol In-Reply-To: Your message of Tue, 25 Jun 91 10:08:47 EDT. <9106251408.AA12946@ftp.com> Date: Mon, 08 Jul 91 11:49:29 -0400 From: balenson@TIS.COM > if security is required, assistance from the people who understand security > is most appreciated. i would rather the person who is going to be dealing > with it be the one to express his views anyway, i fell better arguing with > the author of an idea, not the courier . . . .:) Here, at long last, are my initial comments regarding the recent PPP Authentication Protocols draft. Steve Crocker asked me to share these comments with you and to open up a security discussion on the ietf-ppp@ucdavis.edu mailing list (of which I am now a subscriber). These are initial comments and should be followed by additional discussions and comments. The password-based protocol is, by its own admission, not a strong authentication protocol. Both identities and passwords are passed in the clear and there is no protection against repeated trial and error attacks. It may or may not be even worth considering such a weak protocol. The cryptographic challenge-response protocol is really very simple, in fact, it's too simple. To be authenticated I first identify myself, then I am sent a random number which I "permute" using the algorithm "described in the appendix", and finally I return the result. First and foremost, my concern is how does this provide any security? It seems to me that I could be anyone claiming to be anyone else, and still be able to use QCMDC to permute the random number I am sent. There's no secrets involved! Perhaps I am missing something, or something is missing from the protocol specification? Putting that aside, I have several other concerns regarding the crypto- graphic challenge-response protocol: (1) The specification does not describe the representation of the random number, just that it is 8 octets long. (2) The algorithm "described" in the appendix is the Jueneman/Matyas/Meyer QCMDC algorithm, and it is not really described. The appendix contains C code taken from the MIT Athena DES library for Kerberos, and contains a very brief description as comments. The code also contains a comment that indicates "No guarantees are offered for its security." Given recent revelations about potential weaknesses in QCMDC, if a hash like QCMDC is in fact required here, we should probably consider one of the RSADSI MD{2,4,5} algorithms. (3) There is no explanation of how the server responds to the permuted result that I send it, e.g., that the server should also permute the random number and compare it to the permuted value that I return. (4) There are provisions of ACK and NAKs, but no explanation of their use. Is it possible that the author inadvertently omitted the part of the text that provides the missing information? The SAAG is probably in the best position to work with the PPP folks in coming up with an adequate (set of) authentication protocol(s). Things to consider include the current work on authentication for SNMP (the issues there are both similar and different), the use of public key cryptography (e.g., facilities based on the RSA-based certificate infrastructure being deployed as a part of Privacy Enhanced Mail (PEM)), and the new IETF Common Authentication Technology (CAT) Working Group whose goal is to provide strong authentication to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms (I can provide additional details later). So, let's open this up to general discussion. I'm here, ready, willing and able to offer any assistance that may be required as well as a link to both the SAAG and PSRG. -David Balenson From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 8 09:46:50 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA23166; Mon, 8 Jul 91 09:09:54 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22872; Mon, 8 Jul 91 08:51:03 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA08897; Mon, 8 Jul 91 11:50:43 EDT Message-Id: <9107081550.AA08897@TIS.COM> To: ietf-ppp@ucdavis.edu Subject: FYI: Comments on QCMDC Date: Mon, 08 Jul 91 11:50:43 -0400 From: balenson@TIS.COM ------- Forwarded Message Delivery-Date: Mon, 24 Jun 91 13:06:46 -0400 >From kent@BBN.COM Mon Jun 24 13:05:19 1991 Return-Path: Message-Id: <9106241705.AA29124@TIS.COM> To: Stephen D Crocker Cc: saag@TIS.COM Subject: Re: [bsimpson@vela.acs.oakland.edu (Bill Simpson): PPP Authentication protocols] In-Reply-To: Your message of Fri, 21 Jun 91 00:12:28 -0400. <9106210412.AA27295@TIS.COM> Date: Mon, 24 Jun 91 12:57:46 -0400 From: Steve Kent Steve, Oh, no, not QCMDC again! I recall that we rejected QCMDC in the SNMP security work a while ago after PSRG members identified a numer of security concerns. This algorithm is not viewed as being especially secure for this sort of application (i.e., hashing w/o encryption), it is especially questionable when used to transform a very short quantity (as is likely to be the for these challange-response values), and the Kerberos code included in the text (if it's the saem as last time) doesn't implement the algorithm as cited in the literature! Other than that, it's a fine choice (to paraphrase Stormin' Norman). Steve ------- End of Forwarded Message From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 8 16:48:22 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01727; Mon, 8 Jul 91 16:16:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA01503; Mon, 8 Jul 91 16:03:31 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA00736 to ietf-ppp@ucdavis.edu; Mon, 8 Jul 91 15:58:20 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA07037 to stev@ftp.com; Mon, 8 Jul 91 16:02:26 PDT Date: Mon, 8 Jul 91 16:02:26 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107082302.AA07037@napa.TELEBIT.COM> To: balenson@TIS.COM Cc: stev@ftp.com, ietf-ppp@ucdavis.edu, crocker@TIS.COM, bsimpson@vela.acs.oakland.edu In-Reply-To: balenson@TIS.COM's message of Mon, 08 Jul 91 11:49:29 -0400 <9107081549.AA08844@TIS.COM> Subject: PPP Authentication protocol Reply-To: David M Balenson Date: Mon, 08 Jul 91 11:49:29 -0400 From: balenson@TIS.COM The cryptographic challenge-response protocol is really very simple, in fact, it's too simple. To be authenticated I first identify myself, then I am sent a random number which I "permute" using the algorithm "described in the appendix", and finally I return the result. First and foremost, my concern is how does this provide any security? It seems to me that I could be anyone claiming to be anyone else, and still be able to use QCMDC to permute the random number I am sent. There's no secrets involved! Perhaps I am missing something, or something is missing from the protocol specification? It was real rough. I gave cursory info to Bill Simpson and he quickly put it into a rough form. Basically it needs to be fleshed out just a little more. The challenger generates a 64 bit pseudo random number. The peer being challenged permutes the challenge using the QCMDC algorithm AND a key that is known to both ends (this is why you need to know who the remote peer purports to be). The challenger performs the same process and then compares the local result with the remote response. Putting that aside, I have several other concerns regarding the crypto- graphic challenge-response protocol: (1) The specification does not describe the representation of the random number, just that it is 8 octets long. Right, the bit-ordering should be specified. (2) The algorithm "described" in the appendix is the Jueneman/Matyas/Meyer QCMDC algorithm, and it is not really described. The appendix contains C code taken from the MIT Athena DES library for Kerberos, and contains a very brief description as comments. The code also contains a comment that indicates "No guarantees are offered for its security." Given recent revelations about potential weaknesses in QCMDC, if a hash like QCMDC is in fact required here, we should probably consider one of the RSADSI MD{2,4,5} algorithms. No problem. In our original version we started to use DES but the software implementation was just too slow so we used QCMDC. (3) There is no explanation of how the server responds to the permuted result that I send it, e.g., that the server should also permute the random number and compare it to the permuted value that I return. Yes. (4) There are provisions of ACK and NAKs, but no explanation of their use. Actually when I proposed the scheme to Bill Simpson I did not even bother with ACKs or NAKs. I expected that, if the authentication succeeded PPP would proceed on to the NCP negotiation and if it failed it would shut down the link. An ACK or NAK became superfluous. Is it possible that the author inadvertently omitted the part of the text that provides the missing information? Yes, it is possible. Actually I am quite pleased that Bill did as much as he did as quickly as he did. The SAAG is probably in the best position to work with the PPP folks in coming up with an adequate (set of) authentication protocol(s). Things to consider include the current work on authentication for SNMP (the issues there are both similar and different), the use of public key cryptography (e.g., facilities based on the RSA-based certificate infrastructure being deployed as a part of Privacy Enhanced Mail (PEM)), and the new IETF Common Authentication Technology (CAT) Working Group whose goal is to provide strong authentication to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms (I can provide additional details later). Well, we do not want to spend a great deal of time coming up with the perfect authentication scheme. All I had hoped to accomplish was to get something that was better than user/password authentication. I think that the crypto handshake is a great improvement since the key is never sent over the link and it is relatively immune to a playback attack. I do agree that we could probably come up with a better encyphering algorithm but do consider that all we need is a function that will permute a 64 bit entity in an irreversable manner using a 56-64 bit key. So, let's open this up to general discussion. I'm here, ready, willing and able to offer any assistance that may be required as well as a link to both the SAAG and PSRG. -David Balenson Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 8 19:00:25 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04514; Mon, 8 Jul 91 18:45:16 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04303; Mon, 8 Jul 91 18:34:13 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA29093; Mon, 8 Jul 91 21:33:39 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107090133.AA29093@vela.acs.oakland.edu> Subject: Re: PPP Authentication protocol To: balenson@tis.com Date: Mon, 8 Jul 91 20:51:50 EDT In-Reply-To: <9107081549.AA08844@TIS.COM>; from "balenson@TIS.COM" at Jul 8, 91 11:49 am X-Mailer: ELM [version 2.3 PL6] > These are initial comments and should be followed by additional > discussions and comments. > I would like to take this time to publicly thank the SAAG for taking a look at this! > The password-based protocol is, by its own admission, not a strong > authentication protocol. Both identities and passwords are passed in > the clear and there is no protection against repeated trial and error > attacks. It may or may not be even worth considering such a weak > protocol. > PAP was described in RFC 1172 for use with PPP. Many folks were dissatified with it, which is why we are trying to come up with a better protocol. Unfortunately, it has been widely implemented, and should continue to be described in this revision. Question for the group: should we specifically state that no there should be no *NEW* implementations? > The cryptographic challenge-response protocol is really very simple, in > fact, it's too simple. To be authenticated I first identify myself, > then I am sent a random number which I "permute" using the algorithm > "described in the appendix", and finally I return the result. First > and foremost, my concern is how does this provide any security? It > seems to me that I could be anyone claiming to be anyone else, and > still be able to use QCMDC to permute the random number I am sent. > There's no secrets involved! Perhaps I am missing something, or > something is missing from the protocol specification > You missed the single sentence in the first paragraph. I will be glad to expand upon that sentence. There is a secret key known to both ends. The algorithm calculates a response to the random number using the secret key, and the challenger checks the response to see if it was correct. > Putting that aside, I have several other concerns regarding the crypto- > graphic challenge-response protocol: > > (1) The specification does not describe the representation of the > random number, just that it is 8 octets long. > Internet RFC standard, high byte first. (I will fix.) > (2) The algorithm "described" in the appendix is the > Jueneman/Matyas/Meyer QCMDC algorithm, and it is not really > described. The appendix contains C code taken from the MIT Athena > DES library for Kerberos, and contains a very brief description as > comments. The code also contains a comment that indicates "No > guarantees are offered for its security." Given recent revelations > about potential weaknesses in QCMDC, if a hash like QCMDC is in > fact required here, we should probably consider one of the RSADSI > MD{2,4,5} algorithms. > This is supposed to be a simple RFC describing protocols, not a treatise on strengths and weaknesses of various hashing algorithms. The C code *IS* the specification. Everyone who uses the code will arrive at the same result. Remember, this exchange occurs only *once* during startup of the connection. So we don't need anything terribly elaborate. It would take a *very* long time to collect enough traffic from the same user to determine the key, whatever the algorithm. Any algorithm we choose must: (a) be short, simple C code -- preferably less than 100 lines. (b) be in the public domain. > (3) There is no explanation of how the server responds to the permuted > result that I send it, e.g., that the server should also permute > the random number and compare it to the permuted value that I > return. > Noted above (I will fix.) > (4) There are provisions of ACK and NAKs, but no explanation of their > use. > There are Acks and Naks in PAP. There is no mechanical reason for them, they are just a convenience. As described to me, CHAP has no Acks or Naks, other than continuing or terminating the connection. I reserved a couple of numbers for them, and asked the group whether we want them, but the text doesn't have them (yet). Question for the group: Do we want the extra ability to send a result message, just like PAP? > The SAAG is probably in the best position to work with the PPP folks in > coming up with an adequate (set of) authentication protocol(s). Which is why I invited you to become involved. > ... and the new IETF Common Authentication Technology (CAT) Working > Group whose goal is to provide strong authentication to a variety of > protocol callers in a manner which insulates those callers from the > specifics of underlying security mechanisms (I can provide additional > details later). Just what we need! Is this just starting? How do we get informed/involved? > -David Balenson > Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 9 08:20:15 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18270; Tue, 9 Jul 91 08:01:48 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from tymix.Tymnet.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18141; Tue, 9 Jul 91 07:53:13 -0700 Received: from spiff.Tymnet.COM by tymix.Tymnet.COM (4.1/SMI-4.1) id AA25343; Tue, 9 Jul 91 07:52:37 PDT Received: from sagehen.Tymnet.COM by spiff.Tymnet.COM (4.1/SMI-4.1) id AA01801; Tue, 9 Jul 91 07:52:36 PDT Date: Tue, 9 Jul 91 07:52:36 PDT From: drawson@Tymnet.COM (Dick Rawson) Message-Id: <9107091452.AA01801@spiff.Tymnet.COM> To: bsimpson@vela.acs.oakland.edu Subject: Re: PPP Authentication protocol Cc: ietf-ppp@ucdavis.edu > Question for the group: should we specifically state that no there > should be no *NEW* implementations? [Reading his lips...] So that a new PPP, supporting only CHAP, cannot interwork with an (old) PAP PPP? Do we want that? Perhaps better: new PPP implementations should not support PAP unless they also support CHAP. Dick Rawson From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 9 10:05:06 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20414; Tue, 9 Jul 91 09:47:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20186; Tue, 9 Jul 91 09:37:07 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA09523 to ietf-ppp@ucdavis.edu; Tue, 9 Jul 91 09:31:53 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA08626 to bsimpson@vela.acs.oakland.edu; Tue, 9 Jul 91 09:35:56 PDT Date: Tue, 9 Jul 91 09:35:56 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107091635.AA08626@napa.TELEBIT.COM> To: drawson@tymnet.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu In-Reply-To: Dick Rawson's message of Tue, 9 Jul 91 07:52:36 PDT <9107091452.AA01801@spiff.Tymnet.COM> Subject: PPP Authentication protocol No, as I planned it, a PPP implementation may implement PAP, CHAP, both, or neither. There are a number of PPP implementations that are really stripped down (don't support any options at all except the basic LCP and IPCP) and we need to provide compatibility with them. I also intended CHAP to be totally stateless so that either end could issue a CHAP challenge -AT ANY TIME- regardless of what "phase" you were in (well you do have to have the LCP running first). I envisioned the ability to periodically challenge the peer to avoid a "bait and switch" attack. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 9 13:52:19 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24631; Tue, 9 Jul 91 13:18:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24519; Tue, 9 Jul 91 13:12:48 -0700 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA24413; Tue, 9 Jul 91 14:31:34 -0400 Date: Tue, 9 Jul 91 14:31:34 -0400 Message-Id: <9107091831.AA24413@ftp.com> To: bsimpson@vela.acs.oakland.edu (Bill Simpson) Subject: Re: PPP Authentication protocol From: stev@ftp.com (stev knowles) Cc: balenson@tis.com, ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com Question for the group: should we specifically state that no there should be no *NEW* implementations? you probably can not get away with this, it tries to handcuff people from building a backwards compaitble version. one thing to remember is that if the new security method is not alot better than the old one, alot of people will not want to upgrade. a 10% improvement is not enough to convince people to go through the effort of installing new software and changing their proceedures. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 9 14:23:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24941; Tue, 9 Jul 91 13:31:06 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from ftp.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24541; Tue, 9 Jul 91 13:13:29 -0700 Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA24185; Tue, 9 Jul 91 14:25:44 -0400 Date: Tue, 9 Jul 91 14:25:44 -0400 Message-Id: <9107091825.AA24185@ftp.com> To: David M Balenson Subject: Re: PPP Authentication protocol From: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com to consider include the current work on authentication for SNMP (the issues there are both similar and different), the use of public key cryptography (e.g., facilities based on the RSA-based certificate infrastructure being deployed as a part of Privacy Enhanced Mail (PEM)), and the new IETF Common Authentication Technology (CAT) Working Group whose goal is to provide strong authentication to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms (I can provide additional details later). So, let's open this up to general discussion. I'm here, ready, willing and able to offer any assistance that may be required as well as a link to both the SAAG and PSRG. i would rather not screw up PPP like SNMP got screwed up. i woudl also rather not introduce a protocol that involved either export resrtictions or the payment of royalities to a 3rd party. From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 9 17:45:42 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29779; Tue, 9 Jul 91 17:30:26 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA29500; Tue, 9 Jul 91 17:17:25 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA12990 to ietf-ppp@ucdavis.edu; Tue, 9 Jul 91 17:12:15 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA23951 to balenson@tis.com; Tue, 9 Jul 91 17:16:14 PDT Date: Tue, 9 Jul 91 17:16:14 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107100016.AA23951@napa.TELEBIT.COM> To: stev@babyoil.ftp.COM Cc: balenson@tis.com, ietf-ppp@ucdavis.edu In-Reply-To: stev knowles's message of Tue, 9 Jul 91 14:25:44 -0400 <9107091825.AA24185@ftp.com> Subject: PPP Authentication protocol There are no export restrictions on authentication schemes, only on encryption schemes so CHAP should be just fine with the DOC, thanks. I agree wholeheartedly about public domain algorithms too. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 9 18:31:53 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00618; Tue, 9 Jul 91 18:16:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from research.att.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA00591; Tue, 9 Jul 91 18:14:24 -0700 Message-Id: <9107100114.AA00591@ucdavis.ucdavis.edu> Received: by inet; Tue Jul 9 21:13 EDT 1991 From: smb@ulysses.att.com To: brian@napa.Telebit.COM (Brian Lloyd) Cc: stev@babyoil.ftp.COM, balenson@tis.com, ietf-ppp@ucdavis.edu Subject: Re: PPP Authentication protocol Date: Tue, 09 Jul 91 21:13:40 EDT There are no export restrictions on authentication schemes, only on encryption schemes so CHAP should be just fine with the DOC, thanks. Yes, but. Yes, authentication schemes are fine; however, I don't think that a vendor would be able to deliver source code (or linkable object code) that implemented (say) DES, even if the intent was to use it solely for challenge/response authentication schemes. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 10 08:17:55 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11091; Wed, 10 Jul 91 08:01:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10823; Wed, 10 Jul 91 07:49:49 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA23325; Wed, 10 Jul 91 10:49:14 EDT Message-Id: <9107101449.AA23325@TIS.COM> To: brian@napa.telebit.com Cc: stev@ftp.com, ietf-ppp@ucdavis.edu, bsimpson@vela.acs.oakland.edu Subject: Re: PPP Authentication protocol In-Reply-To: Your message of Mon, 08 Jul 91 16:02:26 PDT. <9107082302.AA07037@napa.TELEBIT.COM> Date: Wed, 10 Jul 91 10:49:13 -0400 From: balenson@TIS.COM > It was real rough. I gave cursory info to Bill Simpson and he quickly > put it into a rough form. Basically it needs to be fleshed out just a > little more. Great, let's go for it! > The challenger generates a 64 bit pseudo random number. The peer > being challenged permutes the challenge using the QCMDC algorithm AND > a key that is known to both ends (this is why you need to know who the > remote peer purports to be). The challenger performs the same process > and then compares the local result with the remote response. Ok, that's the kind of explanation that needed, though perhaps in some greater detail. I would suggest adding to the draft a few additional paragraphs of elaboration. I would also suggest adding to the draft a section that specifically deals with key management, that is, the establishment of secret keys between peers. > (2) The algorithm "described" in the appendix is the > Jueneman/Matyas/Meyer QCMDC algorithm, and it is not really > described. The appendix contains C code taken from the MIT Athena > DES library for Kerberos, and contains a very brief description as > comments. The code also contains a comment that indicates "No > guarantees are offered for its security." Given recent revelations > about potential weaknesses in QCMDC, if a hash like QCMDC is in > fact required here, we should probably consider one of the RSADSI > MD{2,4,5} algorithms. > No problem. In our original version we started to use DES but the > software implementation was just too slow so we used QCMDC. I recommend that QCMDC *not* be considered. Instead, I would suggest using one of the RSADSI MD{4,5} message digest (i.e., hash) algorithms to hash the secret key and the random number. This is, in fact, similar to the approach taken with SNMP Authentication which hashes a secret key and an SNMP message containing a date/time stamp rather than a random number. MD4 was previously described in RFC 1186. A draft revised RFC 1186 and a draft describing MD5 have just been submitted by RSADSI as Internet drafts intended to be considered as standards-track RFCs. I will provide some references in a separate message. > Well, we do not want to spend a great deal of time coming up with the > perfect authentication scheme. All I had hoped to accomplish was to > get something that was better than user/password authentication. I > think that the crypto handshake is a great improvement since the key > is never sent over the link and it is relatively immune to a playback > attack. I do agree that we could probably come up with a better > encyphering algorithm but do consider that all we need is a function > that will permute a 64 bit entity in an irreversable manner using a > 56-64 bit key. I understand. I think that use of the MD{4,5} algorithm in the manner described above satisfies your concerns. -DB From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 10 08:31:40 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA11143; Wed, 10 Jul 91 08:05:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10821; Wed, 10 Jul 91 07:49:49 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA23334; Wed, 10 Jul 91 10:49:18 EDT Message-Id: <9107101449.AA23334@TIS.COM> To: bsimpson@vela.acs.oakland.edu (Bill Simpson) Cc: ietf-ppp@ucdavis.edu Subject: Re: PPP Authentication protocol In-Reply-To: Your message of Mon, 08 Jul 91 20:51:51 EDT. <9107090051.AA28089@vela.acs.oakland.edu> Date: Wed, 10 Jul 91 10:49:17 -0400 From: balenson@TIS.COM > PAP was described in RFC 1172 for use with PPP. Many folks were dissatified > with it, which is why we are trying to come up with a better protocol. > Unfortunately, it has been widely implemented, and should continue to > be described in this revision. Ok, I can accept that. > Question for the group: should we specifically state that no there should be > no *NEW* implementations? I would recommend this. > You missed the single sentence in the first paragraph. I will be glad > to expand upon that sentence. There is a secret key known to both ends. > The algorithm calculates a response to the random number using the secret > key, and the challenger checks the response to see if it was correct. Indeed, there's a hidden reference to a "hidden" secret key. However, for purposes of a complete specification, we'll need to be much more explicit. I would recommend adding to the draft a few additional paragraphs explaining the crypto handshake in more elaborate detail, as well as adding to the draft a complete section that specifically addresses key management, that is, the establishment and use of secret keys between peers. > This is supposed to be a simple RFC describing protocols, not a treatise > on strengths and weaknesses of various hashing algorithms. Agreed. > The C code > *IS* the specification. Everyone who uses the code will arrive at the > same result. We can do better than that. In any case, I do not recommend QCMDC. > Any algorithm we choose must: > (a) be short, simple C code -- preferably less than 100 lines. > (b) be in the public domain. I do recommend MD{4,5}. They have both been specified as Internet-Drafts which handle all of the algorithm-specific details including dicussions of strnegths and weaknesses, AND they include C implementations. I believe that both algorithms satisfy your requirements. > > ... and the new IETF Common Authentication Technology (CAT) Working > > Group whose goal is to provide strong authentication to a variety of > > protocol callers in a manner which insulates those callers from the > > specifics of underlying security mechanisms (I can provide additional > > details later). > Just what we need! Is this just starting? How do we get informed/involved? Maybe. The CAT effort is just starting and it may be some time before it can be easily incorporated into applications such as PPP. CAT is essentially an Application Programming Interface (API) which would overlay authentication protocols such as Kerberos and DEC's SPX. An Internet-Draft describing CAT, draft-ietf-cat-genericsec-00.{txt,ps}, is now available, and an Internet-Draft describing Kerberos, ieft-ietf-cat-kerberos-00.{txt,ps}. I would recommend that we proceed with PAP and CHAP for now, with an eye towards CAT for possible future incorporation. -DB From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 10 10:35:58 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13949; Wed, 10 Jul 91 10:16:32 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from SGI.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA13671; Wed, 10 Jul 91 10:02:16 -0700 Received: from whizzer.wpd.sgi.com by sgi.sgi.com via SMTP (910618.SGI/910110.SGI) for ietf-ppp@ucdavis.edu id AA02873; Wed, 10 Jul 91 10:01:27 -0700 Received: from rigden.wpd.sgi.com by whizzer.wpd.sgi.com via SMTP (910524.SGI/910523.SGI.autocf) for @sgi.sgi.com:ietf-ppp@ucdavis.edu id AA12155; Wed, 10 Jul 91 10:01:22 -0700 Received: by rigden.wpd.sgi.com (5.52/900721.SGI) for @whizzer.wpd.sgi.com:smb@ulysses.att.com id AA11616; Wed, 10 Jul 91 17:01:20 GMT Date: Wed, 10 Jul 91 17:01:20 GMT From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Message-Id: <9107101701.AA11616@rigden.wpd.sgi.com> To: smb@ulysses.att.com Subject: Re: PPP Authentication protocol Cc: ietf-ppp@ucdavis.edu, balenson@tis.com, stev@babyoil.ftp.COM, brian@napa.Telebit.COM +--------------- | There are no export restrictions on authentication schemes, only on | encryption schemes so CHAP should be just fine with the DOC, thanks. | Yes, but. Yes, authentication schemes are fine; however, I don't think | that a vendor would be able to deliver source code (or linkable object | code) that implemented (say) DES, even if the intent was to use it | solely for challenge/response authentication schemes. +--------------- I dunno... They allow the export of the encryption-only part of the Unix DES-like "crypt" library routine used by "login" (and others) for password verification, just not the general encrypt/decrypt functions. I imagine other DES-based authentication schemes might be allowed, provided that they could not be used for general encryption/decryption. -Rob ----- Rob Warnock, MS-1L/515 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311 From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 14 16:30:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16271; Sun, 14 Jul 91 16:16:55 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from CAYMAN.CAYMAN.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16222; Sun, 14 Jul 91 16:12:24 -0700 Received: from caicos.engineering ([143.137.50.9]) by cayman.Cayman.COM (4.1/SMI-4.0) id AA19459; Sun, 14 Jul 91 19:11:26 EDT Received: by caicos.engineering (4.1/SMI-4.1) id AA20372; Sun, 14 Jul 91 19:11:28 EDT Date: Sun, 14 Jul 91 19:11:28 EDT From: brad@Cayman.COM (Brad Parker) Message-Id: <9107142311.AA20372@caicos.engineering> To: ietf-ppp@ucdavis.edu Cc: bkc@omnigate.clarkson.edu, karl@MorningStar.Com Subject: I have some fixes for "ppp-sparc4.1", patchlevel 4 X-Zippy: Excuse me, but didn't I tell you there's NO HOPE for the survival of OFFSET PRINTING? I pulled the "latest" unix PPP code off uunet. It unpacks into dir called "ppp-sparc4.1" and claims to be "PATCHLEVEL 4". I fixed it to negotiated the "new" VJ tcp compression option and made the default async map zero. I also have some bug fixes for crashing which occurs when you send it a protocol it does not understand (like appletalk or ipx ;-) I seems to work just fine (In fact, I'm soaking in it!) Can whomever maintains this please drop me a note if they would like the diffs? -brad From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 14 18:16:03 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17380; Sun, 14 Jul 91 18:00:12 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17238; Sun, 14 Jul 91 17:46:21 -0700 Received: from crappie.morningstar.com by volitans.morningstar.com (5.65a/91071202) id AA14888; Sun, 14 Jul 91 20:45:04 -0400 Received: by crappie.morningstar.com (5.65a/91071202) id AA01609; Sun, 14 Jul 91 20:44:33 -0400 Date: Sun, 14 Jul 91 20:44:33 -0400 From: Karl Fox Message-Id: <9107150044.AA01609@crappie.morningstar.com> To: brad@Cayman.COM (Brad Parker) Cc: bkc@omnigate.clarkson.edu, ietf-ppp@ucdavis.edu In-Reply-To: <9107142311.AA20372@caicos.engineering> Subject: I have some fixes for "ppp-sparc4.1", patchlevel 4 Brad Parker writes: > > I pulled the "latest" unix PPP code off uunet. It unpacks into dir called > "ppp-sparc4.1" and claims to be "PATCHLEVEL 4". I fixed it to negotiated > the "new" VJ tcp compression option and made the default async map zero. > I also have some bug fixes for crashing which occurs when you send it > a protocol it does not understand (like appletalk or ipx ;-) > > I seems to work just fine (In fact, I'm soaking in it!) Can whomever > maintains this please drop me a note if they would like the diffs? > > -brad I posted the "PATCHLEVEL 4" version, so I suppose you should send your patches to me. I have received several other suggested fixes that I really ought to put together and make available. However, I don't run it anymore (I use our about-to-be-released commercial version), so it would be a major effort for me to test the resulting "PATCHLEVEL 5" version. Are you (or anyone else out there) interested in testing it, or maybe even maintaining it? If you would rather not be the recipient of half a dozen e-mail requests for help each week, I would understand, but I do need someone to tell me whether or not it works. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 12:50:47 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03199; Mon, 15 Jul 91 12:31:39 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03065; Mon, 15 Jul 91 12:27:00 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA15408 to ietf-ppp@ucdavis.edu; Mon, 15 Jul 91 11:37:01 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA20084 to ietf-ppp@ucdavis.edu; Mon, 15 Jul 91 11:40:29 PDT Date: Mon, 15 Jul 91 11:40:29 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107151840.AA20084@napa.TELEBIT.COM> To: ietf-ppp@ucdavis.edu Subject: CHAP and MD{4|5} I have been unable to find where MD4/5 allows the user to specify a key for authentication. It looks like it would work for preventing a packet modification attack but not for authentication. I need enlightenment. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 13:19:40 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03799; Mon, 15 Jul 91 13:03:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03588; Mon, 15 Jul 91 12:51:48 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA23162; Mon, 15 Jul 91 15:51:16 EDT Message-Id: <9107151951.AA23162@TIS.COM> To: stev@ftp.com (stev knowles) Cc: ietf-ppp@ucdavis.edu Subject: Re: PPP Authentication protocol In-Reply-To: 's message of Tue, 09 Jul 91 14:25:44 EDT. <9107091825.AA24185@ftp.com> Date: Mon, 15 Jul 91 15:51:15 -0400 From: James M Galvin i would rather not screw up PPP like SNMP got screwed up. i woudl also rather not introduce a protocol that involved either export resrtictions or the payment of royalities to a 3rd party. In what way was SNMP screwed up by security? We should probably take this discussion to the "snmp-sec-dev@tis.com" mailing list, or keep it private. And, just to be clear, export and security are tightly-coupled issues. At least, it is somewhat of a challenge to do security without dealing with export restrictions. All companies planning to support security will need to face this issue eventually. Also, just to be clear, SNMP security does not "owe" any royalties to any third party. Jim (Co-author, SNMP Security Protocols) From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 13:50:10 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04554; Mon, 15 Jul 91 13:35:27 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04096; Mon, 15 Jul 91 13:17:41 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA25715; Mon, 15 Jul 91 16:17:09 EDT Message-Id: <9107152017.AA25715@TIS.COM> To: brian@napa.telebit.com (Brian Lloyd) Cc: ietf-ppp@ucdavis.edu Subject: Re: CHAP and MD{4|5} In-Reply-To: Your message of Mon, 15 Jul 91 11:40:29 PDT. <9107151840.AA20084@napa.TELEBIT.COM> Date: Mon, 15 Jul 91 16:17:08 -0400 From: balenson@TIS.COM > I have been unable to find where MD4/5 allows the user to specify a > key for authentication. It looks like it would work for preventing a > packet modification attack but not for authentication. I need > enlightenment. It doesn;t provide an explicit means for that. What we would do is prepend the key to the data (i.e., the random number) to be hashed, that is, the hash would be computed on the concatenation of the key and the random number. -DB From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 14:09:09 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04611; Mon, 15 Jul 91 13:38:31 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04208; Mon, 15 Jul 91 13:21:00 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA08790; Mon, 15 Jul 91 16:20:06 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107152020.AA08790@vela.acs.oakland.edu> Subject: Re: CHAP and MD{4|5} To: brian@napa.telebit.com (Brian Lloyd) Date: Mon, 15 Jul 91 16:20:06 EDT Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9107151840.AA20084@napa.TELEBIT.COM>; from "Brian Lloyd" at Jul 15, 91 11:40 am X-Mailer: ELM [version 2.3 PL6] I had the same thoughts! But I talked to Dave Balenson & Steve Crocker and learned that the private key is concatenated to the message before passing it through the message digest. (Of course, we would need to standardize whether it's the head or tail of the message.) Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 14:33:04 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04705; Mon, 15 Jul 91 13:44:14 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from research.att.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04378; Mon, 15 Jul 91 13:28:26 -0700 Message-Id: <9107152028.AA04378@ucdavis.ucdavis.edu> Received: by inet; Mon Jul 15 16:27 EDT 1991 From: smb@ulysses.att.com To: brian@napa.Telebit.COM (Brian Lloyd) Cc: ietf-ppp@ucdavis.edu Subject: Re: CHAP and MD{4|5} Date: Mon, 15 Jul 91 16:27:11 EDT I have been unable to find where MD4/5 allows the user to specify a key for authentication. It looks like it would work for preventing a packet modification attack but not for authentication. I need enlightenment. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terra ce brian@telebit.com Sunnyvale, CA 94089-1 100 voice (408) 745-3103 FAX (408) 734-3333 The idea, presumably, is to use MD[45] to hash the string , or perhaps some the string f(key,challenge). If the former is used, one must answer the question of whether or not a key can be recovered, given a known challenge and the output of the hash. I suspect that that's a difficult problem, but I'm by no means certain. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 14:34:44 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04744; Mon, 15 Jul 91 13:45:57 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from volitans.morningstar.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04577; Mon, 15 Jul 91 13:36:31 -0700 Received: by volitans.morningstar.com (5.65a/91071501) id AA16930; Mon, 15 Jul 91 16:35:45 -0400 Date: Mon, 15 Jul 91 16:35:45 -0400 From: Bob Sutterfield Message-Id: <9107152035.AA16930@volitans.morningstar.com> To: ietf-ppp@ucdavis.edu Subject: PPP terminal server? If you are (or know of) a vendor of a terminal server that talks PPP on its serial ports, please contact me. From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 15 15:21:43 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06307; Mon, 15 Jul 91 15:05:00 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from TIS.COM by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA06076; Mon, 15 Jul 91 14:51:53 -0700 Received: from TIS.COM by TIS.COM (4.1/SUN-5.64) id AA29648; Mon, 15 Jul 91 17:51:19 EDT Message-Id: <9107152151.AA29648@TIS.COM> To: balenson@TIS.COM Cc: brian@napa.telebit.com (Brian Lloyd), ietf-ppp@ucdavis.edu Subject: Re: CHAP and MD{4|5} In-Reply-To: balenson's message of Mon, 15 Jul 91 16:17:08 EDT. <9107152017.AA25715@TIS.COM> Date: Mon, 15 Jul 91 17:51:19 -0400 From: James M Galvin > I have been unable to find where MD4/5 allows the user to specify a > key for authentication. It doesn;t provide an explicit means for that. What we would do is prepend the key to the data (i.e., the random number) to be hashed, that is, the hash would be computed on the concatenation of the key and the random number. Note that this is exactly what the SNMP Security Protocols do. If the random number is a key, ie it is in fact secret between the peers, the hash does not need to be encrypted. Jim From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 16 16:00:36 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03403; Tue, 16 Jul 91 15:47:58 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA03328; Tue, 16 Jul 91 15:44:29 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA27132 to balenson@TIS.COM; Tue, 16 Jul 91 11:43:26 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA26352 to ietf-ppp@ucdavis.edu; Tue, 16 Jul 91 11:46:49 PDT Date: Tue, 16 Jul 91 11:46:49 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107161846.AA26352@napa.TELEBIT.COM> To: balenson@TIS.COM Cc: ietf-ppp@ucdavis.edu In-Reply-To: balenson@TIS.COM's message of Mon, 15 Jul 91 16:17:08 -0400 <9107152017.AA25715@TIS.COM> Subject: CHAP and MD{4|5} Reply-To: David M Balenson Date: Mon, 15 Jul 91 16:17:08 -0400 From: balenson@TIS.COM > I have been unable to find where MD4/5 allows the user to specify a > key for authentication. It looks like it would work for preventing a > packet modification attack but not for authentication. I need > enlightenment. It doesn;t provide an explicit means for that. What we would do is prepend the key to the data (i.e., the random number) to be hashed, that is, the hash would be computed on the concatenation of the key and the random number. -DB What you are saying is that, cryptographically speaking, concatenating the random challenge and the private key then running them through the algorithm used in MD4/5 is sufficiently secure that it is virtually impossible to invert the algorithm and deduce the private key. I need to have some assurance that it is virtually impossible to extract the key. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 22 12:19:14 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA21177; Mon, 22 Jul 91 12:01:19 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA20977; Mon, 22 Jul 91 11:50:28 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA02285 to ietf-ppp@ucdavis.edu; Mon, 22 Jul 91 11:45:50 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA19370 to ietf-ppp@ucdavis.edu; Mon, 22 Jul 91 11:45:47 PDT Date: Mon, 22 Jul 91 11:45:47 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107221845.AA19370@napa.TELEBIT.COM> To: ietf-ppp@ucdavis.edu Subject: moving IETF PPP WG Meeting to Mon Nite There are a number of conflicts with the PPP WG meeting. We have been asked to move the meeting to Monday nite at 7pm. I do not see a problem. Any comments? We have until tonight to change the printed schedule. Please reply NOW. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Mon Jul 22 17:33:31 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27413; Mon, 22 Jul 91 17:15:47 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27274; Mon, 22 Jul 91 17:08:17 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA04817 to ietf-ppp@ucdavis.edu; Mon, 22 Jul 91 17:03:42 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA23545 to ietf-ppp@ucdavis.edu; Mon, 22 Jul 91 17:03:41 PDT Date: Mon, 22 Jul 91 17:03:41 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107230003.AA23545@napa.TELEBIT.COM> To: galvin@tis.com Cc: ietf-ppp@ucdavis.edu Subject: PPP WG at IETF Changing the PPP WG meeting at this late hour is going to present a problem for a number of people who are not planning to get to the IETF meeting until Monday night (I fell into that catagory until this morning). As a result I recommend that we keep the formal meeting of the WG at its currently scheduled time on Tuesday but we have a PPP BOF at 7 pm on Monday eve. This will allow those people to are unable to attend the Tuesday meeting to come and discuss their issues on Monday night. We also need an agenda for the meeting so that we operate as efficiently as possible. Could we please address agenda items here in this group for the next couple of days. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 23 16:30:54 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24828; Tue, 23 Jul 91 16:01:44 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA24533; Tue, 23 Jul 91 15:46:34 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA02531; Tue, 23 Jul 91 18:46:12 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107232246.AA02531@vela.acs.oakland.edu> Subject: changes to authentication phase To: ietf-ppp@ucdavis.edu Date: Tue, 23 Jul 91 18:46:11 EDT X-Mailer: ELM [version 2.3 PL6] After discussion about the new CHAP authentication protocol, it has become apparent that the following paragraph must be deleted from the Authentication Phase section of the PPP-LCP draft: To prevent discovery of authentication passwords and algorithms, any authentication protocol packets received during any other phase MUST be silently discarded. The CHAP protocol assumes that a challenge may be issued at any time. Instead, language was added to the PAP protocol stating that once authentication has completed, when another packet is received the response will be the same as previous response. That kills two birds: 1) if the ACK/NAK was lost, another attempt will elicit the lost response; 2) if the peer keeps probing after it's already authenticated (in an attempt to discover other person's passwords), it will just get the same ACK response it did the first time; 3) if the peer keeps probing after failure (the line may still be up), it will just get the same NAK response it did the first time. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 23 16:46:41 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25408; Tue, 23 Jul 91 16:31:08 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25226; Tue, 23 Jul 91 16:22:44 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA03318; Tue, 23 Jul 91 19:22:20 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107232322.AA03318@vela.acs.oakland.edu> Subject: change to authentication configuration option To: ietf-ppp@ucdavis.edu Date: Tue, 23 Jul 91 19:22:19 EDT X-Mailer: ELM [version 2.3 PL6] A few elaborations added: 7.4. Authentication-Protocol Description On some links it may be desirable to require a peer to authenticate itself before allowing network-layer protocol packets to be exchanged. This Configuration Option provides a way to negotiate the use of a specific authentication protocol. By default, authentication is not necessary. An implementation may allow the peer to pick from more than one authentication protocol. To achieve this, it MAY include multiple Authentication-Protocol Configuration Options in its Configure- Request packets. ==>> An implementation receiving a Configure-Request ==>> specifying Authentication-Protocols MAY choose at most one of the proposed authentication protocols and MUST send a Configure-Reject specifying all of the other specified ==>> authentication protocols. The implementation MAY reject all of ==>> the proposed authentication protocols. It is recommended that each PPP implementation support configuration of authentication parameters at least on a per- interface basis, if not a per-peer-entity basis. The parameters should specify which authentication techniques are minimally required as a prerequisite to establishment of a PPP connection, either for the specified interface or for the specified peer entity. Such configuration facilities are necessary to prevent an attacker from negotiating a reduced security authentication protocol, or no authentication at all, in an attempt to circumvent this authentication facility. EDITOR'S NOTE: the preceeding paragraph causes confusion. We need a better guideline as to expected behaviour. I suggest that this paragraph be moved to a more extended discussion in the separate authentication protocol draft. If an implementation sends a Configure-Ack with this Configuration Option, then it is agreeing to authenticate with the specified protocol. An implementation receiving a Configure-Ack with this Configuration Option SHOULD expect the peer to authenticate with the acknowledged protocol. There is no requirement that authentication be full duplex or that the same authentication protocol be used in both directions. It is perfectly acceptable for different authentication protocols to be used in each direction. This will, of course, depend on the specific authentication protocols negotiated. Bill Simpson From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 24 10:05:24 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10910; Wed, 24 Jul 91 09:46:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA10800; Wed, 24 Jul 91 09:40:42 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA24920 to ietf-ppp@ucdavis.edu; Wed, 24 Jul 91 09:36:04 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA02607 to ietf-ppp@ucdavis.edu; Wed, 24 Jul 91 09:36:03 PDT Date: Wed, 24 Jul 91 09:36:03 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107241636.AA02607@napa.TELEBIT.COM> To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Tue, 23 Jul 91 19:22:19 EDT <9107232322.AA03318@vela.acs.oakland.edu> Subject: change to authentication configuration option In all areas of PPP the protocol should be simplified and made as stateless as possible. This greatly simplifies the creation of an interoperable PPP. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 24 15:47:01 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18264; Wed, 24 Jul 91 15:32:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17913; Wed, 24 Jul 91 15:17:15 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA20120; Wed, 24 Jul 91 18:16:43 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107242216.AA20120@vela.acs.oakland.edu> Subject: latest Authentication To: ietf-ppp@ucdavis.edu Date: Wed, 24 Jul 91 18:16:42 EDT Cc: internet-drafts@nri.reston.va.us X-Mailer: ELM [version 2.3 PL6] After much off-list discussion, here's the latest version of the Authentication Draft. I'm also sending it to internet-drafts so you should be able to pick it up at nnsc.nsf.net Would someone please make notes at the IETF meeting, and mail them to me? Sorry I can't be there (no funding). ----------------------------------------------------------------------- Network Working Group B. Lloyd Request for Comments: Draft Telebit W A Simpson CSCS July 1991 The PPP Authentication Protocols Status of this Memo This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Working Group at ietf- ppp@ucdavis.edu. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and provides for Authentication before allowing Network Layer protocols to transmit over the link. This document defines two protocols for Authentication: the simple Password Authentication Protocol, and the Cryptographic Handshake Authentication Protocol. Lloyd & Simpson [Page i] RFC DRAFT PPP Authentication July 1991 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. At this time, PPP specifies the use of asynchronous or synchronous duplex circuits, either dedicated or circuit switched. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network- layer protocols. In order to establish communications over a point-to-point link, the originating PPP would first send LCP packets to configure and test the data link. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network- Layer Protocol phase. If an implementation requires that the peer authenticate with some specific authentication protocol, then it must negotiate the use of that authentication protocol during Link Establishment phase. These authentication protocols are intended for use primarily by hosts and routers that connect via switched circuits or dial-up lines to a PPP network server. The server can then use the identification of the connecting host or router in the selection of options for network layer negotiations. When failing authentication, the server should terminate the connection. 1.1. Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition Lloyd & Simpson [Page 1] RFC DRAFT PPP Authentication July 1991 of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option must none-the-less be prepared to interoperate with another implementation which does include the option. 1.2. Terminology This document frequently uses the following terms: authenticator The end of the link requiring the authentication. peer The other end of the point-to-point link. silently discard This means the implementation MUST discard the packet without further processing. However, for diagnosis of problems, the implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. 2. Management of Keys Distribution and management of Passwords and other Key values .... EDITOR'S NOTE: We need some text for this section. Lloyd & Simpson [Page 2] RFC DRAFT PPP Authentication July 1991 3. Password Authentication Protocol The Password Authentication Protocol (PAP) may be used to verify the identity of the other end of the link. After the Link Establishment phase is complete, an Id/Password pair is repeatedly sent by the peer to the authenticator until authentication is acknowledged or the connection is terminated. Note that PAP is not a strong authentication method. Passwords are passed over the circuit in the clear and there is no protection from playback or repeated trial and error attacks. It is strongly recommended that any implementations which negotiate an Authentication-Protocol Configuration Option offer another authentication method prior to PAP. EDITOR'S NOTE: Some would change "strongly recommended" to REQUIRED. This authentication method is most likely used where the plaintext password must be available to simulate a login at a remote host. In such use, the method is no less secure than the normal user login at the remote host. Lloyd & Simpson [Page 3] RFC DRAFT PPP Authentication July 1991 3.1. Configuration Option Format A summary of the Authentication-Protocol Configuration Option format to negotiate the Password Authentication Protocol is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 4 Authentication-Protocol c023 (hex) for Password Authentication Protocol. Data There is no Data field. Lloyd & Simpson [Page 4] RFC DRAFT PPP Authentication July 1991 3.2. Packet Format Exactly one Password Authentication Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the protocol field indicates type hex c023 (Password Authentication Protocol). A summary of the PAP packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code The Code field is one octet and identifies the type of PAP packet. PAP Codes are assigned as follows: 1 Authenticate-Req 2 Authenticate-Ack 3 Authenticate-Nak Identifier The Identifier field is one octet and aids in matching requests and replies. Length The Length field is two octets and indicates the length of the PAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Data The Data field is zero or more octets. The format of the Data field is determined by the Code field. Lloyd & Simpson [Page 5] RFC DRAFT PPP Authentication July 1991 3.3. Authenticate-Req Description The Authenticate-Req packet is used to begin the Password Authentication Protocol. An implementation having sent a LCP Configure-Ack packet with an Authentication-Protocol Configuration Option specifying the Password Authentication Protocol must send an Authenticate-Req packet during the Authentication phase. The Authenticate-Req packet must be repeated until a valid reply packet is received. An implementation receiving a Configure-Ack with said Configuration Option should expect the peer to send an Authenticate-Req packet. Upon reception of an Authenticate-Req packet, some type of Authenticate reply (described below) MUST be returned. Note: Because the reply might be lost, the protocol MUST allow repeated Authenticate-Req packets after completing the Authentication phase. To prevent discovery of alternative Identities and Passwords, any Authenticate-Req packets received during the Network-Layer Protocol phase MUST return the same reply returned when the Authentication phase completed. Any Authenticate-Req packets received during any other phase MUST be silently discarded. A summary of the Authenticate-Req packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer-ID Length| Peer-Id ... +-+-+-+-+-+-+-+-+-+-+-+-+ | Passwd-Length | Password ... +-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Authenticate-Req. Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field SHOULD be changed each time an Lloyd & Simpson [Page 6] RFC DRAFT PPP Authentication July 1991 Authenticate-Req packet is transmitted. Peer-ID-Length The Peer-ID-Length field is one octet and indicates the length of the Peer-ID field Peer-ID The Peer-ID field is zero or more octets and indicates the name of the peer to be authenticated. Passwd-Length The Passwd-Length field is one octet and indicates the length of the Password field. Password The Password field is zero or more octets and indicates the password to be used for authentication. Lloyd & Simpson [Page 7] RFC DRAFT PPP Authentication July 1991 3.4. Authenticate-Ack and Authenticate-Nak Description If the Peer-ID/Password pair received in an Authenticate-Req is both recognizable and acceptable, then the authenticator MUST transmit a PAP packet with the Code field set to 2 (Authenticate- Ack), the Identifier field copied from the received Authenticate- Req packet, and the Message field optionally filled with an ASCII message. If the Peer-ID/Password pair received in a Authenticate-Req is not recognizable or acceptable, then the authenticator MUST transmit a PAP packet with the Code field set to 3 (Authenticate-Nak), the Identifier field copied from the received Authenticate-Req packet, and the Message field optionally filled with an ASCII message. A summary of the Authenticate-Ack and Authenticate-Nak packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg-Length | Message ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 2 for Authenticate-Ack; 3 for Authenticate-Nak. Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field MUST be copied from the Identifier field of the Authenticate-Req which caused this reply. Msg-Length The Msg-Length field is one octet and indicates the length of the Message field. Message The Message field is zero or more octets and indicates an ASCII Lloyd & Simpson [Page 8] RFC DRAFT PPP Authentication July 1991 message. Lloyd & Simpson [Page 9] RFC DRAFT PPP Authentication July 1991 4. Cryptographic Handshake Authentication Protocol The Cryptographic Handshake Authentication Protocol (CHAP) may be used to verify the identity of the other end of the link. After the Link Establishment phase is complete, an Id is sent by the peer to the authenticator, which returns a randomly generated "challenge" value. The peer responds with a cryptographic checksum of the challenge value paired with a local password-key. The authenticator then checks the "response" value against the checksum value of its challenge combined with its copy of the password-key. The CHAP authentication method provides protection against playback attack, and substitutions in circuit-switched connections after the initial link establishment. This authentication method is most likely used where the same password-key is easily maintained at both ends of the link. Lloyd & Simpson [Page 10] RFC DRAFT PPP Authentication July 1991 4.1. Configuration Option Format A summary of the Authentication-Protocol Configuration Option format to negotiate the Cryptographic Handshake Authentication Protocol is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authentication-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Digest | +-+-+-+-+-+-+-+-+ Type 3 Length 5 Authentication-Protocol c223 (hex) for Cryptographic Handshake Authentication Protocol. Digest The Digest field is one octet and indicates the cryptographic method to be used. The most up-to-date values of the CHAP Digest field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows: 1 unused 2 MD2 3 unused 4 MD4 5 MD5 Lloyd & Simpson [Page 11] RFC DRAFT PPP Authentication July 1991 4.2. Packet Format Exactly one Cryptographic Handshake Authentication Protocol packet is encapsulated in the Information field of PPP Data Link Layer frames where the protocol field indicates type hex c223 (Cryptographic Handshake Authentication Protocol). A summary of the CHAP packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code The Code field is one octet and identifies the type of CHAP packet. CHAP Codes are assigned as follows: 1 Identity 2 Challenge 3 Response 4 Success 5 Failure Identifier The Identifier field is one octet and aids in matching requests and replies. Length The Length field is two octets and indicates the length of the CHAP packet including the Code, Identifier, Length and Data fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception. Data The Data field is zero or more octets. The format of the Data field is determined by the Code field. Lloyd & Simpson [Page 12] RFC DRAFT PPP Authentication July 1991 4.3. Identity Description The Identity packet is used to begin the Cryptographic Handshake Authentication Protocol. An implementation having sent a LCP Configure-Ack packet with an Authentication-Protocol Configuration Option specifying the Cryptographic Handshake Authentication Protocol must send an Identity packet during the Authentication phase. The Identity packet must be repeated until a Challenge packet is received. An implementation receiving a Configure-Ack with said Configuration Option should expect the peer to send an Identity packet. Upon reception of an Identity packet, a Challenge packet MUST be transmitted, even when the Name is not recognized. Note: Any Identity packets received during any other phase MUST be silently discarded. A summary of the Identity packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name ... +-+-+-+-+-+-+-+-+-+-+-+-+ Code 1 for Identity. Identifier The Identifier field is one octet and must be set to zero. Name The Name field is zero or more octets and indicates the name of the peer to be authenticated. Lloyd & Simpson [Page 13] RFC DRAFT PPP Authentication July 1991 4.4. Challenge and Response Description Whenever an Identity packet is received, the implementation MUST transmit a CHAP packet with the Code field set to 2 (Challenge), the Identifier field set, and the Value field filled with a randomly generated value. This MUST occur even when the Name is not recognized. A Challenge packet MAY also be transmitted at any time during the Network-Layer Protocol phase to ensure that the connection has not been altered. The random value MUST be different each time a challenge is issued. Whenever a Challenge packet is received, the implementation MUST transmit a CHAP packet with the Code field set to 3 (Response), the Identifier field copied from the received Challenge packet, and the Value field filled with the cryptographic checksum of the Challenge Value followed by the local copy of the password-key which corresponds to the Name transmitted in the initial Identity packet. Whenever a Response packet is received, the implementation calculates the cryptographic checksum of its Challenge Value followed by its copy of the password-key which corresponds to the Name received in the initial Identity packet, and compares this checksum with the Response Value. Based on this comparison, the implementation sends a Success or Failure packet (described below). A summary of the Challenge and Response packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+ Code 2 for Challenge; 3 for Response. Lloyd & Simpson [Page 14] RFC DRAFT PPP Authentication July 1991 Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field MUST be copied from the Identifier field of the packet which caused this reply. Value The Value field is two or more octets, depending on the digest method negotiated. It contains the values used in the cryptographic handshake. The most significant octet is transmitted first. Lloyd & Simpson [Page 15] RFC DRAFT PPP Authentication July 1991 4.5. Success and Failure Description If the Value received in a Response is acceptable, then the implementation MUST transmit a CHAP packet with the Code field set to 4 (Success), the Identifier field copied from the received Response packet, and the Message field optionally filled with an ASCII message. If the Value received in a Response is not acceptable, then the implementation MAY transmit a CHAP packet with the Code field set to 5 (Failure), the Identifier field copied from the received Response packet, and the Message field optionally filled with an ASCII message. A summary of the Success and Failure packet format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ... +-+-+-+-+-+-+-+-+-+-+-+-+- Code 4 for Success; 5 for Failure. Identifier The Identifier field is one octet and aids in matching requests and replies. The Identifier field MUST be copied from the Identifier field of the Response which caused this reply. Message The Message field is zero or more octets and indicates an ASCII message. Lloyd & Simpson [Page 16] RFC DRAFT PPP Authentication July 1991 References [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC 1171, July, 1990. [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990. Security Considerations Security issues are the primary topic of this RFC. Acknowledgments Some of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF), formerly chaired by Drew Perkins of Carnegie Mellon University, by Russ Hobby of the University of California at Davis, and by Steve Knowles of FTP Software. Chair's Address The working group can be contacted via the current chair: Brian Lloyd Telebit Corporation 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 Phone: (408) 745-3103 EMail: brian@telebit.com Author's Address Questions about this memo can also be directed to: William Allen Simpson Computer Systems Consulting Services P O Box 6205 East Lansing, MI 48826-6025 Lloyd & Simpson [Page 17] RFC DRAFT PPP Authentication July 1991 EMail: Bill_Simpson@um.cc.umich.edu Lloyd & Simpson [Page 18] RFC DRAFT PPP Authentication July 1991 Table of Contents 1. Introduction .......................................... 1 1.1 Requirements .................................... 1 1.2 Terminology ..................................... 2 2. Management of Keys .................................... 2 3. Password Authentication Protocol ...................... 3 3.1 Configuration Option Format ..................... 4 3.2 Packet Format ................................... 5 3.3 Authenticate-Req ................................ 6 3.4 Authenticate-Ack and Authenticate-Nak ........... 8 4. Cryptographic Handshake Authentication Protocol ....... 10 4.1 Configuration Option Format ..................... 11 4.2 Packet Format ................................... 12 4.3 Identity ........................................ 13 4.4 Challenge and Response .......................... 14 4.5 Success and Failure ............................. 16 REFERENCES ................................................... 17 SECURITY CONSIDERATIONS ...................................... 17 ACKNOWLEDGEMENTS ............................................. 17 CHAIR'S ADDRESS .............................................. 17 AUTHOR'S ADDRESS ............................................. 17 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 24 16:01:13 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18335; Wed, 24 Jul 91 15:35:40 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA18066; Wed, 24 Jul 91 15:24:22 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA20379; Wed, 24 Jul 91 18:23:43 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107242223.AA20379@vela.acs.oakland.edu> Subject: Katz' OSI nroff'ed To: ietf-ppp@ucdavis.edu Date: Wed, 24 Jul 91 18:23:43 EDT Cc: internet-drafts@nri.reston.va.us X-Mailer: ELM [version 2.3 PL6] A long, long time ago, Dave Katz wrote a draft for OSI. For some reason, it was never posted in internet-drafts, and turned into an RFC. Here's the text, in the standard nroff format, with the current boilerplate. Please discuss this at IETF. ------------------------------------------------------------------- Network Working Group D. Katz Request for Comments: Draft Merit/NSFnet July 1991 The PPP OSI Network Layer Control Protocol (OSINLCP) Status of this Memo This proposal is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the IETF Working Group at ietf- ppp@ucdavis.edu. Distribution of this memo is unlimited. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the NCP for establishing and configuring OSI Network Layer Protocols. Katz [Page i] RFC DRAFT PPP OSINLCP July 1991 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. PPP uses HDLC as a basis for encapsulating datagrams over point- to-point links. At this time, PPP specifies the use of asynchronous or synchronous duplex circuits, either dedicated or circuit switched. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. PPP is designed to allow the simultaneous use of multiple network- layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention). 1.1. OSI Network Layer Protocols A number of protocols have been defined for the Network Layer of OSI, including the Connectionless Network Layer Protocol (CLNP, ISO 8473) [3], the End System to Intermediate System routing protocol (ES-IS, ISO 9542) [4], the Intermediate System to Intermediate System routing protocol (IS-IS, DP 10589) [5], and the Connection- Oriented Network Protocol (X.25 packet level protocol, ISO 8208) [6]. OSI Network Layer protocols can be discriminated according to the first octet in each PDU, known as the Network Layer Protocol Identifier (NLPID), defined in ISO/TR 9577 [7]. This allows the various protocols to be run over a common data link without any discriminator below the network layer. Katz [Page 1] RFC DRAFT PPP OSINLCP July 1991 2. A PPP Network Control Protocol (NCP) for OSI The OSI Network Layer Control Protocol (OSINLCP) is responsible for configuring, enabling, and disabling the OSI protocol modules on both ends of the point-to-point link. OSINLCP uses the same packet exchange machanism as the Link Control Protocol (LCP). OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. OSINLCP packets received before this phase is reached should be silently discarded. Likewise, OSI NPDUs may not be exchanged until OSINLCP has finished opening the connection (reached the Opened state). The OSI Network Layer Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one IPCP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8023 (OSI Network Layer Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Timeouts OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types Currently, OSINLCP has no Configuration Options defined. 2.1. Sending OSI NPDUs Before any NPDUs may be communicated, PPP must reach the Network- Layer Protocol phase, and the OSI Network Layer Control Protocol must reach the Opened state. Exactly one OSI NPDU is encapsulated in the Information field of PPP Katz [Page 2] RFC DRAFT PPP OSINLCP July 1991 Data Link Layer frames where the Protocol field indicates type hex 0023 (OSI Network Layer). The maximum length of an OSI NPDU transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. Larger NPDUs must be segmented as necessary. If a system wishes to avoid segmentation and reassembly, it should use transport layer mechanisms to discourage others from sending large PDUs. 2.2. Exchanging Network Layer Addressing Information OSINLCP does not define a separate configuration option for the exchange of OSI Network Layer address information. Instead, the ES- IS protocol, ISO 9542, should be used. This protocol provides a mechanism for determining the Network Layer address(es) of the neighbor on the link, as well as determining if the neighbor is an End System or an Intermediate System. The ES-IS protocol does not currently support Network Layer address assignment. If address assignment is viewed as being desirable, it would be preferable to add this capability to ISO 9542, rather than creating a mechanism within PPP. This matter is for further study. Katz [Page 3] RFC DRAFT PPP OSINLCP July 1991 References [1] Perkins, D., "The Point-to-Point Protocol for the Transmission of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC 1171, July 1990. [3] ISO, "Information processing systems--Data communications-- Protocol for providing the connectionless-mode network service", ISO 8473, 1988. [4] ISO, "Information processing systems--Telecommunications and information exchange between systems--End system to Intermediate system Routeing exchange protocol for use in conjunction with the protocol for providing the connectionless- mode network service (ISO 8473)", ISO 9542, 1988. [5] ISO, "Information processing systems--Telecommunications and information exchange between systems--Intermediate system to Intermediate system Intra-Domain routeing exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", DP 10589, 1990. [6] ISO, "Information processing systems--Data communications--X.25 packet level protocol for Data terminal equipment", ISO 8208, 1984. [7] ISO, "Information technology--Telecommunications and information exchange between systems--Protocol identification in the Network layer", ISO/TR 9577, to be published. Security Considerations Security issues are not discussed in this memo. Acknowledgments Some of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF), formerly chaired by Drew Perkins of Carnegie Mellon University, by Russ Hobby of the University of California at Davis, and by Steve Knowles of FTP Software. Editted and formatted by Bill Simpson. Katz [Page 4] RFC DRAFT PPP OSINLCP July 1991 Chair's Address The working group can be contacted via the current chair: Brian Lloyd Telebit Corporation 1315 Chesapeake Terrace Sunnyvale, CA 94089-1100 Phone: (408) 745-3103 EMail: brian@telebit.com Author's Address Questions about this memo can also be directed to: Dave Katz Merit/NSFNET 1075 Beal Ave. Ann Arbor, MI 48109 Phone: (313) 763-4898 EMail: dkatz@merit.edu Katz [Page 5] RFC DRAFT PPP OSINLCP July 1991 Table of Contents 1. Introduction .......................................... 1 1.1 OSI Network Layer Protocols ..................... 1 2. A PPP Network Control Protocol (NCP) for OSI .......... 2 2.1 Sending OSI NPDUs ............................... 2 2.2 Exchanging Network Layer Addressing Information ....................................................... 3 REFERENCES ................................................... 4 SECURITY CONSIDERATIONS ...................................... 4 ACKNOWLEDGEMENTS ............................................. 4 CHAIR'S ADDRESS .............................................. 5 AUTHOR'S ADDRESS ............................................. 5 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 24 16:34:48 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19212; Wed, 24 Jul 91 16:18:30 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA19064; Wed, 24 Jul 91 16:11:32 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA21842; Wed, 24 Jul 91 19:10:48 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107242310.AA21842@vela.acs.oakland.edu> Subject: Re: change to authentication configuration option To: brian@napa.telebit.com (Brian Lloyd) Date: Wed, 24 Jul 91 19:10:47 EDT Cc: ietf-ppp@ucdavis.edu In-Reply-To: <9107241636.AA02607@napa.TELEBIT.COM>; from "Brian Lloyd" at Jul 24, 91 9:36 am X-Mailer: ELM [version 2.3 PL6] > > > In all areas of PPP the protocol should be simplified and made as > stateless as possible. This greatly simplifies the creation of an > interoperable PPP. > > Brian Lloyd, WB6RQN Telebit Corporation > Network Systems Architect 1315 Chesapeake Terrace > brian@telebit.com Sunnyvale, CA 94089-1100 > voice (408) 745-3103 FAX (408) 734-3333 > Sure Brian, but we've knocked it down to as few as there are ever going to be. +--------------------------+ | v Dead -> Establishment -> Authentication -> Network -> Termination -+ ^ | +----------------------------------------------------------------+ Even if additional authemtication is allowed during the Network Phase, there still has to be a make/break test *before* you let them on the net. We need some sort of termination notice before going down, particularly in 3 or 4 wire environments. Good time to update routing tables, too. All in all, I think that the spec is getting pretty solid. We've had a lot of comments, and the process has taken rather a long time. In fact, that is probably the major source of non-interoperability -- earlier implementations that resolved ambiguities differently than the final spec. Bill PS: Hey, I should put that picture in the RFC, it might be more understandable. From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 24 20:15:28 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22848; Wed, 24 Jul 91 20:00:29 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from vela.acs.oakland.edu by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22707; Wed, 24 Jul 91 19:49:47 -0700 Received: by vela.acs.oakland.edu (5.57/Ultrix3.0-C) id AA02243; Wed, 24 Jul 91 22:49:20 -0400 From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Message-Id: <9107250249.AA02243@vela.acs.oakland.edu> Subject: PPP/Ultrix (fwd) To: ietf-ppp@ucdavis.edu Date: Wed, 24 Jul 91 22:49:19 EDT X-Mailer: ELM [version 2.3 PL6] One of the things that needs to be done at IETF this week is list all of the PPP implementations available. Any volunteers to post it? Forwarded message: > From jeff Wed Jul 24 22:28:41 1991 > Subject: PPP/Ultrix > To: bsimpson (Bill Simpson) > Date: Wed, 24 Jul 91 22:28:28 EDT > Organization: Oakland University, Rochester, MI U.S.A. > X-Mailer: ELM [version 2.3 PL6] > > Bill, > > Do you know of any PPP implementations that would run under DEC > Ultrix? (Forgive my ignorance, I've just discovered the joy of PPP > through KA9Q ) > > I'm aware of a somewhat flawed SunOS implementation. Unfortunately, > our BSD systems are going the way of the dinosaur for a while, so > SunOS and Ultrix are the only options. > > Thanks for your help! > > Jeff > > -- > Jeff Marraccini jeff@vela.acs.oakland.edu <- Work > Computing Resource Administrator jeff@nucleus.mi.org <- Home > Oakland University +1 313 370-4542 > Rochester, MI USA 48309-4401 "The Computer is your Friend." -- Paranoia > From ietf-ppp-request@ucdavis.ucdavis.edu Thu Jul 25 08:17:03 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04914; Thu, 25 Jul 91 08:00:49 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from crane.aa.ox.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA04699; Thu, 25 Jul 91 07:54:32 -0700 Received: by crane.aa.ox.com (/\=-/\ Smail3.1.18.1 #18.26) id ; Thu, 25 Jul 91 10:54 EDT Message-Id: To: bsimpson@vela.acs.oakland.edu (Bill Simpson) Cc: ietf-ppp@ucdavis.edu Subject: Re: PPP/Ultrix (fwd) In-Reply-To: Your message of Wed, 24 Jul 91 22:49:19 -0400. <9107250249.AA02243@vela.acs.oakland.edu> Date: Thu, 25 Jul 91 10:54:16 EDT From: Edward Vielmetti > One of the things that needs to be done at IETF this week is list > all of the PPP implementations available. Any volunteers to post it? It's a little late for the IETF, but the comp.protocols.ppp newsgroup looks like it'll be created first week of August (unless I get a hundred or so no votes all at once). Compiling such a list and posting it regularly is part of the charter of that group. --Ed From ietf-ppp-request@ucdavis.ucdavis.edu Sun Jul 28 10:30:08 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08824; Sun, 28 Jul 91 10:15:04 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from GAAK.LCS.MIT.EDU by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA08732; Sun, 28 Jul 91 10:05:32 -0700 Received: by gaak.LCS.MIT.EDU id AA21201; Sun, 28 Jul 91 13:05:05 EDT Date: Sun, 28 Jul 91 13:05:05 EDT Message-Id: <9107281705.AA21201@gaak.LCS.MIT.EDU> To: bsimpson@vela.acs.oakland.edu Cc: ghm@merit.edu, ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Sat, 27 Jul 91 13:00:28 EDT <9107271700.AA26832@vela.acs.oakland.edu> Subject: Idea to discuss at IETF From: Michael A. Patton From: bsimpson@vela.acs.oakland.edu (Bill Simpson) Date: Sat, 27 Jul 91 13:00:28 EDT > I would like it to only apply to LCP packets sent in the LCP phase. > This would allow echo request, echo reply and link quality monitoring > packets to be sent on async lines without unneccessary overhead after > the link is negotiated up. > > Glenn McGregor > Merit Network, Inc. > ghm@merit.edu I don't see any good reason why echo, discard, and LQR packets need the full overhead. If they aren't recognized, it's because there is a configuration problem anyway.... Finally, I don't see how the current restriction could be enforced. In my case, the decoding routine doesn't look at the uncompressed protocol, and the protocol switch has no way of knowing how the packet looked as it came over the link. Let's not start tossing otherwise good packets. Right, time for some "argument from authority" :-). Since I was one of the people who argued for this in the original design, let me try and explain a bit why it is this way. What you say, not to discard them whichever way they come in, is the first part of "Be generous in what you accept and conservative in what you send", but the reason for requiring them to always be sent uncompressed is the second half. There are many reasons why this applies here, let me describe one that I personally felt reasonably compelling in itself. You always send LCP packets as if no options have been negotiated because, that way, even if someone has changed cables on you, at least those get through. This is very useful, because the appearance of inappropriate LCP messages can be a trigger for the systems to detect that the carefully negotiated configuration is now completely useless and go back to trying to establish the link and link parameters. The total amount of traffic on a link that's due to LCP packets had better be trivial compared to other traffic, so the extra overhead didn't seem to be called for. And since one of the cases to handle is that of getting a different system on the other end of the link, it may well be that this system cannot recognize compressed packets. In summary, there seemed to be some reasons (fairly compelling ones to many on the committee) for sending LCP packets in full, and there didn't seem to be any compelling arguments against it. There were a couple of minor reasons that it would be nice, but we felt these were overpowered by the reasons for doing it the way we chose. We felt that if we allowed LCP packets to be sent compressed, then we had to put in a requirement for all implementations to try and recognize these, even ones that would refuse this negotiation. This seems clearly unreasonable. Of course, the IP standards process is a lot more fluid than other standards, this could always be revisited, but I still haven't seen any arguement to allow these that I feel is any where near as compelling as the conservative philosophy argument. __ /| /| /| \ Michael A. Patton, Network Manager / | / | /_|__/ MIT Laboratory for Computer Science / |/ |/ |atton (IETF PPP "committee" since 1987) Disclaimer: The opinions expressed above are a figment of the phosphor on your screen and do not represent the views of MIT, LCS, or MAP. :-) P.S. That's about all I have time for right now. I have to go catch a plane to Atlanta :-). See you there... From ietf-ppp-request@ucdavis.ucdavis.edu Tue Jul 30 13:17:46 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25737; Tue, 30 Jul 91 13:01:59 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA25655; Tue, 30 Jul 91 12:57:32 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA03540 to ietf-ppp@ucdavis.edu; Tue, 30 Jul 91 12:52:48 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA02696 to ietf-ppp@ucdavis.edu; Tue, 30 Jul 91 12:52:46 PDT Date: Tue, 30 Jul 91 12:52:46 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107301952.AA02696@napa.TELEBIT.COM> To: bsimpson@vela.acs.oakland.edu Cc: ietf-ppp@ucdavis.edu In-Reply-To: Bill Simpson's message of Wed, 24 Jul 91 19:10:47 EDT <9107242310.AA21842@vela.acs.oakland.edu> Subject: change to authentication configuration option Well it seems that things are pretty tied up at this point. The PPP WG meeting was this morning and there was a pretty good consensus. I will report more later. Glenn McGregor took good notes and we will whip thme into minutes. A number of them pertain to slight clarifications. The digestification algorithm to be used with CHAP will be MD5 with no support for MD2 or MD4 (they will be dropped from the references but the digest field will be kept around for future purposes). More later. BTW, I am now the WG chaircritter. Brian From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 31 11:36:10 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA17195; Wed, 31 Jul 91 11:15:51 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA16984; Wed, 31 Jul 91 11:04:27 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA14381 to ietf-ppp@ucdavis.edu; Wed, 31 Jul 91 11:02:02 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA18286 to bsimpson@vela.acs.oakland.edu; Wed, 31 Jul 91 11:02:01 PDT Date: Wed, 31 Jul 91 11:02:01 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9107311802.AA18286@napa.TELEBIT.COM> To: emv@ox.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu In-Reply-To: Edward Vielmetti's message of Thu, 25 Jul 91 10:54:16 EDT Subject: PPP/Ultrix (fwd) FYI, I am now the chaircritter for the IETF PPP working group. I am glad to hear that comp.protocols.ppp will be happening soon. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333 From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 31 15:22:24 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22230; Wed, 31 Jul 91 15:02:33 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from poe.aa.ox.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA22065; Wed, 31 Jul 91 14:54:06 -0700 Received: by poe.aa.ox.com (/\=-/\ Smail3.1.18.1 #18.34) id ; Wed, 31 Jul 91 17:52 EDT Message-Id: To: brian@napa.Telebit.COM (Brian Lloyd) Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu, emv@msen.com Subject: Re: PPP/Ultrix (fwd) In-Reply-To: Your message of Wed, 31 Jul 91 11:02:01 -0700. <9107311802.AA18286@napa.TELEBIT.COM> Date: Wed, 31 Jul 91 17:52:44 EDT From: Edward Vielmetti I'm going to be counting the ppp votes tonight, and sending a message to news.announce.newgroups saying that the vote passed. Per protocol it should be created in about 5 days, which would put it at next Monday for the first newgroup messages. Think now about things you'd like to post, esp. an "introduction to ppp", a "summary of commercial and free implementations", and a "where to get protocol information". I do not currently have write access to an internet anonymous FTP site, so I won't be keeping an archive myself. The mailing list to newsgroup gateway probably won't happen right away; if you're prepared to volunteer to run one let me know ASAP. -- Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com MSEN, Inc. 628 Brooks Ann Arbor MI 48103 +1 313 741 1120 for information on MSEN products and services contact info@msen.com From ietf-ppp-request@ucdavis.ucdavis.edu Wed Jul 31 21:00:49 1991 Received: by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA28006; Wed, 31 Jul 91 20:45:24 -0700 Sender: ietf-ppp-request@ucdavis.ucdavis.edu Received: from apache.telebit.com by ucdavis.ucdavis.edu (5.61/UCD2.03) id AA27921; Wed, 31 Jul 91 20:36:21 -0700 Received: from napa.TELEBIT.COM by apache.telebit.com (4.1/SMI-4.1/Telebit-Apache-DBC-910705) id AA18953 to ietf-ppp@ucdavis.edu; Wed, 31 Jul 91 20:35:49 PDT Received: by napa.TELEBIT.COM (4.1/napa.telebit.com-DBC-910507) id AA28122 to bsimpson@vela.acs.oakland.edu; Wed, 31 Jul 91 20:35:48 PDT Date: Wed, 31 Jul 91 20:35:48 PDT From: brian@napa.Telebit.COM (Brian Lloyd) Message-Id: <9108010335.AA28122@napa.TELEBIT.COM> To: emv@ox.com Cc: bsimpson@vela.acs.oakland.edu, ietf-ppp@ucdavis.edu, brent@napa.Telebit.COM In-Reply-To: Edward Vielmetti's message of Wed, 31 Jul 91 17:52:44 EDT Subject: PPP/Ultrix (fwd) We can keep the archive for the newsgroup comp.protocols.ppp on apache.telebit.com (ftp.telebit.com). The charter for that machine is to function as a repository for dial-up IP software and information. I am also looking for pointers to public domain SLIP and PPP implementations to keep on that machine as well. If you are aware of any good, working implementations, please let me know so we can pick them up and make them available for anonymous FTP. We will also try to ensure that there is sufficient information about software kept there so that others will be able to make use of what they find there. Brian Lloyd, WB6RQN Telebit Corporation Network Systems Architect 1315 Chesapeake Terrace brian@telebit.com Sunnyvale, CA 94089-1100 voice (408) 745-3103 FAX (408) 734-3333