CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT) Invitational Lunch Meeting and Discussion Session A group of people met for lunch on Wednesday, 30 March to discuss PPP authentication. This effort is in part an outgrowth of the NASREQ Working Group. The people who met were: Andy Nicholson, Bill Simpson, Brad Parker, David Carrel, Fred Baker, John Vollbrecht, Larry Blunk, Mike O'Dell, Shirley Sun, Ted Ts'o, Tim Kolar and Clifford Neuman. Three proposals have been posted as Internet-Drafts within the last few days for providing enhanced authentication procedures for PPP. These drafts are: o ``The Arbitrary Handshake Authentication (AHA) protocol'' (draft-ietf-pppext-aha-auth-00.txt) o ``The Generic Athentication Protocol (GAP)'' (draft-ietf-pppext-gap-auth-00.txt) o ``PPP Kerberos Authentication Protocol (KAP)'' (draft-ietf-pppext-kap-auth-00.txt) We agreed on certain organizational details and timelines, to wit: o Larry Blunk will create a mailing list ppp-auth@merit.edu for preliminary discussion of this topic by the interested parties. o David Carrel will edit a ``PPP Authentication Requirements'' draft to guide the discussion. This should be stable by 1 June, preferably earlier. The objective of this document is to provide a problem statement and a set of guidelines that will govern the solution. This will be posted as an Internet-Draft. o An editor (to be named) will merge the above proposals in accordance with the agreed requirements and post it as an Internet-Draft by the July IETF meeting. This editor will present a solution to the problem to the PPPEXT Working Group at that meeting. o After that, discussion of PPP authentication will proceed on the ietf-ppp@merit.edu mailing list and will be an open discussion. o Ideally, we should be prepared to advance the current Internet-Draft to Proposed Standard status by the winter IETF meeting. o We expect that the documents published as RFCs will include: - The requirements document, - One or more ``framework'' documents, and - Several documents describing individual authentication procedures. The model here is PPP compression, which has a number of procedures, mostly covered by patent claims, and mostly proprietary. We wrote one standards track document which indicates how these procedures can be accommodated (PPP CCP), and the various vendors provided FYI description RFCs for their procedures. Here, the supporting RFCs may be FYI or standards track, and may or may not be supplied by vendors. However, the framework is standards track. We also discussed the requirements that we felt needed to be addressed. Points mentioned included: o ARA-like procedures need in-band authentication. The solution must enable various procedures to be usable, including but not limited to: - Password authentication (PAP) - Challenge authentication (CHAP) - Token card authentication (SecureID and similar systems) - Kerberos 4 and 5 - X.509/PEM o We want to specify the behavior on the line, but not the user interface that will supply the tokens used on it. There may, however, be unavoidable user interface implications. o Must determine the authentication procedure and database based on an identity presented by the system being authenticated; providers often have different authentication databases by peer that need to be inspected. o The actual authentication procedure used must not be negotiated or announced. o The scheme MUST work for error-prone end users and for automated peers such as dial on demand routers. o Whatever solution we come up with MUST cooperate with the larger security and service framework being discussed in other areas. A solution to a small piece of the total problem may be worse than no solution at all. o Should perhaps provide, through some mechanism, features like: - authentication retry - password modification - various encryption/privacy procedures - call-back General Meeting Thursday 31 March o ``The Point-to-Point Protocol (PPP)'' (draft-ietf-pppext-lcp-fs-00.txt) o ``PPP in HDLC-like Framing'' (draft-ietf-pppext-hdlc-fs-00.txt) Take the LCP and normal HDLC operation to Standard. Bill will add a sentence to the Authentication section of LCP explaining that the Authentication Option states ``you must authenticate with me,'' and how the authentication phase is intended to proceed and terminate. We will ship this up. Bill will write an Informational RFC for all of PPP, as some have found a need for an overview. There is a need, in order to go to Standard, for one implementation to have implemented the entire standard. Fred Baker will poll the list regarding LCP options and correlate the responses, seeking to find, preferably, one implementation that has implemented all or, second best, that all options have in fact been implemented. HDLC has a problem in that the same implementation is most unlikely to have implemented async, bit-sync, and octet sync. The area director advises that two interoperable implementations of each are adequate. Fred Baker will poll the list seeking two octet synchronous implementations. o ``PPP LCP Option for Data Encapsulation Selection'' (draft-ietf-pppext-dataencap-02.txt) o ``PPP in Frame Relay'' (draft-ietf-pppext-frame-relay-02.txt) Joel and Bill will finalize some language in each of these documents and post drafts. We will then start the Last Call process to go to Proposed Standard on each. o ``The PPP NetBIOS Frames Control Protocol (NBFCP)'' (draft-ietf-pppext-netbios-fcp-04.txt) Thomas will add a sentence defining canonical format and specifying that it should be used, and making a few other editorial changes. NetBIOS name defense will also be beefed up---there is a fair amount of state in name defense, and this needs to be clarified. There needs to be some implementation notes regarding timing in name defense, as the peer needs to be considerate of flooded implementations in generating its multicasts. Specific changes required: o Define and require canonical MAC address format o MAC address becomes a boolean option o Clarify name defense o Applicability Statement (dial-in end systems) We will take the updated draft to Proposed Standard. o ``The Arbitrary Handshake Authentication (AHA) protocol'' (draft-ietf-pppext-aha-auth-00.txt) o ``The Generic Athentication Protocol (GAP)'' (draft-ietf-pppext-gap-auth-00.txt) o ``PPP Kerberos Authentication Protocol (KAP)'' (draft-ietf-pppext-kap-auth-00.txt) This is work spun off by NASREQ; Brad reported on the meetings earlier in the week. Narren will write an update to call-back; it doesn't quite do the authentication job now, and there is another possible use in dial-up in the face of congestion. This will be discussed on the ppp-auth@merit.edu list and then taken to the main list for wider discussion. o ``The PPP Multilink Protocol (MP)'' (draft-ietf-pppext-multilink-07.txt) Compression may be done above or below the link; two protocol identifiers have been assigned. Although this is described in the compression document, there is text left here as this is the one thing that can be in either place. Number space size will have the following sequence space, with no negotiation: 0 1 2 3 4 5 6 7 8 31 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |B|E| reserved | 24 bit sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This preserves memory boundary alignment (needed by many 16-bit controllers) and satisfies the need for a large sequence space in long delay high bandwidth (satellite T3) The two packet loss detection methods (timer based reassembly and increasing sequence number per link) will be re-organized somewhat reflecting this. Define the concept of ``packet migration'' and a negotiation that says ``I am willing to receive messages out of sequence.'' Keith will define an option to this effect, and we will get Dave Carr to spell out the algorithms and motivations. Endpoint Identification (what system I am): We agreed to define an LCP option that identifies the endpoint system. It is not authenticated, it is advisory, to help distinguish instances of an entity. Tom Coradetti to provide text. Bundle Identification Option (whom you wish to become part of): Tom Coradetti agrees that authentication should be used to identify the bundle. Tom Coradetti to provide text. Make it clear that padding is a feature specific to the link within the bundle, and that it is required to be done the same way (no pad, self identifying pad, or message with length field) for all messages of a given protocol type on a link. Make it clear in the text that the multi-link specification defines what is happening within a bundle, and that ``bundle'' is defined by the combination of ``authenticated name''-using-``endpoint'' pairs. Need to clarify protocol reject: messages received on the bundle should, if rejected, be rejected on the bundle. Keith will outlaw asymmetric configurations, where fragmentation and other procedures are only legal in one direction. MLCP may not have LCP Configuration request, ack, or reject, but other messages may run on it. IESG Review of Compression Draft (John Klensin) John Klensin presented the results of the IESG review. There is a view that the CCP cannot be standardized because there exist separate compression options. The IESG would like for the working group to select one and make it a requirement of the standard. This is not an IESG ``position'' at this point, but a major concern. Dave Rand is to clarify the language about exactly what is being standardized. The IESG wants to be able to know what must be interoperable for the draft to be considered a Standard. Symplex Communications may make its standard licensed for the price of the documentation, and will post a draft indicating that. For the information of the working group, Motorola claims to have a patent on CCP's dictionary reset mechanism. ISDN MIB Fred Baker to talk to Marshall and Stev about a MIB development. Attendees Ron Aley aley@cac.washington.edu Edward Allen eallen@wellfleet.com Cyrus Azar cyrus@netcom.com Fred Baker fbaker@acc.com Dana Blair dblair@vnet.ibm.com Larry Blunk ljb@merit.edu Carsten Bormann cabo@informatik.uni-bremen.de Rich Bowen rkb@ralvm11.vnet.ibm.com Caralyn Brown cbrown@wellfleet.com Frank Cannata cannata@cabletron.com David Carrel carrel@cisco.com Thomas Coradetti tomc@digibd.com Marty Del Vecchio marty@shiva.com Thomas Dimitri tommyd@microsoft.com Bob Downs bdowns@combinet.com Shoji Fukutomi fuku@furukawa.co.jp Chris Gunner gunner@dsmail.lkg.dec.com Joel Halpern jhalpern@newbridge.com Marco Hernandez marco@cren.net Jan-Olof Jemnemo Jan-Olof.Jemnemo@intg.telia.se Bent Jensen bent@cisco.com David Kaufman dek@magna.telco.com Tim Kolar tkolar@cisco.com Mark Lewis Mark.S.Lewis@telebit.com Joshua Littlefield josh@cayman.com Andrew Malis malis@maelstrom.timeplex.com Glenn McGregor glenn@lloyd.com Gerry Meyer gerry@spider.co.uk William Miskovetz misko@cisco.com Robert Moose rmoose@gateway.mitre.org Kenneth Mueller ken@cmc.com Clifford Neuman bcn@isi.edu Andy Nicholson andyni@microsoft.com Michael O'Dell mo@uunet.uu.net Todd Palgut todd@nei.com Brad Parker brad@fcr.com James Philippou japhilippou@eng.xyplex.com Venkat Prasad vsp@3com.com Rex Pugh pugh@hprnd.rose.hp.com Shahbaz Rahmanian shahbaz@ameris.ameritech.com Kenneth Rehbehn kjr@netrix.com Allen Rochkind Allen_Rochkind@3com.com Benny Rodrig brodrig@rnd-gate.rad.co.il Guenter Roeck roeck@conware.de Doug Schremp dhs@magna.telco.com Paul Serice serice@cos.com William Simpson bsimpson@morningstar.com Keith Sklower sklower@cs.berkeley.edu Walter Sotelo shin@hodaka.mtd.cs.fujitsu.co.jp Shirley Sun suns@centrum.com Claudio Topolcic topolcic@bbn.com Theodore Ts'o tytso@mit.edu John Vollbrecht jrv@merit.edu Glen Zorn glenz@ocsg.com