rfc2203.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   the encrypted numbers in the credential would have obviated a
   protocol change, but would have introduced more overloading of fields
   and would have made implementations of RPC more complex. Even if the
   fields were encrypted somehow, in most cases an attacker can
   determine the program number and version number by examining the
   destination address of the request and querying the rpcbind service
   on the destination host [Srinivasan-bind].  In any case, even by not
   encrypting the three numbers, RPCSEC_GSS still improves the state of
   security over what existing RPC services have had available
   previously. Implementors of new RPC services that are concerned about
   this risk may opt to design in a "sub-procedure" field that is
   included in the service specific call arguments.

7.2.  Sequence Number Attacks

7.2.1.  Sequence Numbers Above the Window

   An attacker cannot coax the server into raising the sequence number
   beyond the range the legitimate client is aware of (and thus engineer
   a denial of server attack) without constructing an RPC request that
   will pass the header checksum. If the cost of verifying the header
   checksum is sufficiently large (depending on the speed of the
   processor doing the checksum and the cost of checksum algorithm), it
   is possible to envision a denial of service attack (vandalism, in the
   form of wasting processing resources) whereby the attacker sends
   requests that are above the window. The simplest method might be for
   the attacker to monitor the network traffic and then choose a
   sequence number that is far above the current sequence number. Then
   the attacker can send bogus requests using the above window sequence
   number.

7.2.2.  Sequence Numbers Within or Below the Window

   If the attacker sends requests that are within or below the window,
   then even if the header checksum is successfully verified, the server
   will silently discard the requests because the server assumes it has
   already processed the request. In this case, a server can optimize by



Eisler, et. al.             Standards Track                    [Page 18]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


   skipping the header checksum verification if the sequence number is
   below the window, or if it is within the window, not attempt the
   checksum verification if the sequence number has already been seen.

7.3.  Message Stealing Attacks

   This proposal does not address attacks where an attacker can block or
   steal messages without being detected by the server. To implement
   such protection would be tantamount to assuming a state in the RPC
   service. RPCSEC_GSS does not worsen this situation.









































Eisler, et. al.             Standards Track                    [Page 19]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


Appendix A. GSS-API Major Status Codes

   The GSS-API definition [Linn] does not include numerical values for
   the various GSS-API major status codes. It is expected that this will
   be addressed in future RFC. Until then, this appendix defines the
   values for each GSS-API major status code listed in the GSS-API
   definition.  If in the future, the GSS-API definition defines values
   for the codes that are different than what follows, then implementors
   of RPCSEC_GSS will be obliged to map them into the values defined
   below. If in the future, the GSS-API definition defines additional
   status codes not defined below, then the RPCSEC_GSS definition will
   subsume those additional values.

   Here are the definitions of each GSS_S_* major status that the
   implementor of RPCSEC_GSS can expect in the gss_major major field of
   rpc_gss_init_res.  These definitions are not in RPC description
   language form.  The numbers are in base 16 (hexadecimal):

      GSS_S_COMPLETE                  0x00000000
      GSS_S_CONTINUE_NEEDED           0x00000001
      GSS_S_DUPLICATE_TOKEN           0x00000002
      GSS_S_OLD_TOKEN                 0x00000004
      GSS_S_UNSEQ_TOKEN               0x00000008
      GSS_S_GAP_TOKEN                 0x00000010
      GSS_S_BAD_MECH                  0x00010000
      GSS_S_BAD_NAME                  0x00020000
      GSS_S_BAD_NAMETYPE              0x00030000
      GSS_S_BAD_BINDINGS              0x00040000
      GSS_S_BAD_STATUS                0x00050000
      GSS_S_BAD_MIC                   0x00060000
      GSS_S_BAD_SIG                   0x00060000
      GSS_S_NO_CRED                   0x00070000
      GSS_S_NO_CONTEXT                0x00080000
      GSS_S_DEFECTIVE_TOKEN           0x00090000
      GSS_S_DEFECTIVE_CREDENTIAL      0x000a0000
      GSS_S_CREDENTIALS_EXPIRED       0x000b0000
      GSS_S_CONTEXT_EXPIRED           0x000c0000
      GSS_S_FAILURE                   0x000d0000
      GSS_S_BAD_QOP                   0x000e0000
      GSS_S_UNAUTHORIZED              0x000f0000
      GSS_S_UNAVAILABLE               0x00100000
      GSS_S_DUPLICATE_ELEMENT         0x00110000
      GSS_S_NAME_NOT_MN               0x00120000
      GSS_S_CALL_INACCESSIBLE_READ    0x01000000
      GSS_S_CALL_INACCESSIBLE_WRITE   0x02000000
      GSS_S_CALL_BAD_STRUCTURE        0x03000000





Eisler, et. al.             Standards Track                    [Page 20]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


   Note that the GSS-API major status is split into three fields as
   follows:

        Most Significant Bit                     Least Significant Bit
        |------------------------------------------------------------|
        | Calling Error | Routine Error  |    Supplementary Info     |
        |------------------------------------------------------------|
      Bit 31           24 23            16 15                        0

   Up to one status in the Calling Error field can be logically ORed
   with up to one status in the Routine Error field which in turn can be
   logically ORed with zero or more statuses in the Supplementary Info
   field. If the resulting major status has a non-zero Calling Error
   and/or a non-zero Routine Error, then the applicable GSS-API
   operation has failed.  For purposes of RPCSEC_GSS, this means that
   the GSS_Accept_sec_context() call executed by the server has failed.

   If the major status is equal GSS_S_COMPLETE, then this indicates the
   absence of any Errors or Supplementary Info.

   The meanings of most of the GSS_S_* status are defined in the GSS-API
   definition, which the exceptions of:

   GSS_S_BAD_MIC       This code has the same meaning as GSS_S_BAD_SIG.

   GSS_S_CALL_INACCESSIBLE_READ
                        A required input parameter could not be read.

   GSS_S_CALL_INACCESSIBLE_WRITE
                        A required input parameter could not be written.

   GSS_S_CALL_BAD_STRUCTURE
                       A parameter was malformed.


















Eisler, et. al.             Standards Track                    [Page 21]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


Acknowledgements

   Much of the protocol was based on the AUTH_GSSAPI security flavor
   developed by Open Vision Technologies [Jaspan].  In particular, we
   acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen
   McDermott.

   Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike
   Eisler.  Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to
   Sun Microsystems' implementation of RPCSEC_GSS.

   Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie
   Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the
   specification and gave valuable feedback.

   Steve Nahm and Kathy Slattery reviewed various drafts of this
   specification.

   Much of content of Appendix A was excerpted from John Wray's Work in
   Progress on GSS-API Version 2 C-bindings.

References

   [Eisler]            Eisler, M., Schemers, R., and Srinivasan, R.
                       (1996).  "Security Mechanism Independence in ONC
                       RPC," Proceedings of the Sixth Annual USENIX
                       Security Symposium, pp. 51-65.

   [Jaspan]            Jaspan, B. (1995). "GSS-API Security for ONC
                       RPC," `95 Proceedings of The Internet Society
                       Symposium on Network and Distributed System
                       Security, pp. 144- 151.

   [Linn]              Linn, J., "Generic Security Service Application
                       Program Interface, Version 2", RFC 2078, January
                       1997.

   [Srinivasan-bind]   Srinivasan, R., "Binding Protocols for
                       ONC RPC Version 2", RFC 1833, August 1995.

   [Srinivasan-rpc]    Srinivasan, R., "RPC: Remote Procedure Call
                       Protocol Specification Version 2", RFC 1831,
                       August 1995.

   [Srinivasan-xdr]    Srinivasan, R., "XDR: External Data
                       Representation Standard", RFC 1832, August 1995.





Eisler, et. al.             Standards Track                    [Page 22]

RFC 2203           RPCSEC_GSS Protocol Specification      September 1997


Authors' Addresses

   Michael Eisler
   Sun Microsystems, Inc.
   M/S UCOS03
   2550 Garcia Avenue
   Mountain View, CA 94043

   Phone: [phone]
   EMail: [e-mail]


   Alex Chiu
   Sun Microsystems, Inc.
   M/S UMPK17-203
   2550 Garcia Avenue
   Mountain View, CA 94043

   Phone: [phone]
   EMail: [e-mail]


   Lin Ling
   Sun Microsystems, Inc.
   M/S UMPK17-201
   2550 Garcia Avenue
   Mountain View, CA 94043

   Phone: [phone]
   EMail: [e-mail]





















Eisler, et. al.             Standards Track                    [Page 23]