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 htmlized 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 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.Show full document text