NFSv4 M. Eisler Internet-Draft NetApp Intended status: Standards Track February 18, 2008 Expires: August 21, 2008 RPCSEC_GSS Version 2 draft-ietf-nfsv4-rpcsec-gss-v2-00.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, 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 Eisler Expires August 21, 2008 [Page 1] Internet-Draft RPCSEC_GSSv2 February 2008 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 3.3. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Eisler Expires August 21, 2008 [Page 2] Internet-Draft RPCSEC_GSSv2 February 2008 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. Eisler Expires August 21, 2008 [Page 3] Internet-Draft RPCSEC_GSSv2 February 2008 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. Eisler Expires August 21, 2008 [Page 4] Internet-Draft RPCSEC_GSSv2 February 2008 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 of RPCSEC_GSS_BIND_CHANNEL will fit in the RPC verifier. Like RPCSEC_GSS_DATA, the seq_num field is set as if the procedure was RPCSEC_GSS_DATA. The service is set to rpc_gss_svc_none, and the handle is set to that of established RPCSEC_GSS handle. The argument, of data type rpc_gss_bind_channel_arg is placed in the request's verifier, with the RPC flavor set to RPCSEC_GSS. The field rgbca_chan_bind_type identifies the type of channel binding the client is using. The field rgbca_MIC_hdr is the GSS_GetMIC() resulted of the RPC header (up to and including the credential. The field rgbca_MIC_chan_bindings is equal to the result of GSS_GetMIC() a value of data type rpc_gss_chan_bind_input. The content of rpcs_gss_chan_bind_input 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. Eisler Expires August 21, 2008 [Page 5] Internet-Draft RPCSEC_GSSv2 February 2008 If the target verifies rgbca_MIC_hdr, then it will return a result. Otherwise an RPC level error is returned. See section 5.3.3.4.2 of [2]. If the target does not recognize rgbca_chan_bind_type, it will return a zero length rgbcr_MIC_chan_bind. If the target fails to verify rgbca_MIC_chan_bindings, it will return an error as per section 5.3.3.4.2 of [2]. The result pf RPCSEC_GSS_BIND_CHANNEL is returned in rpc_gss_bind_channel_res in the RPC verifier of the reply. The flavor of the verifier is set to RPCSEC_GSS. The field rgbcr_MIC_seq is the result of the target's execution of GSS_GetMIC() on the seq_num in the credential. The field rgbcr_MIC_chan_bind is the result of the target's execution of GSS_GetMIC() on the a value of data type rpc_gss_chan_bind_input. After the client successfully verifies both MICs, the RPCSEC_GSS context is now associated with the secure channel. 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. 4. 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. Eisler Expires August 21, 2008 [Page 6] Internet-Draft RPCSEC_GSSv2 February 2008 5. Acknowledgements Nico Williams had the idea for extending RPCSEC_GSS to support channel bindings. 6. Security Considerations The security considerations are the same as [2]. 7. 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. 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. 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 Eisler Expires August 21, 2008 [Page 7] Internet-Draft RPCSEC_GSSv2 February 2008 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). Eisler Expires August 21, 2008 [Page 8]