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