CURRENT_MEETING_REPORT_ Reported by Raj Srinivasan/SunSoft Minutes of the ONC Remote Procedure Call Working Group (ONCRPC) The ONCRPC Working Group met on 28 March at the Seattle IETF. There were thirty-three attendees. Afternoon Session After introductions, Dave Crocker talked about IETF practices regarding standardization. The IETF is not standardizing ``The RPC Everyone Should Use.'' Steve Nahm gave a presentation on the history and architecture of ONC RPC and XDR. Following Steve's presentation, the group reviewed the charter. There was acceptance of the charter wording and delivery timetable. The initial standard will have no changes from the current practice of ONC RPC and XDR. The follow-on working group will work on issues raised by this working group. Delivery of documents describing the standard is currently scheduled to be in May (before the next IETF). The group then reviewed XDR. Only the main changes from RFC 1014 were reviewed. This was the section on the quadruple-precision floating point data type, and the wording about NaNs. It was suggested that at least the IEEE specification for NaNs should be listed in an appendix (all NaNs and their meanings are not required). Evening Session The changes from RFC 1057 were reviewed. Suggestions were: o Remove ``Sun''---call it ``ONC RPC'' rather than ``Sun RPC.'' wherever appropriate in the document. o In a discussion of the authentication flavors that are currently deployed, it was suggested that some be required (mandatory) and others be optional in implementations; AUTH_NONE is required; AUTH_SYS should be moved to an appendix and it should be strongly recommended that it be included in any implementation (note that NFS uses AUTH_SYS); Diffie-Hellman and Kerberos-based authentication mechanisms should be moved to separate drafts, not part of the main standard, which will become Informational RFCs that document existing practice. Also, the Diffie-Hellman document should give a reference to the paper that points out the weaknesses of this mechanism, and deprecate this mechanism because of its weaknesses. A caveat that AUTH_SYS provides legitimate authentication only when all RPC-related applications on all platforms on the network are under control, is required. An explanation of the ``privileged ports'' mechanism as it used in conjunction with AUTH_SYS for certifying the sender/receiver should be added. The main reason for taking this tack is due to the known weakness of the Diffie-Hellman mechanism, and the relatively low deployment of the Kerberos-based mechanism. o Change AUTH_KERB to AUTH_KERB4. o Change AUTH_DES to AUTH_DH. Wherever ``DES Authentication'' is mentioned, change it to ``Diffie-Hellman Authentication.'' o Change ``window'' to ``lifetime,'' for describing the lifetime of a credential. o Section on Kerberos-based authentication mentions ``window'' without defining it. o Note in the document that the credential and verifier are historically separate items, but always used together. o A short section on Kerberos naming should be added. Some guidance as to how a client could determine a server's name is needed. o In the authkerb_fullname structure, ``ticket<>'' should be changed to have a maximum length of 392. o Mention that the Diffie-Hellman modulus is in hexadecimal notation. o The RPCBIND protocols (including the portmapper version 2 protocol) should be moved to a separate Internet-Draft. This will be standardized along with RPC and XDR, and be the recommended binding method. o The RPCBIND document must note the properties of ``netid.'' Perhaps netid's for common transports should be defined. o Multicast should be mentioned in addition to broadcast---there is at least one implementation that has used multicasting successfully. The two mechanisms are very similar in RPC. o Need references to Kerberos V4. o Section 4 (``Transports and Semantics'') the RPC document should point to the ``Record Marking Standard'' section (section 10). Evening Session - Follow-on Working Group Discussion The following suggestions were made for consideration by the follow-on working group. o A GSS API based mechanism for security could be incorporated into ONC RPC. Underlying this could be other mechanisms such as Kerberos V5, RSA, etc. At least one company has done this - details need to be investigated. o Features to support DCE/ONC gateways. o Formalize multicast support. One proposal was to have multicast requests followed by multiple responses from multiple nodes; another mentioned using name services to create multicast groups, etc. Neither affects packet formats. o XDR should support wide characters. It was suggested that array encodings be used for wide characters. Other encodings need to be investigated. o Support the ``at most once'' semantic over all transports. o Need more error information in the ``rejected_reply'' union, following the ``auth_stat'' field in the ``AUTH_ERROR'' arm. o How about alternative XDR encodings? Attendees Steve Alexander stevea@lachman.com Mark Allyn allyn@netcom.com Susie Armstrong susie@mentat.com Karl Auerbach auerbach@ssds.com Brad Burdick bburdick@radio.com Brett Chappell bchappe@relay.nswc.navy.mil David Crocker dcrocker@mordor.stanford.edu Dante Delucia dante@usc.edu Robert Gilligan Bob.Gilligan@Eng.Sun.Com Robert Hinden hinden@eng.sun.com Mike Holloway mikeh@newbridge.com Marc Horowitz marc@security.ov.com Richard Hovey hovey@silkie.enet.dec.com Phil Irey pirey@relay.nswc.navy.mil Ronald Jacoby rj@sgi.com Scott Kaplan scott@wco.ftp.com Charlie Kaufman kaufman@zk3.dec.com John Linn linn@security.ov.com David Marlow dmarlow@relay.nswc.navy.mil Dwayne McIntosh mcintosh@sleepy.ns.us.boeing.com Chuck McManis chuck.mcmanis@eng.sun.com Greg Minshall minshall@wc.novell.com Stephen Nahm sxn@sun.com Clifford Neuman bcn@isi.edu Brian O'Keefe bok@cnd.hp.com Ming-Jye Sheu msheu@vnet.ibm.com Raj Srinivasan raj.srinivasan@eng.sun.com Don Stephenson don.stephenson@sun.com Theodore Ts'o tytso@mit.edu Randy Turner rturner@qms.com Dick Wallace dick@concord.com Glenn Waters gwaters@bnr.ca Grace Wiechman gw@cray.com