NFSv4                                                          M. Eisler
Internet-Draft                                                    NetApp
Intended status: Standards Track                       February 18, 20, 2008
Expires: August 21, 23, 2008

                          RPCSEC_GSS Version 2
                 draft-ietf-nfsv4-rpcsec-gss-v2-00.txt
                 draft-ietf-nfsv4-rpcsec-gss-v2-01.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 21, 23, 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.  New Version Number  . . . . . . . . . . . . . . . . . . . . 4
     3.2.  New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5 4
     3.3.  New Security Service - rpc_gss_svc_channel_prot . . . . . . 6 5
   4.  Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Implementation Notes  . . . . . . . . . . . . . . . . . . . . . 6
   5.
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6. 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7. 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8. 6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

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 can also be eliminated.

2.  Channel Bindings Explained

   If a channel between two parties is secure, there must be a shared
   secret known between the two parties.  Either this secret is an
   inherent part of the channel, or, because the channel is secure, and
   has the option of confidentiality, the secret can be exchanged at any
   time.  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 secret.

   o  The proof of the knowledge of the shared secret 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 secret, and send
   the MIC to the target.  The target verifies the MIC, and in turn
   sends its own MIC of the secret back 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 secret, and
   thus are using the same channel.  Third, the first and second thing
   are done simultaneously.

3.  The RPCSEC_GSSv2 Protocol

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

3.1.  New Version Number

   const RPCSEC_GSS_VERS_1 = 1;
   const RPCSEC_GSS_VERS_2 = 2; /* new */

         struct rpc_gss_cred_t {
             union switch (unsigned int version) { /* version of
                                                         RPCSEC_GSS */
             case RPCSEC_GSS_VERS_1:
             case RPCSEC_GSS_VERS_2: /* new */
                 struct {
                     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;

   As is apparent from the above, the RPCSEC_GSSv2 credential has the
   same format as the RPCSSEC_GSSv1 credential.  By setting the version
   field to 2, this indicates that the initiator and target support
   channel bindings.

3.2.  New Procedure - RPCSEC_GSS_BIND_CHANNEL

           enum rpc_gss_proc_t {
                   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_chan_bind_input {
                   unsigned int    rgcbi_seq_num;
                   opaque          rgcbi_chan_bindings<>;
           };

           struct rpc_gss_bind_channel_arg {
                   int             rgbca_chan_bind_type;
                   opaque          rgbca_MIC_hdr<>;
                   opaque          rgbca_MIC_chan_bindings<>;
           };

           struct rpc_gss_bind_channel_res {
                   opaque          rgbcr_MIC_seq<>;
                   opaque          rgbcr_MIC_chan_bind<>;
           };

   Once an RPCSEC_GSSv2 handle has been established over a secure
   channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL.  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 argument and result verifier is of
   RPCSEC_GSS_BIND_CHANNEL will fit in the RPC verifier.  Like
   RPCSEC_GSS_DATA, the sufficient size for
   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 the procedure was gss_proc
   were set to RPCSEC_GSS_DATA.  The service field is set to rpc_gss_svc_none, and the
   rpc_gss_svc_none.  The handle field is set to that of established an RPCSEC_GSS handle.  The
   argument, of data type rpc_gss_bind_channel_arg
   handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT.

   When gss_proc is placed in the
   request's verifier, with RPCSEC_GSS_DATA, the verifier of an RPC flavor request is
   set to RPCSEC_GSS.  The field
   rgbca_chan_bind_type identifies the type output of channel binding GSS_GetMIC() on the
   client RPC header as described in
   Section 5.3.1 of [2].  When gss_proc is using.  The field rgbca_MIC_hdr RPCSEC_GSS_DATA, the verifier
   is of an RPC request is set to the output of GSS_GetMIC()
   resulted on the
   concatenation of the RPC header (up ("up to and including the credential.  The
   field rgbca_MIC_chan_bindings is equal to
   credential") and the result XDR encoding of GSS_GetMIC()
   a value an instance of data type data
   rpc_gss_chan_bind_input.

   The content of rpcs_gss_chan_bind_input

   Similarly when gss_proc is composed as follows.  The
   field rgcbi_seq_num is the same as the seq_num in the credential.
   The field rgcbi_chan_bindings contains the actual channel bindings.

   If RPCSEC_GSS_DATA, the target verifies rgbca_MIC_hdr, then it will return a result.
   Otherwise verifier of an RPC level error
   reply is returned.  See section 5.3.3.4.2 of
   [2].  If set to the target does not recognize rgbca_chan_bind_type, it will
   return a zero length rgbcr_MIC_chan_bind.  If output of GSS_GetMIC() on the target fails to
   verify rgbca_MIC_chan_bindings, it will return an error as per
   section 5.3.3.4.2 seq_num of [2].

   The result pf RPCSEC_GSS_BIND_CHANNEL is returned in
   rpc_gss_bind_channel_res in the RPC verifier
   credential of the reply.  The
   flavor 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 RPCSEC_GSS.  The field rgbcr_MIC_seq
   is the result of the target's execution ouput of GSS_GetMIC() on the
   concantenation of the seq_num in and the credential. XDR encoding of an instance of
   data type rpc_gss_chan_bind_input.

   The content of rpc_gss_chan_bind_input has a single field,
   rgcbi_chan_bindings.  The rgcbi_chan_bindings field rgbcr_MIC_chan_bind is the
   result consists of the target's execution
   channel bindings as defined in [3].  The channel bindings are a
   "canonical octet string encoding of GSS_GetMIC() on the channel bindings", starting
   "with the channel bindings prefix followed by a value colon (ASCII 0x3A)."

   Thus the channel bindings of
   data type rpc_gss_chan_bind_input.  After the client successfully initiator are verified when the
   target verifies both MICs, the RPCSEC_GSS context is now associated with verifier via GSS_VerifyMIC().  Similarly, the
   secure channel.
   channel bindings of the target are verified when the initiator
   verifies the verifier of the RPC reply via GSS_VerifyMIC().  Errors
   are handled the same way as described in Section 5.3.3.4.2 of [2].

3.3.  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 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 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 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.

5.

6.  Acknowledgements

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

6.

7.  Security Considerations

   The security considerations are the same as [2].

7.

8.  IANA Considerations

   The rgbca_chan_bind_type field of the RPCSEC_GSS_BIND_CHANNEL
   arguments requires an IANA registry.  Values less than zero, are
   reserved for experimentation, and do not have to be registered.
   Values greater than or equal to zeor should be registered with IANA
   in order to enable interoperability.  An entry in the registry must
   include the 32 bit binding type, and a reference to an RFC that
   describes the channel and its bindings, including how the bindings
   are constructed.

8.

   None.

9.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", 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.

Author's Address

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

   Phone: +1-719-599-9026
   Email: email2mre-ietf@yahoo.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).