RPCSEC_GSS Version 2
RFC 5403

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 06

Network Working Group                                          M. Eisler
Request for Comments: 5403                                        NetApp
Updates: 2203                                              February 2009
Category: Standards Track

                          RPCSEC_GSS Version 2

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes version 2 of the RPCSEC_GSS protocol.
   Version 2 is the same as version 1 (specified in RFC 2203) except
   that support for channel bindings has been added.  RPCSEC_GSS allows
   remote procedure call (RPC) protocols to access the Generic Security
   Services Application Programming Interface (GSS-API).

Eisler                      Standards Track                     [Page 1]
RFC 5403                      RPCSEC_GSSv2                 February 2009

Table of Contents

   1. Introduction and Motivation .....................................2
      1.1. Requirements Language ......................................3
   2. Channel Bindings Explained ......................................3
   3. The RPCSEC_GSSv2 Protocol .......................................4
      3.1. Compatibility with RPCSEC_GSSv1 ............................4
      3.2. New Version Number .........................................5
      3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL ....................7
      3.4. New Security Service - rpc_gss_svc_channel_prot ...........10
   4. Version Negotiation ............................................11
   5. Native GSS Channel Bindings ....................................11
   6. Operational Recommendation for Deployment ......................11
   7. Implementation Notes ...........................................11
   8. Acknowledgments ................................................11
   9. Security Considerations ........................................11
   10. References ....................................................13
      10.1. Normative References .....................................13
      10.2. Informative References ...................................14

1.  Introduction and Motivation

   This document describes RPCSEC_GSS version 2 (RPCSEC_GSSv2).
   RPCSEC_GSSv2 is the same as RPCSEC_GSS version 1 (RPCSEC_GSSv1) [1]
   except that support for channel bindings [2] 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 (see [7] and [8] for information on IPsec
   channel bindings).  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.

   RPCSEC_GSSv2 and RPCSEC_GSSv1 are protocols that exchange tokens
   emitted by the Generic Security Services (GSS) framework, which is
   defined in [3], and differ only in the support for GSS channel
   bindings in RPCSEC_GSSv2.  GSS itself supports channel bindings, and
   in theory RPCSEC_GSSv2 could use native GSS channel bindings to
   achieve the effects described in this section.  However, as Section
   1.1.6 of [3] states, not all implementations of all GSS mechanisms
   support channel bindings.  This is sufficient justification for the
   approach taken in this document: modify the RPCSEC_GSS protocol to
   support channel bindings independent of the capabilities of the GSS
   mechanism being used.

Eisler                      Standards Track                     [Page 2]
RFC 5403                      RPCSEC_GSSv2                 February 2009

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