home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-oncrpc-rpcsec_gss-03.txt < prev    next >
Text File  |  1997-03-20  |  49KB  |  1,241 lines
  1.  
  2.  
  3.  
  4. ONC RPC Working Group                                      M. Eisler
  5. Internet Draft                                             A. Chiu
  6. Document: draft-ietf-oncrpc-rpcsec_gss-03.txt              L. Ling
  7.                                                            March 1997
  8.  
  9.  
  10.                    RPCSEC_GSS Protocol Specification
  11.  
  12. Abstract
  13.  
  14.    This memo describes an ONC/RPC security flavor that allows RPC
  15.    protocols to access the Generic Security Services Application
  16.    Programming Interface (referred to henceforth as GSS-API).
  17.  
  18. Status of this Memo
  19.  
  20.    This document is an Internet-Draft.  Internet-Drafts are working
  21.    documents of the Internet Engineering Task Force (IETF), its areas,
  22.    and its working groups.  Note that other groups may also distribute
  23.    working documents as Internet-Drafts.
  24.  
  25.    Internet-Drafts are draft documents valid for a maximum of six
  26.    months.  This Internet-Draft expires in September 1997.  Internet-
  27.    Drafts may be updated, replaced, or obsoleted by other documents at
  28.    any time. It is not appropriate to use Internet-Drafts as reference
  29.    material or to cite them other than as "work in progress."
  30.  
  31.    To learn the current status of any Internet-Draft, please check the
  32.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  33.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  34.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  35.    ftp.isi.edu (US West Coast).
  36.  
  37.    Comments on this document should be sent to the IETF ONCRPC Working
  38.    Group discussion list:
  39.  
  40.         oncrpc-wg@sunroof.eng.sun.com
  41.  
  42.    Distribution of this memo is unlimited.
  43.  
  44.  
  45. Table of Contents
  46.  
  47.    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
  48.    2.  Review of the RPC Message Protocol . . . . . . . . . . . . . . 2
  49.    3.  Flavor Number Assignment . . . . . . . . . . . . . . . . . . . 5
  50.    4.  New auth_stat Values . . . . . . . . . . . . . . . . . . . . . 5
  51.    5.  Elements of the RPCSEC_GSS Security Protocol . . . . . . . . . 6
  52.    5.1.  Version Selection  . . . . . . . . . . . . . . . . . . . . . 7
  53.    5.2.  Context Creation . . . . . . . . . . . . . . . . . . . . . . 7
  54.    5.2.1.  Mechanism and QOP Selection  . . . . . . . . . . . . . . . 7
  55.    5.2.2.  Context Creation Requests  . . . . . . . . . . . . . . . . 8
  56.    5.2.3.  Context Creation Responses . . . . . . . . . . . . . . . . 9
  57.    5.2.3.1.  Context Creation Response - Successful Acceptance  . . . 9
  58.  
  59.  
  60.  
  61. Expires: September 1997                                         [Page 1]
  62.  
  63. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  64.  
  65.  
  66.    5.2.3.1.1.  Client Processing of Successful Context Creation
  67.                Responses  . . . . . . . . . . . . . . . . . . . . .  10
  68.    5.2.3.2.  Context Creation Response - Unsuccessful Cases . . . .  10
  69.    5.3.  RPC Data Exchange  . . . . . . . . . . . . . . . . . . . .  11
  70.    5.3.1.  RPC Request Header . . . . . . . . . . . . . . . . . . .  11
  71.    5.3.2.  RPC Request Data . . . . . . . . . . . . . . . . . . . .  12
  72.    5.3.2.1.  RPC Request Data - No Data Integrity . . . . . . . . .  12
  73.    5.3.2.2.  RPC Request Data - With Data Integrity . . . . . . . .  12
  74.    5.3.2.3.  RPC Request Data - With Data Privacy . . . . . . . . .  13
  75.    5.3.3.  Server Processing of RPC Data Requests . . . . . . . . .  13
  76.    5.3.3.1.  Context Management . . . . . . . . . . . . . . . . . .  13
  77.    5.3.3.2.  Server Reply - Request Accepted  . . . . . . . . . . .  14
  78.    5.3.3.3.  Server Reply - Request Denied  . . . . . . . . . . . .  15
  79.    5.3.3.4.  Mapping of GSS-API Errors to Server Responses  . . . .  16
  80.    5.3.3.4.1.  GSS_GetMIC() Failure . . . . . . . . . . . . . . . .  16
  81.    5.3.3.4.2.  GSS_VerifyMIC() Failure  . . . . . . . . . . . . . .  16
  82.    5.3.3.4.3.  GSS_Unwrap() Failure . . . . . . . . . . . . . . . .  17
  83.    5.3.3.4.4.  GSS_Wrap() Failure . . . . . . . . . . . . . . . . .  17
  84.    5.4.  Context Destruction  . . . . . . . . . . . . . . . . . . .  17
  85.    6.  Set of GSS-API Mechanisms  . . . . . . . . . . . . . . . . .  17
  86.    7.  Security Considerations  . . . . . . . . . . . . . . . . . .  18
  87.    7.1.  Privacy of Call Header . . . . . . . . . . . . . . . . . .  18
  88.    7.2.  Sequence Number Attacks  . . . . . . . . . . . . . . . . .  18
  89.    7.2.1.  Sequence Numbers Above the Window  . . . . . . . . . . .  18
  90.    7.2.2.  Sequence Numbers Within or Below the Window  . . . . . .  18
  91.    7.3.  Message Stealing Attacks . . . . . . . . . . . . . . . . .  19
  92.    8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  19
  93.    9.  References . . . . . . . . . . . . . . . . . . . . . . . . .  19
  94.    10.  Authors' Addresses  . . . . . . . . . . . . . . . . . . . .  20
  95.  
  96. 1.  Introduction
  97.  
  98.    This document describes the protocol used by the RPCSEC_GSS security
  99.    flavor.  Security flavors have been called authentication flavors for
  100.    historical reasons. This memo recognizes that there are two other
  101.    security services besides authentication, integrity, and privacy, and
  102.    so defines a new RPCSEC_GSS security flavor.
  103.  
  104.    The protocol is described using the XDR language [Srinivasan-xdr].
  105.    The reader is assumed to be familiar with ONC RPC and the security
  106.    flavor mechanism [Srinivasan-rpc].  The reader is also assumed to be
  107.    familiar with the GSS-API framework [Linn].  The RPCSEC_GSS security
  108.    flavor uses GSS-API interfaces to provide security services that are
  109.    independent of the underlying security mechanism.
  110.  
  111. 2.  Review of the RPC Message Protocol
  112.  
  113.    This memo refers to several fields of the RPC protocol. For
  114.    convenience of reviewers, as this document is in Internet-Draft
  115.    state, an XDR language description of the RPC message protocol is
  116.    provided here.
  117.  
  118.       /* RPC message type */
  119.  
  120.  
  121.  
  122.  
  123. Expires: September 1997                                         [Page 2]
  124.  
  125. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  126.  
  127.  
  128.       enum msg_type {
  129.           CALL  = 0,
  130.           REPLY = 1
  131.       };
  132.  
  133.       /* Reply types */
  134.  
  135.       enum reply_stat {
  136.           MSG_ACCEPTED = 0,
  137.           MSG_DENIED   = 1
  138.       };
  139.  
  140.       /* Security flavors */
  141.  
  142.       enum auth_flavor {
  143.           AUTH_NONE = 0,
  144.           AUTH_SYS = 1,
  145.           AUTH_SHORT = 2
  146.       };
  147.  
  148.       /* Status of accepted messages */
  149.  
  150.       enum accept_stat {
  151.           SUCCESS = 0,
  152.           PROG_UNAVAIL = 1,
  153.           PROG_MISMATCH = 2,
  154.           PROC_UNAVAIL = 3,
  155.           GARBAGE_ARGS = 4,
  156.           SYSTEM_ERR = 5
  157.       };
  158.  
  159.       /* Status of rejected messages */
  160.  
  161.       enum reject_stat {
  162.           RPC_MISMATCH = 0,
  163.           AUTH_ERROR = 1
  164.       };
  165.  
  166.       /* Why authentication failed */
  167.  
  168.       enum auth_stat {
  169.           AUTH_OK = 0,
  170.  
  171.           /* failed at remote end */
  172.  
  173.           AUTH_BADCRED = 1,
  174.           AUTH_REJECTEDCRED = 2,
  175.           AUTH_BADVERF = 3,
  176.           AUTH_REJECTEDVERF = 4,
  177.           AUTH_TOOWEAK = 5,
  178.  
  179.           /* failed locally */
  180.  
  181.           AUTH_INVALIDRESP = 6,
  182.  
  183.  
  184.  
  185. Expires: September 1997                                         [Page 3]
  186.  
  187. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  188.  
  189.  
  190.           AUTH_FAILED = 7
  191.       };
  192.  
  193.       /* Opaque structure of credential and verifier */
  194.  
  195.       struct opaque_auth {
  196.           auth_flavor flavor;
  197.           opaque body<400>;
  198.       };
  199.  
  200.       /* The RPC message */
  201.  
  202.       struct rpc_msg {
  203.           unsigned int xid;
  204.           union switch (msg_type mtype) {
  205.           case CALL:
  206.               call_body cbody;
  207.           case REPLY:
  208.               reply_body rbody;
  209.           } body;
  210.       };
  211.  
  212.       /* Body of RPC call */
  213.  
  214.       struct call_body {
  215.           unsigned int rpcvers;
  216.           unsigned int prog;
  217.           unsigned int vers;
  218.           unsigned int proc;
  219.           opaque_auth  cred;
  220.           opaque_auth  verf;
  221.  
  222.           /* procedure specific parameters start here */
  223.       };
  224.  
  225.       /* Body of RPC reply */
  226.  
  227.       union reply_body switch (reply_stat stat) {
  228.       case MSG_ACCEPTED:
  229.           accepted_reply areply;
  230.       case MSG_DENIED:
  231.           rejected_reply rreply;
  232.       } reply;
  233.  
  234.       /* Accepted reply */
  235.  
  236.       struct accepted_reply {
  237.           opaque_auth verf;
  238.           union switch (accept_stat stat) {
  239.           case SUCCESS:
  240.               opaque results[0];
  241.  
  242.               /* procedure-specific results start here */
  243.  
  244.  
  245.  
  246.  
  247. Expires: September 1997                                         [Page 4]
  248.  
  249. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  250.  
  251.  
  252.           case PROG_MISMATCH:
  253.               struct {
  254.                   unsigned int low;
  255.                   unsigned int high;
  256.               } mismatch_info;
  257.  
  258.           default:
  259.  
  260.               /*
  261.                * Void.  Cases include PROG_UNAVAIL,
  262.                * PROC_UNAVAIL, GARBAGE_ARGS, and
  263.                * SYSTEM_ERR.
  264.                */
  265.  
  266.               void;
  267.           } reply_data;
  268.       };
  269.  
  270.       /* Rejected reply */
  271.  
  272.       union rejected_reply switch (reject_stat stat) {
  273.       case RPC_MISMATCH:
  274.           struct {
  275.               unsigned int low;
  276.               unsigned int high;
  277.           } mismatch_info;
  278.       case AUTH_ERROR:
  279.           auth_stat stat;
  280.       };
  281.  
  282. 3.  Flavor Number Assignment
  283.  
  284.    The RPCSEC_GSS security flavor has been assigned the value of 6:
  285.  
  286.       enum auth_flavor {
  287.           ...
  288.           RPCSEC_GSS = 6      /* RPCSEC_GSS security flavor */
  289.       };
  290.  
  291. 4.  New auth_stat Values
  292.  
  293.    RPCSEC_GSS requires the addition of two new values to the auth_stat
  294.    enumerated type definition:
  295.  
  296.       enum auth_stat {
  297.               ...
  298.               /*
  299.                * RPCSEC_GSS errors
  300.                */
  301.               RPCSEC_GSS_CREDPROBLEM = 13,
  302.               RPCSEC_GSS_CTXPROBLEM = 14
  303.       };
  304.    The descriptions of these two new values are defined later in this
  305.    memo.
  306.  
  307.  
  308.  
  309. Expires: September 1997                                         [Page 5]
  310.  
  311. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  312.  
  313.  
  314. 5.  Elements of the RPCSEC_GSS Security Protocol
  315.  
  316.    An RPC session based on the RPCSEC_GSS security flavor consists of
  317.    three phases: context creation, RPC data exchange, and context
  318.    destruction.  In the following discussion, protocol elements for
  319.    these three phases are described.
  320.  
  321.    The following description of the RPCSEC_GSS protocol uses some of the
  322.    definitions within XDR language description of the RPC protocol.
  323.  
  324.    Context creation and destruction use control messages that are not
  325.    dispatched to service procedures registered by an RPC server.  The
  326.    program and version numbers used in these control messages are the
  327.    same as the RPC service's program and version numbers.  The procedure
  328.    number used is NULLPROC (zero).  A field in the credential
  329.    information (the gss_proc field which is defined in the
  330.    rpc_gss_cred_t structure below) specifies whether a message is to be
  331.    interpreted as a control message or a regular RPC message.  If this
  332.    field is set to RPCSEC_GSS_DATA, no control action is implied; in
  333.    this case, it is a regular data message.  If this field is set to any
  334.    other value, a control action is implied.  This is described in the
  335.    following sections.
  336.  
  337.    Just as with normal RPC data exchange messages, the transaction
  338.    identifier (the xid field in struct rpc_msg), should be set to unique
  339.    values on each call for context creation and context destruction.
  340.  
  341.    The following definitions are used for describing the protocol.
  342.  
  343.       /* RPCSEC_GSS control procedures */
  344.  
  345.  
  346.       enum rpc_gss_proc_t {
  347.               RPCSEC_GSS_DATA = 0,
  348.               RPCSEC_GSS_INIT = 1,
  349.               RPCSEC_GSS_CONTINUE_INIT = 2,
  350.               RPCSEC_GSS_DESTROY = 3
  351.       };
  352.  
  353.       /* RPCSEC_GSS services */
  354.  
  355.       enum rpc_gss_service_t {
  356.           /* Note: the enumerated value for 0 is reserved. */
  357.           rpc_gss_svc_none = 1,
  358.           rpc_gss_svc_integrity = 2,
  359.           rpc_gss_svc_privacy = 3
  360.       };
  361.  
  362.       /* Credential */
  363.  
  364.       /*
  365.        * Note: version 0 is reserved for possible future
  366.        * definition of a version negotiation protocol
  367.        *
  368.  
  369.  
  370.  
  371. Expires: September 1997                                         [Page 6]
  372.  
  373. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  374.  
  375.  
  376.        */
  377.       #define RPCSEC_GSS_VERS_1 1
  378.  
  379.       struct rpc_gss_cred_t {
  380.           union switch (unsigned int version) { /* version of
  381.                                                       RPCSEC_GSS */
  382.           case RPCSEC_GSS_VERS_1:
  383.               struct {
  384.                   rpc_gss_proc_t gss_proc;  /* control procedure */
  385.                   unsigned int seq_num;   /* sequence number */
  386.                   rpc_gss_service_t service; /* service used */
  387.                   opaque handle<>;       /* context handle */
  388.               } rpc_gss_cred_vers_1_t;
  389.           }
  390.       };
  391.  
  392.       /* Maximum sequence number value */
  393.  
  394.       #define MAXSEQ 0x80000000
  395.  
  396. 5.1.  Version Selection
  397.  
  398.    This document defines just one protocol version (RPCSEC_GSS_VERS_1).
  399.    The client should assume that the server supports RPCSEC_GSS_VERS_1
  400.    and issue a Context Creation message (as described in the section
  401.    'Context Creation'). If the server does not support
  402.    RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of
  403.    MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of
  404.    AUTH_REJECTED_CRED.
  405.  
  406. 5.2.  Context Creation
  407.  
  408.    Before RPC data is exchanged on a session using the RPCSEC_GSS
  409.    flavor, a context must be set up between the client and the server.
  410.    Context creation may involve zero or more RPC exchanges.  The number
  411.    of exchanges depends on the security mechanism.
  412.  
  413. 5.2.1.  Mechanism and QOP Selection
  414.  
  415.    There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API
  416.    mechanism identifiers or QOP values. At minimum, it is expected that
  417.    implementations of the RPCSEC_GSS protocol provide interfaces in the
  418.    RPC programming layer to:
  419.  
  420.    *    specify mechanism identifiers, QOP values, and RPCSEC_GSS
  421.         service values on the client side, and to
  422.  
  423.    *    return mechanism identifiers, QOP values, and RPCSEC_GSS service
  424.         values on a per-request basis to the server side.
  425.  
  426.    Additionally, implementations may depend on negotiation schemes
  427.    constructed as pseudo-mechanisms under the GSS-API, such as the
  428.    Simple GSS-API Negotiation Mechanism [Baize]. Because such schemes
  429.    are below the GSS-API layer, the RPCSEC_GSS protocol, as specified in
  430.  
  431.  
  432.  
  433. Expires: September 1997                                         [Page 7]
  434.  
  435. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  436.  
  437.  
  438.    this document, can make use of them.
  439.  
  440. 5.2.2.  Context Creation Requests
  441.  
  442.    The first RPC request from the client to the server initiates context
  443.    creation.  Within the RPC message protocol's call_body structure,
  444.    rpcvers is set to 2. prog and vers are always those for the service
  445.    being accessed.  The proc is always set to NULLPROC (zero).
  446.  
  447.    Within the RPC message protocol's cred structure, flavor is set to
  448.    RPCSEC_GSS (6).  The opaque data of the cred structure (the body
  449.    field) constituting the credential encodes the rpc_gss_cred_t
  450.    structure defined previously.
  451.  
  452.    The values of the fields contained in the rpc_gss_cred_t structure
  453.    are set as follows.  The version field is set to the version of the
  454.    RPCSEC_GSS protocol the client wants to use.  The remainder of this
  455.    memo documents version RPCSEC_GSS_VERS_1 of RPCSEC_GSS, and so the
  456.    version field would be set to RPCSEC_GSS_VERS_1.  The gss_proc field
  457.    must be set to RPCSEC_GSS_INIT for the first creation request.  In
  458.    subsequent creation requests, the gss_proc field must be set to
  459.    RPCSEC_GSS_CONTINUE_INIT.  In a creation request, the seq_num and
  460.    service fields are undefined and both must be ignored by the server.
  461.    In the first creation request, the handle field is NULL (opaque data
  462.    of zero length).  In subsequent creation requests, handle must be
  463.    equal to the value returned by the server.  The handle field serves
  464.    as the identifier for the context, and will not change for the
  465.    duration of the context, including responses to
  466.    RPCSEC_GSS_CONTINUE_INIT.
  467.  
  468.    The verifier field in the RPC message header is also described by the
  469.    opaque_auth structure.  All creation requests have the NULL verifier
  470.    (AUTH_NONE flavor with zero length opaque data).
  471.  
  472.    Following the verifier are the call data (procedure specific
  473.    parameters).  Note that the proc field of the call_body structure is
  474.    set to NULLPROC, and thus normally there would be zero octets
  475.    following the verifier.  However, since there is no RPC data exchange
  476.    during a context creation, it is safe to transfer information
  477.    following the verifier.  It is necessary to "overload" the call data
  478.    in this way, rather than pack the GSS-API token into the RPC header,
  479.    because RPC Version 2 restricts the amount of data that can be sent
  480.    in the header.  The opaque body of the credential and verifier fields
  481.    can be each at most 400 octets long, and GSS tokens can be longer
  482.    than 800 octets.
  483.  
  484.    The call data for a context creation request is described by the
  485.    following structure for all creation requests:
  486.  
  487.       struct rpc_gss_init_arg {
  488.           opaque gss_token<>;
  489.       };
  490.  
  491.    Here, gss_token is the token returned by the call to  GSS-API's
  492.  
  493.  
  494.  
  495. Expires: September 1997                                         [Page 8]
  496.  
  497. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  498.  
  499.  
  500.    GSS_Init_sec_context() routine, opaquely encoded.  The value of this
  501.    field will likely be different in each creation request, if there is
  502.    more than one creation request.  If no token is returned by the call
  503.    to GSS_Init_sec_context(), the context must have been created
  504.    (assuming no errors), and there will not be any more creation
  505.    requests.
  506.  
  507.    When GSS_Init_sec_context() is called, the parameters
  508.    replay_det_req_flag and sequence_req_flag must be turned off. The
  509.    reasons for this are:
  510.  
  511.    *    ONC RPC can be used over unreliable transports and provides no
  512.         layer to reliably re-assemble messages. Thus it is possible for
  513.         gaps in message sequencing to occur, as well as out of order
  514.         messages.
  515.  
  516.    *    RPC servers can be multi-threaded, and thus the order in which
  517.         GSS-API messages are signed or wrapped can be different from the
  518.         order in which the messages are verified or unwrapped, even if
  519.         the requests are sent on reliable transports.
  520.  
  521.    *    To maximize convenience of implementation, the order in which an
  522.         ONC RPC entity will verify the header and verify/unwrap the body
  523.         of an RPC call or reply is left unspecified.
  524.  
  525.    The RPCSEC_GSS protocol provides for protection from replay attack,
  526.    yet tolerates out-of-order delivery or processing of messages and
  527.    tolerates dropped requests.
  528.  
  529. 5.2.3.  Context Creation Responses
  530.  
  531. 5.2.3.1.  Context Creation Response - Successful Acceptance
  532.  
  533.    The response to a successful creation request has an MSG_ACCEPTED
  534.    response with a status of SUCCESS.  The results field encodes result
  535.    argument that has the following structure:
  536.  
  537.       struct rpc_gss_init_res {
  538.               opaque handle<>;
  539.               unsigned int gss_major;
  540.               unsigned int gss_minor;
  541.               unsigned int seq_window;
  542.               opaque gss_token<>;
  543.       };
  544.  
  545.    Here, handle is non-NULL opaque data that serves as the context
  546.    identifier. The client must use this value in all subsequent requests
  547.    (whether control messages or otherwise).  The gss_major and gss_minor
  548.    fields contain the results of the call to GSS_Accept_sec_context()
  549.    executed by the server.  If gss_major is not one of GSS_S_COMPLETE or
  550.    GSS_S_CONTINUE_NEEDED, the context setup has failed; in this case
  551.    handle and gss_token must be set to NULL by the server.  The value of
  552.    gss_minor is dependent on the value of gss_major and the security
  553.    mechanism used.  The gss_token field contains any token returned by
  554.  
  555.  
  556.  
  557. Expires: September 1997                                         [Page 9]
  558.  
  559. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  560.  
  561.  
  562.    the GSS_Accept_sec_context() call executed by the server.  A token
  563.    may be returned for both successful values of gss_major.  If the
  564.    value is GSS_S_COMPLETE, it indicates that the server is not
  565.    expecting any more tokens, and the RPC Data Exchange phase must begin
  566.    on the subsequent request from the client. If the value is
  567.    GSS_S_CONTINUE_NEEDED, the server is expecting another token.  Hence
  568.    the client must send at least one more creation request (with
  569.    gss_proc set to RPCSEC_GSS_CONTINUE_INIT in the request's credential)
  570.    carrying the required token.
  571.  
  572.    In a successful response, the seq_window field is set to the sequence
  573.    window length supported by the server for this context.  This window
  574.    specifies the maximum number of client requests that may be
  575.    outstanding for this context. The server will accept "seq_window"
  576.    requests at a time, and these may be out of order.  The client may
  577.    use this number to determine the number of threads that can
  578.    simultaneously send requests on this context.
  579.  
  580.    If gss_major is GSS_S_COMPLETE, the verifier's (the verf element in
  581.    the response) flavor field to to RPCSEC_GSS, and the body field set
  582.    to the checksum of the seq_window (in network order). The QOP used
  583.    for this checksum is 0 (zero), which is the default QOP.  For all
  584.    other values of gss_major, a NULL verifier (AUTH_NONE flavor with
  585.    zero-length opaque data) is used.
  586.  
  587. 5.2.3.1.1.  Client Processing of Successful Context Creation Responses
  588.  
  589.    If the value of gss_major in the response is GSS_S_CONTINUE_NEEDED,
  590.    then the client, per the GSS-API specification, must invoke
  591.    GSS_Init_sec_context() using the token returned in gss_token in the
  592.    context creation response. The client must then generate a context
  593.    creation request, with gss_proc set to RPCSEC_GSS_CONTINUE_INIT.
  594.  
  595.    If the value of gss_major in the response is GSS_S_COMPLETE, and if
  596.    the client's previous invocation of GSS_Init_sec_context() returned a
  597.    gss_major value of GSS_S_CONTINUE_NEEDED, then the client, per the
  598.    GSS-API specification, must invoke GSS_Init_sec_context() using the
  599.    token returned in gss_token in the context creation response. If
  600.    GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is
  601.    successfully set up, and the RPC data exchange phase must begin on
  602.    the subsequent request from the client.
  603.  
  604. 5.2.3.2.  Context Creation Response - Unsuccessful Cases
  605.  
  606.    An MSG_ACCEPTED reply (to a creation request) with an acceptance
  607.    status of other than SUCCESS has a NULL verifier (flavor set to
  608.    AUTH_NONE, and zero length opaque data in the body field), and is
  609.    formulated as usual for different status values.
  610.  
  611.    An MSG_DENIED reply (to a creation request) is also formulated as
  612.    usual.  Note that MSG_DENIED could be returned because the server's
  613.    RPC implementation does not recognize the RPCSEC_GSS security flavor.
  614.    RFC 1831 does not specify the appropriate reply status in this
  615.    instance.  Solaris 2 implementations return a rejection status of
  616.  
  617.  
  618.  
  619. Expires: September 1997                                        [Page 10]
  620.  
  621. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  622.  
  623.  
  624.    AUTH_ERROR with an auth_stat of AUTH_REJECTEDCRED. Even though two
  625.    new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have
  626.    been defined for the auth_stat type, neither of these two can be
  627.    returned in responses to context creation requests.  The new values
  628.    are relevant to for responses to normal (data) requests.  This is
  629.    described later.
  630.  
  631.    MSG_DENIED might also be returned if the RPCSEC_GSS version number in
  632.    the credential is not supported on the server. In that case, the
  633.    server returns a rejection status of AUTH_ERROR, with an auth_stat of
  634.    AUTH_REJECTED_CRED.
  635.  
  636. 5.3.  RPC Data Exchange
  637.  
  638.    The data exchange phase is entered after a context has been
  639.    successfully set up. The format of the data exchanged depends on the
  640.    security service used for the request.  Although clients can change
  641.    the security service and QOP used on a per-request basis, this may
  642.    not be acceptable to all RPC services; some RPC services may "lock"
  643.    the data exchange phase into using the the QOP and service used on
  644.    the first data exchange message.  For all three modes of service (no
  645.    data integrity, data integrity, data privacy), the RPC request header
  646.    has the same format.
  647.  
  648. 5.3.1.  RPC Request Header
  649.  
  650.    The credential has the opaque_auth structure described earlier.  The
  651.    flavor field is set to RPCSEC_GSS.  The credential body is created by
  652.    XDR encoding the rpc_gss_cred_t structure listed earlier into an
  653.    octet stream, and then opaquely encoding this octet stream as the
  654.    body field.
  655.  
  656.    Values of the fields contained in the rpc_gss_cred_t structure are
  657.    set as follows.  The version field is set to same version value that
  658.    was used to create the context, which within the scope of this memo
  659.    will always be RPCSEC_GSS_VERS_1.  The gss_proc field is set to
  660.    RPCSEC_GSS_DATA.  The service field is set to indicate the desired
  661.    service (one of rpc_gss_svc_none, rpc_gss_svc_integrity, or
  662.    rpc_gss_svc_privacy).  The handle field is set to the context handle
  663.    value received from the RPC server during context creation.  The
  664.    seq_num field can start at any value below MAXSEQ, and must be
  665.    incremented (by one or more) for successive requests.  Use of
  666.    sequence numbers is described in detail when server processing of the
  667.    request is discussed.
  668.  
  669.    The verifier has the opaque_auth structure described earlier.  The
  670.    flavor field is set to RPCSEC_GSS.  The body field is set as follows.
  671.    The checksum of the RPC header (up to and including the credential)
  672.    is computed using the GSS_GetMIC() call with the desired QOP.  This
  673.    returns the checksum as an opaque octet stream and its length.  This
  674.    is encoded into the body field.  Note that the QOP is not explicitly
  675.    specified anywhere in the request.  It is implicit in the checksum or
  676.    encrypted data.  The same QOP value as is used for the header
  677.    checksum must also be used for the data (for checksumming or
  678.  
  679.  
  680.  
  681. Expires: September 1997                                        [Page 11]
  682.  
  683. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  684.  
  685.  
  686.    encrypting), unless the service used for the request is
  687.    rpc_gss_svc_none.
  688.  
  689. 5.3.2.  RPC Request Data
  690.  
  691. 5.3.2.1.  RPC Request Data - No Data Integrity
  692.  
  693.    If the service specified is rpc_gss_svc_none, the data (procedure
  694.    arguments) are not integrity or privacy protected.  They are sent in
  695.    exactly the same way as they would be if the AUTH_NONE flavor were
  696.    used (following the verifier).  Note, however, that since the RPC
  697.    header is integrity protected, the sender will still be authenticated
  698.    in this case.
  699.  
  700. 5.3.2.2.  RPC Request Data - With Data Integrity
  701.  
  702.    When data integrity is used, the request data is represented as
  703.    follows:
  704.  
  705.       struct rpc_gss_integ_data {
  706.           opaque databody_integ<>;
  707.           opaque checksum<>;
  708.       };
  709.  
  710.    The databody_integ field is created as follows.  A structure
  711.    consisting of a sequence number followed by the procedure arguments
  712.    is constructed. This is shown below as the type rpc_gss_data_t:
  713.  
  714.  
  715.       struct rpc_gss_data_t {
  716.           unsigned int seq_num;
  717.           proc_req_arg_t arg;
  718.       };
  719.  
  720.    Here, seq_num must have the same value as in the credential.  The
  721.    type proc_req_arg_t is the procedure specific XDR type describing the
  722.    procedure arguments (and so is not specified here).  The octet stream
  723.    corresponding to the XDR encoded rpc_gss_data_t structure and its
  724.    length are placed in the databody_integ field. Note that because the
  725.    XDR type of databody_integ is opaque, the XDR encoding of
  726.    databody_integ will include an initial four octet length field,
  727.    followed by the XDR encoded octet stream of rpc_gss_data_t.
  728.  
  729.    The checksum field represents the checksum of the XDR encoded octet
  730.    stream corresponding to the XDR encoded rpc_gss_data_t structure
  731.    (note, this is not the checksum of the databody_integ field).  This
  732.    is obtained using the GSS_GetMIC() call, with the same QOP as was
  733.    used to compute the header checksum (in the verifier). The
  734.    GSS_GetMIC() call returns the checksum as an opaque octet stream and
  735.    its length. The checksum field of struct rpc_gss_integ_data has an
  736.    XDR type of opaque. Thus the checksum length from GSS_GetMIC() is
  737.    encoded as a four octet  length field, followed by the checksum,
  738.    padded to a multiple of four octets.
  739.  
  740.  
  741.  
  742.  
  743. Expires: September 1997                                        [Page 12]
  744.  
  745. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  746.  
  747.  
  748. 5.3.2.3.  RPC Request Data - With Data Privacy
  749.  
  750.    When data privacy is used, the request data is represented as
  751.    follows:
  752.  
  753.       struct rpc_gss_priv_data {
  754.           opaque databody_priv<>
  755.       };
  756.  
  757.    The databody_priv field is created as follows.  The rpc_gss_data_t
  758.    structure described earlier is constructed again in the same way as
  759.    for the case of data integrity.  Next, the GSS_Wrap() call is invoked
  760.    to encrypt the octet stream corresponding to the rpc_gss_data_t
  761.    structure, using the same value for QOP (argument qop_req to
  762.    GSS_Wrap()) as was used for the header checksum (in the verifier) and
  763.    conf_req_flag (an argument to GSS_Wrap()) of TRUE.  The GSS_Wrap()
  764.    call returns an opaque octet stream (representing the encrypted
  765.    rpc_gss_data_t structure) and its length, and this is encoded as the
  766.    databody_priv field. Since databody_priv has an XDR type of opaque,
  767.    the length returned by GSS_Wrap() is encoded as the four octet
  768.    length, followed by the encrypted octet stream (padded to a multiple
  769.    of four octets).
  770.  
  771. 5.3.3.  Server Processing of RPC Data Requests
  772.  
  773. 5.3.3.1.  Context Management
  774.  
  775.    When a request is received by the server, the following are verified
  776.    to be acceptable:
  777.  
  778.    *    the version number in the credential
  779.  
  780.    *    the service specified in the credential
  781.  
  782.    *    the context handle specified in the credential
  783.  
  784.    *    the header checksum in the verifier (via GSS_VerifyMIC())
  785.  
  786.    *    the sequence number (seq_num) specified in the credential (more
  787.         on this follows)
  788.  
  789.    The gss_proc field in the credential must be set to RPCSEC_GSS_DATA
  790.    for data requests (otherwise, the message will be interpreted as a
  791.    control message).
  792.  
  793.    The server maintains a window of "seq_window" sequence numbers,
  794.    starting with the last sequence number seen and extending backwards.
  795.    If a sequence number higher than the last number seen is received
  796.    (AND if GSS_VerifyMIC() on the header checksum from the verifier
  797.    returns GSS_S_COMPLETE), the window is moved forward to the new
  798.    sequence number.  If the last sequence number seen is N, the server
  799.    is prepared to receive requests with sequence numbers in the range N
  800.    through (N - seq_window + 1), both inclusive.  If the sequence number
  801.    received falls below this range, it is silently discarded.  If the
  802.  
  803.  
  804.  
  805. Expires: September 1997                                        [Page 13]
  806.  
  807. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  808.  
  809.  
  810.    sequence number is within this range, and the server has not seen it,
  811.    the request is accepted, and the server turns on a bit to "remember"
  812.    that this sequence number has been seen.  If the server determines
  813.    that it has already seen a sequence number within the window, the
  814.    request is silently discarded. The server should select a seq_window
  815.    value based on the number requests it expects to process
  816.    simultaneously. For example, in a threaded implementation seq_window
  817.    might be equal to the number of server threads. There are no known
  818.    security issues with selecting a large window. The primary issue is
  819.    how much space the server is willing to allocate to keep track of
  820.    requests received within the window.
  821.  
  822.    The reason for discarding requests silently is that the server is
  823.    unable to determine if the duplicate or out of range request was due
  824.    to a sequencing problem in the client, network, or the operating
  825.    system, or due to some quirk in routing, or a replay attack by an
  826.    intruder.  Discarding the request allows the client to recover after
  827.    timing out, if indeed the duplication was unintentional or well
  828.    intended.  Note that a consequence of the silent discard is that
  829.    clients may increment the seq_num by more than one. The effect of
  830.    this is that the window will move forward more quickly. It is not
  831.    believed that there is any benefit to doing this.
  832.  
  833.    Note that the sequence number algorithm requires that the client
  834.    increment the sequence number even if it is retrying a request with
  835.    the same RPC transaction identifier.  It is not infrequent for
  836.    clients to get into a situation where they send two or more attempts
  837.    and a slow server sends the reply for the first attempt. With
  838.    RPCSEC_GSS, each request and reply will have a unique sequence
  839.    number. If the client wishes to improve turn around time on the RPC
  840.    call, it can cache the RPCSEC_GSS sequence number of each request it
  841.    sends. Then when it receives a response with a matching RPC
  842.    transaction identifier, it can compute the checksum of each sequence
  843.    number in the cache to try to match the checksum in the reply's
  844.    verifier.
  845.  
  846.    The data is decoded according to the service specified in the
  847.    credential.  In the case of integrity or privacy, the server ensures
  848.    that the QOP value is acceptable, and that it is the same as that
  849.    used for the header checksum in the verifier.  Also, in the case of
  850.    integrity or privacy, the server will reject the message (with a
  851.    reply status of MSG_ACCEPTED, and an acceptance status of
  852.    GARBAGE_ARGS) if the sequence number embedded in the request body is
  853.    different from the sequence number in the credential.
  854.  
  855. 5.3.3.2.  Server Reply - Request Accepted
  856.  
  857.    An MSG_ACCEPTED reply to a request in the data exchange phase will
  858.    have the verifier's (the verf element in the response) flavor field
  859.    set to RPCSEC_GSS, and the body field set to the checksum (the output
  860.    of GSS_GetMIC()) of the sequence number (in network order) of the
  861.    corresponding request.  The QOP used is the same as the QOP used for
  862.    the corresponding request.
  863.  
  864.  
  865.  
  866.  
  867. Expires: September 1997                                        [Page 14]
  868.  
  869. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  870.  
  871.  
  872.    If the status of the reply is not SUCCESS, the rest of the message is
  873.    formatted as usual.
  874.  
  875.    If the status of the message is SUCCESS, the format of the rest of
  876.    the message depends on the service specified in the corresponding
  877.    request message. Basically, what follows the verifier in this case
  878.    are the procedure results, formatted in different ways depending on
  879.    the requested service.
  880.  
  881.    If no data integrity was requested, the procedure results are
  882.    formatted as for the AUTH_NONE security flavor.
  883.  
  884.    If data integrity was requested, the results are encoded in exactly
  885.    the same way as the procedure arguments were in the corresponding
  886.    request.  See the section 'RPC Request Data - With Data Integrity.'
  887.    The only difference is that the structure representing the
  888.    procedure's result - proc_res_arg_t - must be substituted in place of
  889.    the request argument structure proc_req_arg_t.  The QOP used for the
  890.    checksum must be the same as that used for constructing the reply
  891.    verifier.
  892.  
  893.    If data privacy was requested, the results are encoded in exactly the
  894.    same way as the procedure arguments were in the corresponding
  895.    request.  See the section 'RPC Request Data - With Data Privacy.'
  896.    The QOP used for  encryption must be the same as that used for
  897.    constructing the reply verifier.
  898.  
  899. 5.3.3.3.  Server Reply - Request Denied
  900.  
  901.    An MSG_DENIED reply (to a data request) is formulated as usual.  Two
  902.    new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have
  903.    been defined for the auth_stat type.  When the reason for denial of
  904.    the request is a reject_stat of AUTH_ERROR, one of the two new
  905.    auth_stat values could be returned in addition to the existing
  906.    values.  These two new values have special significance from the
  907.    existing reasons for denial of a request.
  908.  
  909.    The server maintains a list of contexts for the clients that are
  910.    currently in session with it.  Normally, a context is destroyed when
  911.    the client ends the session corresponding to it.  However, due to
  912.    resource constraints, the server may destroy a context prematurely
  913.    (on an LRU basis, or if the server machine is rebooted, for example).
  914.    In this case, when a client request comes in, there may not be a
  915.    context corresponding to its handle. The server rejects the request,
  916.    with the reason RPCSEC_GSS_CREDPROBLEM in this case.  Upon receiving
  917.    this error, the client must refresh the context - that is,
  918.    reestablish it after destroying the old one - and try the request
  919.    again.  This error is also returned if the context handle matches
  920.    that of a different context that was allocated after the client's
  921.    context was destroyed (this will be detected by a failure in
  922.    verifying the header checksum).
  923.  
  924.    If the GSS_VerifyMIC() call in the verifier (the header checksum)
  925.    fails to return GSS_S_COMPLETE, the server rejects the requests and
  926.  
  927.  
  928.  
  929. Expires: September 1997                                        [Page 15]
  930.  
  931. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  932.  
  933.  
  934.    returns an auth_stat of RPCSEC_GSS_CREDPROBLEM.
  935.  
  936.    When the client's sequence number exceeds the maximum the server will
  937.    allow, the server will reject the request with the reason
  938.    RPCSEC_GSS_CTXPROBLEM.  Also, if security credentials become stale
  939.    while in use (due to ticket expiry in the case of the Kerberos V5
  940.    mechanism, for example), the failures which result cause the
  941.    RPCSEC_GSS_CTXPROBLEM reason to be returned.  In these cases also,
  942.    the client must refresh the context, and retry the request.
  943.  
  944.    For other errors, retrying will not rectify the problem and the
  945.    client must not refresh the context until the problem causing the
  946.    client request to be denied is rectified.
  947.  
  948.    If the version field in the credential does not match the version of
  949.    RPCSEC_GSS that was used when the context was created, the
  950.    AUTH_BADCRED value is returned.
  951.  
  952.    If there is a problem with the credential, such a bad length, illegal
  953.    control procedure, or an illegal service, the appropriate auth_stat
  954.    status is AUTH_BADCRED.
  955.  
  956.    Other errors can be returned as appropriate.
  957.  
  958. 5.3.3.4.  Mapping of GSS-API Errors to Server Responses
  959.  
  960.    During the data exchange phase, the server may invoke GSS_GetMIC(),
  961.    GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of these
  962.    routines fail to return GSS_S_COMPLETE, then various unsuccessful
  963.    responses can be returned. The are described as follows for each of
  964.    the aforementioned four interfaces.
  965.  
  966. 5.3.3.4.1.  GSS_GetMIC() Failure
  967.  
  968.    When GSS_GetMIC() is called to generate the verifier in the response,
  969.    a failure results in an RPC response with a reply status of
  970.    MSG_DENIED, reject status of AUTH_ERROR and an auth status of
  971.    RPCSEC_GSS_CTXPROBLEM.
  972.  
  973.    When GSS_GetMIC() is called to sign the call results (service is
  974.    rpc_gss_svc_integrity), a failure results in no RPC response being
  975.    sent. Since ONC RPC server applications will typically control when a
  976.    response is sent, the failure indication will be returned to the
  977.    server application and it can take appropriate action (such as
  978.    logging the error).
  979.  
  980. 5.3.3.4.2.  GSS_VerifyMIC() Failure
  981.  
  982.    When GSS_VerifyMIC() is called to verify the verifier in request, a
  983.    failure results in an RPC response with a reply status of MSG_DENIED,
  984.    reject status of AUTH_ERROR and an auth status of
  985.    RPCSEC_GSS_CREDPROBLEM.
  986.  
  987.    When GSS_VerifyMIC() is called to verify the call arguments (service
  988.  
  989.  
  990.  
  991. Expires: September 1997                                        [Page 16]
  992.  
  993. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  994.  
  995.  
  996.    is rpc_gss_svc_integrity), a failure results in an RPC response with
  997.    a reply status of MSG_ACCEPTED, and an acceptance status of
  998.    GARBAGE_ARGS.
  999.  
  1000. 5.3.3.4.3.  GSS_Unwrap() Failure
  1001.  
  1002.    When GSS_Unwrap() is called to decrypt the call arguments (service is
  1003.    rpc_gss_svc_privacy), a failure results in an RPC response with a
  1004.    reply status of MSG_ACCEPTED, and an acceptance status of
  1005.    GARBAGE_ARGS.
  1006.  
  1007. 5.3.3.4.4.  GSS_Wrap() Failure
  1008.  
  1009.    When GSS_Wrap() is called to encrypt the call results (service is
  1010.    rpc_gss_svc_privacy), a failure results in no RPC response being
  1011.    sent. Since ONC RPC server applications will typically control when a
  1012.    response is sent, the failure indication will be returned to the
  1013.    application and it can take appropriate action (such as logging the
  1014.    error).
  1015.  
  1016. 5.4.  Context Destruction
  1017.  
  1018.    When the client is done using the session, it must send a control
  1019.    message informing the server that it no longer requires the context.
  1020.    This message is formulated just like a data request packet, with the
  1021.    following differences:  the credential has gss_proc set to
  1022.    RPCSEC_GSS_DESTROY, the procedure specified in the header is
  1023.    NULLPROC, and there are no procedure arguments.  The sequence number
  1024.    in the request must be valid, and the header checksum in the verifier
  1025.    must be valid, for the server to accept the message.
  1026.  
  1027.    The server sends a response as it would to a data request.  The
  1028.    client and server must then destroy the context for the session.
  1029.  
  1030.    If the request to destroy the context fails for some reason, the
  1031.    client need not take any special action.  The server must be prepared
  1032.    to deal with situations where clients never inform the server that
  1033.    they no longer are in session and so don't need the server to
  1034.    maintain a context.  An LRU mechanism or an aging mechanism should be
  1035.    employed by the server to clean up in such cases.
  1036.  
  1037. 6.  Set of GSS-API Mechanisms
  1038.  
  1039.    RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and
  1040.    as such it is inappropriate for the RPCSEC_GSS specification to
  1041.    enumerate a minimum set of required security mechanisms and/or
  1042.    quality of protections.
  1043.  
  1044.    If an application protocol specification references RPCSEC_GSS, the
  1045.    protocol specification must list a mandatory set of
  1046.    { mechanism, QOP, service } triples, such that an implementation
  1047.    cannot claim conformance to the protocol specification unless it
  1048.    implements the set of triples. Within each triple, mechanism is a
  1049.    GSS-API security mechanism, QOP is a valid quality-of-protection
  1050.  
  1051.  
  1052.  
  1053. Expires: September 1997                                        [Page 17]
  1054.  
  1055. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  1056.  
  1057.  
  1058.    within the mechanism, and service is either rpc_gss_svc_integrity or
  1059.    rpc_gss_svc_privacy.
  1060.  
  1061.    For example, a network filing protocol built on RPC that depends on
  1062.    RPCSEC_GSS for security, might require that Kerberos V5 with the
  1063.    default QOP using the rpc_gss_svc_integrity service be supported by
  1064.    implementations conforming to the network filing protocol
  1065.    specification.
  1066.  
  1067. 7.  Security Considerations
  1068.  
  1069. 7.1.  Privacy of Call Header
  1070.  
  1071.    The reader will note that for the privacy option, only the call
  1072.    arguments and results are encrypted. Information about the
  1073.    application in the form of RPC program number, program version
  1074.    number, and program procedure number is transmitted in the clear.
  1075.    Encrypting these fields in the RPC call header would have changed the
  1076.    size and format of the call header. This would have required revising
  1077.    the RPC protocol which was beyond the scope of this proposal. Storing
  1078.    the encrypted numbers in the credential would have obviated a
  1079.    protocol change, but would have introduced more overloading of fields
  1080.    and would have made implementations of RPC more complex. Even if the
  1081.    fields were encrypted somehow, in most cases an attacker can
  1082.    determine the program number and version number by examining the
  1083.    destination address of the request and querying the rpcbind service
  1084.    on the destination host [Srinivasan-bind].  In any case, even by not
  1085.    encrypting the three numbers, RPCSEC_GSS still improves the state of
  1086.    security over what existing RPC services have had available
  1087.    previously. Implementors of new RPC services that are concerned about
  1088.    this risk may opt to design in a "sub-procedure" field that is
  1089.    included in the service specific call arguments.
  1090.  
  1091. 7.2.  Sequence Number Attacks
  1092.  
  1093. 7.2.1.  Sequence Numbers Above the Window
  1094.  
  1095.    An attacker cannot coax the server into raising the sequence number
  1096.    beyond the range the legitimate client is aware of (and thus engineer
  1097.    a denial of server attack) without constructing an RPC request that
  1098.    will pass the header checksum. If the cost of verifying the header
  1099.    checksum is sufficiently large (depending on the speed of the
  1100.    processor doing the checksum and the cost of checksum algorithm), it
  1101.    is possible to envision a denial of service attack (vandalism, in the
  1102.    form of wasting processing resources) whereby the attacker sends
  1103.    requests that are above the window. The simplest method might be for
  1104.    the attacker to monitor the network traffic and then choose a
  1105.    sequence number that is far above the current sequence number. Then
  1106.    the attacker can send bogus requests using the above window sequence
  1107.    number.
  1108.  
  1109. 7.2.2.  Sequence Numbers Within or Below the Window
  1110.  
  1111.    If the attacker sends requests that within or below the window, then
  1112.  
  1113.  
  1114.  
  1115. Expires: September 1997                                        [Page 18]
  1116.  
  1117. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  1118.  
  1119.  
  1120.    even if the header checksum is successfully verified, the server will
  1121.    silently discard the requests because the server assumes it has
  1122.    already processed the request. In this case, a server can optimize by
  1123.    skipping the header checksum verification if the sequence number is
  1124.    below the window, or if it is within the window, do not attempt the
  1125.    checksum verification if the sequence number has already been seen.
  1126.  
  1127. 7.3.  Message Stealing Attacks
  1128.  
  1129.    This proposal does not address attacks where an attacker can block or
  1130.    steal messages without being detected by the server. To implement
  1131.    such protection would be tantamount to assuming a state in the RPC
  1132.    service. RPCSEC_GSS does not worsen this situation.
  1133.  
  1134. 8.  Acknowledgements
  1135.  
  1136.    Much of protocol was based on the AUTH_GSSAPI security flavor
  1137.    developed by Open Vision Technologies [Jaspan].  In particular, we
  1138.    acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen
  1139.    McDermott.
  1140.  
  1141.    Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike
  1142.    Eisler.  Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to
  1143.    SunSoft's implementation of RPCSEC_GSS.
  1144.  
  1145.    Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie
  1146.    Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the
  1147.    specification and gave valuable feedback.
  1148.  
  1149.    Steve Nahm and Kathy Slattery reviewed various drafts of this
  1150.    specification.
  1151.  
  1152. 9.  References
  1153.  
  1154.  
  1155. [Baize]             Baize, E., and Pinkas, D.  (1996).
  1156.                     draft-ietf-cat-snego-02.txt "Simple GSS-API
  1157.                     Negotiation Mechanism," This is a work in progress
  1158.                     which may be updated, replaced, or obsoleted at any
  1159.                     time.
  1160.  
  1161. [Eisler]            Eisler, M., Schemers, R., and Srinivasan, R. (1996).
  1162.                     "Security Mechanism Independence in ONC RPC," To be
  1163.                     published in the Proceedings of 1996 Usenix Security
  1164.                     Symposium.
  1165.  
  1166. [Jaspan]            Jaspan, B. (1995). "GSS-API Security for ONC RPC,"
  1167.                     `95 Proceedings of The Internet Society Symposium on
  1168.                     Network and Distributed System Security, pp. 144-
  1169.                     151.
  1170.  
  1171. [Linn]              Linn, J. (1997). RFC 2078, "Generic Security Service
  1172.                     Application Program Interface, Version 2."
  1173.  
  1174.  
  1175.  
  1176.  
  1177. Expires: September 1997                                        [Page 19]
  1178.  
  1179. Internet Draft     RPCSEC_GSS Protocol Specification          March 1997
  1180.  
  1181.  
  1182. [Srinivasan-bind]   Srinivasan, R. (1995). RFC 1833, "Binding Protocols
  1183.                     for ONC RPC Version 2."
  1184.  
  1185. [Srinivasan-rpc]    Srinivasan, R. (1995). RFC 1831, "RPC: Remote
  1186.                     Procedure Call Protocol Specification Version 2."
  1187.  
  1188. [Srinivasan-xdr]    Srinivasan, R. (1995). RFC 1832, "XDR: External Data
  1189.                     Representation Standard."
  1190.  
  1191.  
  1192. 10.  Authors' Addresses
  1193.  
  1194.    Michael Eisler
  1195.    Sun Microsystems, Inc.
  1196.    M/S UCOS03
  1197.    2550 Garcia Avenue
  1198.    Mountain View, CA 94043
  1199.  
  1200.    Phone: +1 (719) 599-9026
  1201.  
  1202.    E-mail: mre@eng.sun.com
  1203.  
  1204.    Alex Chiu
  1205.    Sun Microsystems, Inc.
  1206.    M/S UMPK17-203
  1207.    2550 Garcia Avenue
  1208.    Mountain View, CA 94043
  1209.  
  1210.    Phone: +1 (415) 786-6465
  1211.  
  1212.    E-mail: hacker@eng.sun.com
  1213.  
  1214.    Lin Ling
  1215.    Sun Microsystems, Inc.
  1216.    M/S UMPK17-201
  1217.    2550 Garcia Avenue
  1218.    Mountain View, CA 94043
  1219.  
  1220.    Phone: +1 (415) 786-5084
  1221.  
  1222.    E-mail: lling@eng.sun.com
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234.  
  1235.  
  1236.  
  1237.  
  1238.  
  1239. Expires: September 1997                                        [Page 20]
  1240.  
  1241.