home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / oncrpc / oncrpc-minutes-96jun.txt < prev    next >
Encoding:
Text File  |  1996-10-07  |  8.0 KB  |  151 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3.  
  4.  
  5. Minutes, Montreal IETF ONCRPC WG meeting
  6. June 28, 1996
  7.  
  8. Reported by Alex Chiu and Steve Nahm
  9.  
  10. The agenda followed during this meeting was as posted:
  11.  
  12. 1) Introductions
  13. 2) Review of draft-ietf-oncrpc-remote-00.txt changes versus RFC1831
  14. 3) Review of draft-ietf-oncrpc-rpcbind-00.txt changes versus RFC1833
  15. 4) Review of draft-ietf-oncrpc-auth-02.txt changes versus
  16.    draft-ietf-oncrpc-auth-01.txt
  17. 5) Presentation on the GSS API-based Security mechanism by Mike Eisler
  18.    of SunSoft
  19.  
  20. Steve Nahm chaired the meeting and presented summaries of the changes made to
  21. the three new drafts.  The slides for these summaries appear in the Montreal
  22. IETF proceedings.  Note that the first draft, draft-ietf-oncrpc-remote-00.txt,
  23. was truncated when it was posted.  A new version will be posted shortly.
  24.  
  25. The changes to the RPC V2 specification (draft-ietf-oncrpc-remote-00.txt) were
  26. noncontroversial.  The chair indicated that he is working to transfer
  27. administration of the RPC number space to IANA, as the new draft specifies.
  28. The most significant change to the RPC V2 draft is additional wording
  29. regarding Transmission IDs (XIDs) in the RPC V2 header.  The new wording
  30. recommends that the XID be considered specific to each client-server session
  31. by checking that other parameters of the call match:  RPC program number, RPC
  32. program version, RPC procedure and possibly the transport end-point (such as
  33. TCP/IP address and port).  During discussion it was decided that including RPC
  34. procedure in this check may not be necessary and that this recommendation be
  35. dropped from the draft.
  36.  
  37. The draft-ietf-oncrpc-rpcbind-00.txt changes were more extensive than the RPC
  38. V2 changes.  This is mostly due to the change to the RPCL specification to
  39. replace all instances of the "long" data type with the "int" data type.  This
  40. change was motivated by work being done with 64-bit operating systems, many of
  41. which have adopted the "LP64" convention in which "long" is a 64-bit data type
  42. and "int" is a 32-bit data type.  "long" is not a base type defined in RPCL
  43. (see RFC1832), whereas "int" is clearly defined as a 32-bit value.  It was
  44. suggested that for further clarity the specification use a typedef to create
  45. an int32 data type and use that instead.  This was agreed to.
  46.  
  47. The other major change to the RPC Bind specification was the addition of a
  48. Security Considerations section.  No changes were suggested to this section of
  49. the new draft.
  50.  
  51. The last draft reviewed was draft-ietf-oncrpc-auth-02.txt.  Several
  52. significant changes were made to this draft:  First, a WARNING was added to
  53. the draft to document that the Diffie-Hellman mechanism used by AUTH_DH has
  54. been compromised, including a reference; and a warning that certain
  55. implementations of Kerberos version 4 ticket servers are vulnerable to attack
  56. as documented in a CERT advisory which is referenced.  Second, additional
  57. information is included to document when certain authentication errors are to
  58. be returned or expected in both AUTH_DH and AUTH_KERB4.  Finally, additional
  59. information about AUTH_KERB4 authentication errors was provided.
  60.  
  61. A suggestion was made to include in the Kerberos warning an explanation that
  62. these vulnerabilities were being fixed.  The chair held that the CERT advisory
  63. reference can be used to find mitigations, and that this additional
  64. information is outside the scope of the Authentication specification.  Another
  65. suggestion was made to refer to the USENIX paper in which Bellovin detailed
  66. the vulnerabilities of Kerberos.  This was agreed to.
  67.  
  68. A comment was made that it would have been better to group authentication
  69. errors with the authentication mechanism rather than as part of the RPC
  70. header.  Putting it in the header requires someone to manage the
  71. authentication error space in addition to the other two number spaces managed
  72. by the central authority (RPC program numbers and authentication mechanism
  73. numbers).  The chair agreed that this would have been better, but that change
  74. needs to wait until the RPC protocol itself is revised.  The chair agreed to
  75. note this additonal number management issue when transitioning the registry
  76. authority to IANA.
  77.  
  78. The final presentation of the meeting was by Mike Eisler who described a GSS
  79. API Security mechanism for ONC RPC.  Slides for his presentation are available
  80. elsewhere in the proceedings.  Issues raised during the presentation were:
  81.  
  82.      1. How does RPCSEC_GSS handle situations where an attacker steals
  83.         and destroys the whole packet during the first transmission?
  84.  
  85. Mike Eisler responded that the situation is no worse than with existing
  86. authentication mechanisms.  Ultimately the RPC application needs to take
  87. responsibilty for detecting missing packets.
  88.  
  89.      2. There was some question regarding the sequence number used in
  90.         the mechanism.  Was this being used to security reasons or was
  91.         there an attempt to improve RPC semantics?
  92.  
  93. There was an attempt to ameliorate time-stamp problems seen with threaded RPC
  94. applications.  Current authentication mechanisms like AUTH_DH do not work well
  95. with threaded clients as messages may be received out of order. AUTH_DH
  96. requires that timestamps always increase, which may not be true when messages
  97. are received out of order from threaded clients.  The RPCSEC_GSS window allows
  98. for out-of-order messages.
  99.  
  100.      3. On the server replies, Mike Eisler said security type (integrity or
  101.         privacy) is specified on the call and the reply always uses the
  102.         same mechanism.  One person observed that this may not be desired
  103.         if a request needs to use privacy, but the possibly large reply
  104.         may not need this expensive security type.
  105.  
  106. The design was intended to keep things simple.  Providing this kind of
  107. flexibility would requires a more complicated API.
  108.  
  109.      4. On the server reply to context destruction, Mike Eisler will check
  110.         whether it is done by sending the credential first and then
  111.         replying or replying with the credential.
  112.  
  113. The client must send a valid credential as part of the context destruction
  114. request.
  115.  
  116.      5. A suggestion was made that IPSEC might be used. Mike Eisler said
  117.         that while end-system IPSEC could be used by an implementation of
  118.         RPCSEC_GSS, IPSEC doesn't seem to fit with RPC applications such as
  119.         NFS where prinicpals may change with each message.  If IPSEC is
  120.         eventually able to support this, Mike hopes that any API used to
  121.         control such prinicpal changes is supported via GSS API.
  122.  
  123.      6. How are replay packets handled?  Mike Eisler said that the server 
  124.         will check and check until window size is exceeded; then the
  125.         message is dropped.  Hillary Orman said, "Replay prevention is
  126.         not a security problem."  Mike countered that most existing RPC
  127.         applications do not attempt to detect replays due to various
  128.         implementation shortcomings (eg, lack of duplicate request caches,
  129.         weak authenitcation mechanisms currently available).  Including replay
  130.         detection eases the burden of RPC programmers wishing to use
  131.         RPCSEC_GSS.
  132.  
  133.      7. Marc Horowitz requested that the defined binary constants from GSS API
  134.         be allowed in the RPCSEC_GSS API rather than requiring stringified
  135.         names.
  136.  
  137.      8. Hillary Orman noted that a denial-of-service attack is possible if the
  138.         attacker sends copies of the same RPC request at the server. Unless
  139.         the server first checks that the sequence number is below the window,
  140.         it may expend resources verifying and unsealing the message. Mike
  141.         noted that even if this check were done, the attacker could send
  142.         messages that were within the window and cause the same effect.
  143.         Nonetheless, doing the sequence number check early would be a good
  144.         implementation practice.
  145.  
  146. After the RPCSEC_GSS talk, the chair summarized the next steps: reissue the
  147. working group drafts after the revisions suggested were made, and then proceed
  148. to Last Call for moving RPC, XDR and Bind to Draft Standard.  Also, future
  149. work was noted for reviewing and considering for the standards track the
  150. RPCSEC_GSS security mechanism.
  151.