home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / oncrpc / oncrpc-minutes-94mar.txt < prev    next >
Text File  |  1994-06-06  |  7KB  |  170 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Raj Srinivasan/SunSoft
  5.  
  6. Minutes of the ONC Remote Procedure Call Working Group (ONCRPC)
  7.  
  8. The ONCRPC Working Group met on 28 March at the Seattle IETF. There were
  9. thirty-three attendees.
  10.  
  11.  
  12. Afternoon Session
  13.  
  14. After introductions, Dave Crocker talked about IETF practices regarding
  15. standardization.  The IETF is not standardizing ``The RPC Everyone
  16. Should Use.''
  17.  
  18. Steve Nahm gave a presentation on the history and architecture of ONC
  19. RPC and XDR.
  20.  
  21. Following Steve's presentation, the group reviewed the charter.  There
  22. was acceptance of the charter wording and delivery timetable.  The
  23. initial standard will have no changes from the current practice of ONC
  24. RPC and XDR. The follow-on working group will work on issues raised by
  25. this working group.  Delivery of documents describing the standard is
  26. currently scheduled to be in May (before the next IETF).
  27.  
  28. The group then reviewed XDR. Only the main changes from RFC 1014 were
  29. reviewed.  This was the section on the quadruple-precision floating
  30. point data type, and the wording about NaNs.  It was suggested that at
  31. least the IEEE specification for NaNs should be listed in an appendix
  32. (all NaNs and their meanings are not required).
  33.  
  34.  
  35. Evening Session
  36.  
  37. The changes from RFC 1057 were reviewed.  Suggestions were:
  38.  
  39.  
  40.    o Remove ``Sun''---call it ``ONC RPC'' rather than ``Sun RPC.''
  41.      wherever appropriate in the document.
  42.  
  43.    o In a discussion of the authentication flavors that are currently
  44.      deployed, it was suggested that some be required (mandatory) and
  45.      others be optional in implementations; AUTH_NONE is required;
  46.      AUTH_SYS should be moved to an appendix and it should be strongly
  47.      recommended that it be included in any implementation (note that
  48.      NFS uses AUTH_SYS); Diffie-Hellman and Kerberos-based authentication
  49.      mechanisms should be moved to separate drafts, not part of the main
  50.      standard, which will become Informational RFCs that document
  51.      existing practice.  Also, the Diffie-Hellman document should give a
  52.      reference to the paper that points out the weaknesses of this
  53.      mechanism, and deprecate this mechanism because of its weaknesses.
  54.      A caveat that AUTH_SYS provides legitimate authentication only when
  55.      all RPC-related applications on all platforms on the network are
  56.      under control, is required.  An explanation of the ``privileged
  57.      ports'' mechanism as it used in conjunction with AUTH_SYS for
  58.      certifying the sender/receiver should be added.
  59.  
  60.      The main reason for taking this tack is due to the known weakness
  61.      of the Diffie-Hellman mechanism, and the relatively low deployment
  62.      of the Kerberos-based mechanism.
  63.  
  64.    o Change AUTH_KERB to AUTH_KERB4.
  65.  
  66.    o Change AUTH_DES to AUTH_DH. Wherever ``DES Authentication'' is
  67.      mentioned, change it to ``Diffie-Hellman Authentication.''
  68.  
  69.    o Change ``window'' to ``lifetime,'' for describing the lifetime of a
  70.      credential.
  71.  
  72.    o Section on Kerberos-based authentication mentions ``window''
  73.      without defining it.
  74.  
  75.    o Note in the document that the credential and verifier are
  76.      historically separate items, but always used together.
  77.  
  78.    o A short section on Kerberos naming should be added.  Some guidance
  79.      as to how a client could determine a server's name is needed.
  80.  
  81.    o In the authkerb_fullname structure, ``ticket<>'' should be changed
  82.      to have a maximum length of 392.
  83.  
  84.    o Mention that the Diffie-Hellman modulus is in hexadecimal notation.
  85.  
  86.    o The RPCBIND protocols (including the portmapper version 2 protocol)
  87.      should be moved to a separate Internet-Draft.  This will be
  88.      standardized along with RPC and XDR, and be the recommended binding
  89.      method.
  90.  
  91.    o The RPCBIND document must note the properties of ``netid.''
  92.      Perhaps netid's for common transports should be defined.
  93.  
  94.    o Multicast should be mentioned in addition to broadcast---there is
  95.      at least one implementation that has used multicasting
  96.      successfully.  The two mechanisms are very similar in RPC.
  97.  
  98.    o Need references to Kerberos V4.
  99.  
  100.    o Section 4 (``Transports and Semantics'') the RPC document should
  101.      point to the ``Record Marking Standard'' section (section 10).
  102.  
  103.  
  104. Evening Session - Follow-on Working Group Discussion
  105.  
  106. The following suggestions were made for consideration by the follow-on
  107. working group.
  108.  
  109.  
  110.    o A GSS API based mechanism for security could be incorporated into
  111.      ONC RPC. Underlying this could be other mechanisms such as Kerberos
  112.      V5, RSA, etc.  At least one company has done this - details need to
  113.      be investigated.
  114.  
  115.    o Features to support DCE/ONC gateways.
  116.  
  117.    o Formalize multicast support.  One proposal was to have multicast
  118.      requests followed by multiple responses from multiple nodes;
  119.      another mentioned using name services to create multicast groups,
  120.      etc.  Neither affects packet formats.
  121.  
  122.    o XDR should support wide characters.  It was suggested that array
  123.      encodings be used for wide characters.  Other encodings need to be
  124.      investigated.
  125.  
  126.    o Support the ``at most once'' semantic over all transports.
  127.  
  128.    o Need more error information in the ``rejected_reply'' union,
  129.      following the ``auth_stat'' field in the ``AUTH_ERROR'' arm.
  130.  
  131.    o How about alternative XDR encodings?
  132.  
  133.  
  134. Attendees
  135.  
  136. Steve Alexander          stevea@lachman.com
  137. Mark Allyn               allyn@netcom.com
  138. Susie Armstrong          susie@mentat.com
  139. Karl Auerbach            auerbach@ssds.com
  140. Brad Burdick             bburdick@radio.com
  141. Brett Chappell           bchappe@relay.nswc.navy.mil
  142. David Crocker            dcrocker@mordor.stanford.edu
  143. Dante Delucia            dante@usc.edu
  144. Robert Gilligan          Bob.Gilligan@Eng.Sun.Com
  145. Robert Hinden            hinden@eng.sun.com
  146. Mike Holloway            mikeh@newbridge.com
  147. Marc Horowitz            marc@security.ov.com
  148. Richard Hovey            hovey@silkie.enet.dec.com
  149. Phil Irey                pirey@relay.nswc.navy.mil
  150. Ronald Jacoby            rj@sgi.com
  151. Scott Kaplan             scott@wco.ftp.com
  152. Charlie Kaufman          kaufman@zk3.dec.com
  153. John Linn                linn@security.ov.com
  154. David Marlow             dmarlow@relay.nswc.navy.mil
  155. Dwayne McIntosh          mcintosh@sleepy.ns.us.boeing.com
  156. Chuck McManis            chuck.mcmanis@eng.sun.com
  157. Greg Minshall            minshall@wc.novell.com
  158. Stephen Nahm             sxn@sun.com
  159. Clifford Neuman          bcn@isi.edu
  160. Brian O'Keefe            bok@cnd.hp.com
  161. Ming-Jye Sheu            msheu@vnet.ibm.com
  162. Raj Srinivasan           raj.srinivasan@eng.sun.com
  163. Don Stephenson           don.stephenson@sun.com
  164. Theodore Ts'o            tytso@mit.edu
  165. Randy Turner             rturner@qms.com
  166. Dick Wallace             dick@concord.com
  167. Glenn Waters             gwaters@bnr.ca
  168. Grace Wiechman           gw@cray.com
  169.  
  170.