Editor's note: These minutes have not been edited. Minutes, Montreal IETF ONCRPC WG meeting June 28, 1996 Reported by Alex Chiu and Steve Nahm The agenda followed during this meeting was as posted: 1) Introductions 2) Review of draft-ietf-oncrpc-remote-00.txt changes versus RFC1831 3) Review of draft-ietf-oncrpc-rpcbind-00.txt changes versus RFC1833 4) Review of draft-ietf-oncrpc-auth-02.txt changes versus draft-ietf-oncrpc-auth-01.txt 5) Presentation on the GSS API-based Security mechanism by Mike Eisler of SunSoft Steve Nahm chaired the meeting and presented summaries of the changes made to the three new drafts. The slides for these summaries appear in the Montreal IETF proceedings. Note that the first draft, draft-ietf-oncrpc-remote-00.txt, was truncated when it was posted. A new version will be posted shortly. The changes to the RPC V2 specification (draft-ietf-oncrpc-remote-00.txt) were noncontroversial. The chair indicated that he is working to transfer administration of the RPC number space to IANA, as the new draft specifies. The most significant change to the RPC V2 draft is additional wording regarding Transmission IDs (XIDs) in the RPC V2 header. The new wording recommends that the XID be considered specific to each client-server session by checking that other parameters of the call match: RPC program number, RPC program version, RPC procedure and possibly the transport end-point (such as TCP/IP address and port). During discussion it was decided that including RPC procedure in this check may not be necessary and that this recommendation be dropped from the draft. The draft-ietf-oncrpc-rpcbind-00.txt changes were more extensive than the RPC V2 changes. This is mostly due to the change to the RPCL specification to replace all instances of the "long" data type with the "int" data type. This change was motivated by work being done with 64-bit operating systems, many of which have adopted the "LP64" convention in which "long" is a 64-bit data type and "int" is a 32-bit data type. "long" is not a base type defined in RPCL (see RFC1832), whereas "int" is clearly defined as a 32-bit value. It was suggested that for further clarity the specification use a typedef to create an int32 data type and use that instead. This was agreed to. The other major change to the RPC Bind specification was the addition of a Security Considerations section. No changes were suggested to this section of the new draft. The last draft reviewed was draft-ietf-oncrpc-auth-02.txt. Several significant changes were made to this draft: First, a WARNING was added to the draft to document that the Diffie-Hellman mechanism used by AUTH_DH has been compromised, including a reference; and a warning that certain implementations of Kerberos version 4 ticket servers are vulnerable to attack as documented in a CERT advisory which is referenced. Second, additional information is included to document when certain authentication errors are to be returned or expected in both AUTH_DH and AUTH_KERB4. Finally, additional information about AUTH_KERB4 authentication errors was provided. A suggestion was made to include in the Kerberos warning an explanation that these vulnerabilities were being fixed. The chair held that the CERT advisory reference can be used to find mitigations, and that this additional information is outside the scope of the Authentication specification. Another suggestion was made to refer to the USENIX paper in which Bellovin detailed the vulnerabilities of Kerberos. This was agreed to. A comment was made that it would have been better to group authentication errors with the authentication mechanism rather than as part of the RPC header. Putting it in the header requires someone to manage the authentication error space in addition to the other two number spaces managed by the central authority (RPC program numbers and authentication mechanism numbers). The chair agreed that this would have been better, but that change needs to wait until the RPC protocol itself is revised. The chair agreed to note this additonal number management issue when transitioning the registry authority to IANA. The final presentation of the meeting was by Mike Eisler who described a GSS API Security mechanism for ONC RPC. Slides for his presentation are available elsewhere in the proceedings. Issues raised during the presentation were: 1. How does RPCSEC_GSS handle situations where an attacker steals and destroys the whole packet during the first transmission? Mike Eisler responded that the situation is no worse than with existing authentication mechanisms. Ultimately the RPC application needs to take responsibilty for detecting missing packets. 2. There was some question regarding the sequence number used in the mechanism. Was this being used to security reasons or was there an attempt to improve RPC semantics? There was an attempt to ameliorate time-stamp problems seen with threaded RPC applications. Current authentication mechanisms like AUTH_DH do not work well with threaded clients as messages may be received out of order. AUTH_DH requires that timestamps always increase, which may not be true when messages are received out of order from threaded clients. The RPCSEC_GSS window allows for out-of-order messages. 3. On the server replies, Mike Eisler said security type (integrity or privacy) is specified on the call and the reply always uses the same mechanism. One person observed that this may not be desired if a request needs to use privacy, but the possibly large reply may not need this expensive security type. The design was intended to keep things simple. Providing this kind of flexibility would requires a more complicated API. 4. On the server reply to context destruction, Mike Eisler will check whether it is done by sending the credential first and then replying or replying with the credential. The client must send a valid credential as part of the context destruction request. 5. A suggestion was made that IPSEC might be used. Mike Eisler said that while end-system IPSEC could be used by an implementation of RPCSEC_GSS, IPSEC doesn't seem to fit with RPC applications such as NFS where prinicpals may change with each message. If IPSEC is eventually able to support this, Mike hopes that any API used to control such prinicpal changes is supported via GSS API. 6. How are replay packets handled? Mike Eisler said that the server will check and check until window size is exceeded; then the message is dropped. Hillary Orman said, "Replay prevention is not a security problem." Mike countered that most existing RPC applications do not attempt to detect replays due to various implementation shortcomings (eg, lack of duplicate request caches, weak authenitcation mechanisms currently available). Including replay detection eases the burden of RPC programmers wishing to use RPCSEC_GSS. 7. Marc Horowitz requested that the defined binary constants from GSS API be allowed in the RPCSEC_GSS API rather than requiring stringified names. 8. Hillary Orman noted that a denial-of-service attack is possible if the attacker sends copies of the same RPC request at the server. Unless the server first checks that the sequence number is below the window, it may expend resources verifying and unsealing the message. Mike noted that even if this check were done, the attacker could send messages that were within the window and cause the same effect. Nonetheless, doing the sequence number check early would be a good implementation practice. After the RPCSEC_GSS talk, the chair summarized the next steps: reissue the working group drafts after the revisions suggested were made, and then proceed to Last Call for moving RPC, XDR and Bind to Draft Standard. Also, future work was noted for reviewing and considering for the standards track the RPCSEC_GSS security mechanism.