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