NFSv4                                                          M. Eisler
Internet-Draft                                                    NetApp
Intended status: Standards Track                       February 24,                            May 23, 2008
Expires: August 27, November 24, 2008

                          RPCSEC_GSS Version 2
                 draft-ietf-nfsv4-rpcsec-gss-v2-02.txt
                 draft-ietf-nfsv4-rpcsec-gss-v2-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 27, November 24, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This Internet-Draft describes version 2 of the RPCSEC_GSS protocol.
   Version 2 is the same as Version 1 but adds support for channel
   bindings.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].

Table of Contents

   1.  Introduction and Motivation  . . . . . . . . . . . . . . . . . .  3
   2.  Channel Bindings Explained . . . . . . . . . . . . . . . . . .  3
   3.  The RPCSEC_GSSv2 Protocol  . . . . . . . . . . . . . . . . . . .  4
     3.1.  Compatibility with RPCSEC_GSSv1  . . . . . . . . . . . . . .  4
     3.2.  New Version Number . . . . . . . . . . . . . . . . . . . . 4  5
     3.3.  New Procedure - RPCSEC_GSS_BIND_CHANNEL  . . . . . . . . . . 5  6
     3.4.  New Security Service - rpc_gss_svc_channel_prot  . . . . . . 6  9
   4.  Version Negotiation  . . . . . . . . . . . . . . . . . . . . . . 6  9
   5.  Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . . 7 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . . 7 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 7 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 8 11

1.  Introduction and Motivation

   RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version
   1 (RPCSEC_GSSv1) except that support for channel bindings has been
   added.  The primary motivation for channel bindings is to securely
   take advantage of hardware assisted encryption that might exist at
   lower levels of the networking protocol stack, such as at the
   Internet Protocol (IP) layer in the form of IPsec.  The secondary
   motivation is that even if lower levels are not any more efficient at
   encryption than the RPCSEC_GSS layer, if encryption is occurring at
   the lower level, it can be redundant at the RPCSEC_GSS level.

   Once an RPCSEC_GSS target and initiator are mutually assured that
   they are each using the same secure, end to end channel, the overhead
   of computing message integrity codes (MICs) for authenticating and
   integrity protecting RPC requests and replies can be eliminated
   because the channel is performing the same function.  Similarly, if
   the channel also provides confidentiality, the overhead of RPCSEC_GSS
   privacy protect protection can also be eliminated.

   The XDR description is provided in this document in a way that makes
   it simple for the reader to extract into ready to compile form.  The
   reader can feed this document into the following shell script to
   produce the machine readable XDR description of NFSv4.1:

   #!/bin/sh
   grep "^  *///" | sed 's?^  *///??'

   I.e. if the above script is stored in a file called "extract.sh", and
   this docum ent is in a file called "spec.txt", then the reader can
   do:

    sh extract.sh < spec.txt > rpcsec_gss_v2.x

   The effect of the script is to remove leading white space from each
   line of the specification, plus a sentinel sequence of "///".

2.  Channel Bindings Explained

   If a channel between two parties is secure, there must be shared
   information between the two parties.  This information might be
   secret or not.  The requirement for secrecy depends on the specifics
   of the channel.

   For example, the shared information could be the concatenation of the
   public key of the source and destination of the channel (where each
   public key has a corresponding private key).  Suppose the channel is
   not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are
   two channels, one from the initiator to the MITM, and one from the
   MITM to the target.  The MITM cannot simply force each channel to use
   the same public keys, because the a public keys come key derives from a private keys,
   key, and the key management system for each node will surely assign
   unique or random private keys.  At most most, the MITM can force one end
   of each channel to use the same public key.  The MIC of the public
   keys from the initiator will not be verified by the target, because
   at least one of the public keys will be different.  Similarly, the
   MIC of the public keys from the target will not be verified by the
   initiator because at least one of the public keys will be different.

   A higher layer protocol using the secure channel can safely exploit
   the channel to the mutual benefit of the higher level parties if each
   higher level party can prove:

   o  They each know the channel's shared information.

   o  The proof of the knowledge of the shared information is in fact
      being conveyed by each of the higher level parties, and not some
      other entities.

   RPCSEC_GSSv2 simply adds an optional round trip that has the
   initiator compute a GSS MIC on the channel binding's shared
   information, and sends the MIC to the target.  The target verifies
   the MIC, and in turn sends its own MIC of the shared information to
   the initiator which verifies the target's MIC.  This accomplishes
   three things.  First the initiator and target are mutually
   authenticated.  Second, the initiator and target prove they know the
   channel's shared information, and thus are using the same channel.
   Third, the first and second things are done simultaneously.

3.  The RPCSEC_GSSv2 Protocol

   The RPCSEC_GSSv2 protocol will now be explained.  The entire protocol
   is not presented.  Instead the differences between RPCSEC_GSSv2 and
   RPCSEC_GSSv1 are shown.

3.1.  Compatibility with RPCSEC_GSSv1

   The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2.

3.2.  New Version Number

   const RPCSEC_GSS_VERS_1

   ///  enum rpc_gss_service_t {
   ///    /* Note: the enumerated value for 0 is reserved. */
   ///    rpc_gss_svc_none         = 1;
   const RPCSEC_GSS_VERS_2 1,
   ///    rpc_gss_svc_integrity    = 2; 2,
   ///    rpc_gss_svc_privacy      = 3,
   ///    rpc_gss_svc_channel_prot = 4 /* new */

         struct rpc_gss_cred_t {
             union switch (unsigned int version)
   ///  };
   ///
   ///   enum rpc_gss_proc_t { /* version of
                                                         RPCSEC_GSS */
             case RPCSEC_GSS_VERS_1:
             case RPCSEC_GSS_VERS_2:
   ///     RPCSEC_GSS_DATA          = 0,
   ///     RPCSEC_GSS_INIT          = 1,
   ///     RPCSEC_GSS_CONTINUE_INIT = 2,
   ///     RPCSEC_GSS_DESTROY       = 3,
   ///     RPCSEC_GSS_BIND_CHANNEL  = 4 /* new */
   ///  };
   ///
   ///  struct rpc_gss_cred_vers_1_t {
   ///    rpc_gss_proc_t    gss_proc; /* control procedure */
   ///    unsigned int      seq_num;  /* sequence number */
   ///    rpc_gss_service_t service;  /* service used */
   ///    opaque            handle<>; /* context handle */
                 } rpc_gss_cred_vers_1_t;
   ///  };
   ///
   ///  const RPCSEC_GSS_VERS_1 = 1;
   ///  const RPCSEC_GSS_VERS_2 = 2; /* new */
   ///
   ///  union rpc_gss_cred_t switch (unsigned int rgc_version) {
   ///    case RPCSEC_GSS_VERS_1:
   ///    case RPCSEC_GSS_VERS_2: /* new */
   ///      rpc_gss_cred_vers_1_t rgc_cred_v1;
   ///  };
   ///

                                 Figure 3

   As is apparent from the above, the RPCSEC_GSSv2 credential has the
   same format as the RPCSSEC_GSSv1 credential. RPCSEC_GSSv1 credential (albeit corrected so that
   the definition is in legal XDR description language that is also
   compatible with [6].  Hence the field "version", a keyword in [6], is
   replaced with rgc_version).  By setting the version rgc_version field to 2,
   this indicates that the initiator and target support channel
   bindings.

3.3.  New Procedure - RPCSEC_GSS_BIND_CHANNEL

           enum rpc_gss_proc_t

   ///  struct rgss2_bind_chan_MIC_in_args {
                   RPCSEC_GSS_DATA = 0,
                   RPCSEC_GSS_INIT = 1,
                   RPCSEC_GSS_CONTINUE_INIT = 2,
                   RPCSEC_GSS_DESTROY = 3,
                   RPCSEC_GSS_BIND_CHANNEL = 4 /* new */
   ///    opaque          rbcmia_bind_chan_hash<>;
   ///  };
   ///
   ///  typedef opaque    rgss2_chan_pref<>;
   ///  typedef opaque    rgss2_oid<>;
   ///
   ///  struct rpc_gss_chan_bind_input rgss2_bind_chan_verf_args {
   ///    rgss2_chan_pref rbcva_chan_bind_prefix;
   ///    rgss2_oid       rbcva_chan_bind_oid_hash;
   ///    opaque          rgcbi_chan_bindings<>;          rbcva_chan_mic<>;
   ///  };
   ///

                                 Figure 4

   Once an RPCSEC_GSSv2 handle has been established over a secure
   channel, the client initiator MAY issue RPCSEC_GSS_BIND_CHANNEL. RPCSEC_GSS_BIND_CHANNEL (Figure 3).
   Targets MUST support RPCSEC_GSS_BIND_CHANNEL.  Like RPCSEC_GSS_INIT
   and RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be
   used.  Unlike those two requests, the arguments of the NULL procedure
   are not overloaded, because the verifier is of sufficient size for
   the purpose of RPCSEC_GSS_BIND_CHANNEL.  The gss_proc field is set to
   RPCSEC_GSS_BIND_CHANNEL.  The seq_num field is set as if gss_proc
   were set to RPCSEC_GSS_DATA.  The service field is set to
   rpc_gss_svc_none.  The handle field is set to that of an RPCSEC_GSS
   handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.

   When

   As described in Section 5.3.1 of [2] when gss_proc is
   RPCSEC_GSS_DATA, the verifier of an RPC request is set to the output
   of GSS_GetMIC() on the RPC header as described in
   Section 5.3.1 of [2]. header.  When gss_proc is
   RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC request is set to the
   XDR encoding on a value of data type rgss2_bind_chan_verf_args.  The
   rgss2_bind_chan_verf_args data type consists of three fields:

   o  rbcva_chan_bind_prefix.  This is the channel binding prefix as
      described in [3] up to, but excluding the colon (ASCII 0x3A) that
      separates the prefix from the suffix.

   o  rbcva_chan_bind_hash_oid.  This is the object identifier (OID) of
      the hash algorithm used to compute rbcmia_bind_chan_hash.  This
      field contains an OID encoded in ASN.1 as used by GSS-API in the
      mech_type argument to GSS_Init_sec_context ([4]).  See [5] for the
      OIDs of the SHA one-way hash algorithms.

   o  rbcva_chan_mic.  This is the output of GSS_GetMIC() on the
      concatenation of the XDR encoded RPC header ("up to and including
      the
   credential") credential" as per [2]) and the XDR encoding of an instance of
      type data
   rpc_gss_chan_bind_input.

   Similarly when rgss2_bind_chan_MIC_in_args.  The data type
      rgss2_bind_chan_MIC_in_args consists of one field,
      rbcmia_bind_chan_hash, which is a hash of the channel bindings as
      defined in [3].  The channel bindings are a "canonical octet
      string encoding of the channel bindings", starting "with the
      channel bindings prefix followed by a colon (ASCII 0x3A)."  The
      reason a hash of the channel bindings and not the actual channel
      bindings are used to compute rbcva_chan_mic is that some channel
      bindings, such as those composed of public keys, can be relatively
      large, and thus place a higher space burden on the implementations
      to manage.  One way hashes consume less space.

   ///  enum rgss2_bind_chan_status {
   ///    RGSS2_BIND_CHAN_OK           = 0,
   ///    RGSS2_BIND_CHAN_PREF_NOTSUPP = 1,
   ///    RGSS2_BIND_CHAN_HASH_NOTSUPP = 2
   ///  };
   ///
   ///  union rgss2_bind_chan_res switch
   ///     (rgss2_bind_chan_status rbcr_stat) {
   ///
   ///    case RGSS2_BIND_CHAN_OK:
   ///      void;
   ///
   ///    case RGSS2_BIND_CHAN_PREF_NOTSUPP:
   ///      rgss2_chan_pref rbcr_pref_list<>;
   ///
   ///    case RGSS2_BIND_CHAN_HASH_NOTSUPP:
   ///      rgss2_oid       rbcr_oid_list<>;
   ///  };
   ///
   ///  struct rgss2_bind_chan_MIC_in_res {
   ///    unsigned int        rbcmr_seq_num;
   ///    opaque              rbcmr_bind_chan_hash<>;
   ///    rgss2_bind_chan_res rbcmr_res;
   ///  };
   ///
   ///  struct rgss2_bind_chan_verf_res {
   ///    rgss2_bind_chan_res rbcvr_res;
   ///    opaque              rbcvr_mic<>;
   ///  };
   ///

                                 Figure 5
   When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC reply is set
   to the output of GSS_GetMIC() on the seq_num of the credential of the
   corresponding request (as described in Section 5.3.3.2 of [2]).  When
   gss_proc is RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is
   set to the ouput of GSS_GetMIC() on the
   concantenation of the seq_num and the XDR encoding of an instance of data type rpc_gss_chan_bind_input.
   rgss2_bind_chan_verf_res.  The content data type rgss2_bind_chan_verf_res
   consists of rpc_gss_chan_bind_input has a single field,
   rgcbi_chan_bindings. two fields.

   o  rbcvr_res.  The rgcbi_chan_bindings field consists data type of
   channel bindings as defined in [3]. this field is rgss2_bind_chan_res.
      The channel bindings are rgss2_bind_chan_res data type is a
   "canonical octet string encoding switched union consisting
      of three cases switched on the channel bindings", starting
   "with status contained in the rbcr_stat
      field.

      *  RGSS2_BIND_CHAN_OK.  If this status is returned, the server
         accepted the channel bindings bindings, and successfully verified
         rbcva_chan_mic in the request.  No additional results will be
         in rbcvr_res.

      *  RGSS2_BIND_CHAN_PREF_NOTSUPP.  If this status is returned, the
         server did not support the prefix followed by a colon (ASCII 0x3A)."
   Thus in the channel bindings rbcva_chan_bind_prefix
         field of the initiator are verified when arguments, and thus the
   target verifies RPCSEC_GSS_BIND_CHANNEL
         request was rejected.  The server returned a list of prefixes
         it does support in the verifier via GSS_VerifyMIC().  Similarly, field rbcr_pref_list.

      *  RGSS2_BIND_CHAN_HASH_NOTSUPP.  If this status is returned, the
   channel bindings
         server did not support the hash algorithm identified in the
         rbcva_chan_bind_hash_oid field of the target are verified when arguments, and thus the initiator
   verifies
         RPCSEC_GSS_BIND_CHANNEL request was rejected.  The server
         returned a list of OIDs of hash algorithms it does support in
         the verifier field rbcr_oid_list.

   o  rbcvr_mic.  The value of this field is equal to the RPC reply via GSS_VerifyMIC().  Errors
   are handled output of
      GSS_GetMIC() on the same XDR encoding of an instance of data type
      rgss2_bind_chan_MIC_in_res.  The data type
      rgss2_bind_chan_MIC_in_res consists of three fields.

      *  rbcmr_seq_num.  The value of this field is equal the field
         seq_num in the RPCSEC_GSS credential (data type
         rpc_gss_cred_vers_1_t).

      *  rbcmr_bind_chan_hash.  This is the result of the one way as described hash
         of the channel bindings (including the prefix), using the hash
         algorithm identified by the rbcva_chan_bind_oid_hash field in Section 5.3.3.4.2
         the arguments to RPCSEC_GSS_BIND_CHANNEL.

      *  rbcmr_res.  The value of [2]. this field is equal to the value of
         the rbcvr_res field.

3.4.  New Security Service - rpc_gss_svc_channel_prot

         enum rpc_gss_service_t {
             /* Note: the enumerated value for 0 is reserved. */
             rpc_gss_svc_none = 1,
             rpc_gss_svc_integrity = 2,
             rpc_gss_svc_privacy = 3,
             rpc_gss_svc_channel_prot = 4 /* new */
         };

   The rpc_gss_svc_channel_prot service (Figure 3) is valid only if
   RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has
   been executed successfully, and the secure channel still exists.
   When rpc_gss_svc_channel_prot is used, the RPC requests and replies
   are similar to those of rpc_gss_svc_none except that the verifiers on
   the request and reply always have the flavor set to AUTH_NONE, and
   the contents are zero length.

   Note that even though NULL verifiers are used when
   rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are
   used.  The  In order to identify the principal sending the request, the
   same credential is used as before, except that service field is set
   to rpc_gss_svc_channel_prot.

4.  Version Negotiation

   An initiator that supports version 2 of RPCSEC_GSS simply issues an
   RPCSEC_GSS request with the version rgc_version field set to
   RPCSEC_GSS_VERS_2.  If the target does not recognize
   RPCSEC_GSS_VERS_2, the target will return an RPC error per section
   5.1 of [2].

   The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned
   by version 2 of a target with version 1 of the same target.  The
   initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by
   version 1 of a target with version 2 of the same target.

5.  Implementation Notes

   Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been
   performed on an RPCSEC_GSSv2 context handle, the initiator's
   implementation may map application requests for rpc_gss_svc_none and
   rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials.  And
   if the secure channel has privacy enabled, requests for
   rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot.

6.  Acknowledgements

   Nico

   Nicolas Williams had the idea for extending RPCSEC_GSS to support
   channel bindings.

7.  Security Considerations

   The security considerations are the same as [2].

8.  IANA Considerations

   None.

9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [2]  Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
        Specification", RFC 2203, September 1997.

   [3]  Williams, N., "On the Use of Channel Bindings to Secure
        Channels", RFC 5056, November 2007.

   [4]  Linn, J., "Generic Security Service Application Program
        Interface Version 2, Update 1", RFC 2743, January 2000.

   [5]  Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms
        and Identifiers for RSA Cryptography for use in the Internet
        X.509 Public Key Infrastructure Certificate and Certificate
        Revocation List (CRL) Profile", RFC 4055, June 2005.

9.2.  Informative References

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

Author's Address

   Mike Eisler
   NetApp
   5765 Chase Point Circle
   Colorado Springs, CO  80919
   USA
   US

   Phone: +1-719-599-9026
   Email: email2mre-ietf@yahoo.com mike@eisler.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).