RPCSEC_GSS Version 2
RFC 5403
| Document | Type |
RFC - Proposed Standard
(February 2009; No errata)
Updated by RFC 7861
Updates RFC 2203
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5403 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Lars Eggert | ||
| Send notices to | (None) | ||
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
Show full document text