idnits 2.17.1 draft-ietf-nfsv4-rpcsec-gss-v2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 310. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 152 has weird spacing: '...ned int rgc...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5911 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 M. Eisler 3 Internet-Draft NetApp 4 Intended status: Standards Track February 18, 2008 5 Expires: August 21, 2008 7 RPCSEC_GSS Version 2 8 draft-ietf-nfsv4-rpcsec-gss-v2-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 21, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. 42 Version 2 is the same as Version 1 but adds support for channel 43 bindings. 45 Requirements Language 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [1]. 51 Table of Contents 53 1. Introduction and Motivation . . . . . . . . . . . . . . . . . . 3 54 2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 3 55 3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . . 4 56 3.1. New Version Number . . . . . . . . . . . . . . . . . . . . 4 57 3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5 58 3.3. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6 59 4. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 60 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Intellectual Property and Copyright Statements . . . . . . . . . . 8 67 1. Introduction and Motivation 69 RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version 70 1 (RPCSEC_GSSv1) except that support for channel bindings has been 71 added. The primary motivation for channel bindings is to securely 72 take advantage of hardware assisted encryption that might exist at 73 lower levels of the networking protocol stack, such as at the 74 Internet Protocol (IP) layer in the form of IPsec. The secondary 75 motivation is that even if lower levels are not any more efficient at 76 encryption than the RPCSEC_GSS layer, if encryption is occurring at 77 the lower level, it can be redundant at the RPCSEC_GSS level. 79 Once an RPCSEC_GSS target and initiator are mutually assured that 80 they are each using the same secure, end to end channel, the overhead 81 of computing message integrity codes (MICs) for authenticating and 82 integrity protecting RPC requests and replies can be eliminated 83 because the channel is performing the same function. Similarly, if 84 the channel also provides confidentiality, the overhead of RPCSEC_GSS 85 privacy protect can also be eliminated. 87 2. Channel Bindings Explained 89 If a channel between two parties is secure, there must be a shared 90 secret known between the two parties. Either this secret is an 91 inherent part of the channel, or, because the channel is secure, and 92 has the option of confidentiality, the secret can be exchanged at any 93 time. A higher layer protocol using the secure channel can safely 94 exploit the channel to the mutual benefit of the higher level parties 95 if each higher level party can prove: 97 o They each know the channel's shared secret. 99 o The proof of the knowledge of the shared secret is in fact being 100 conveyed by each of the higher level parties, and not some other 101 entities. 103 RPCSEC_GSSv2 simply adds an optional round trip that has the 104 initiator compute a GSS MIC on the channel binding secret, and send 105 the MIC to the target. The target verifies the MIC, and in turn 106 sends its own MIC of the secret back to the initiator which verifies 107 the target's MIC. This accomplishes three things. First the 108 initiator and target are mutually authenticated. Second, the 109 initiator and target prove they know the channel's shared secret, and 110 thus are using the same channel. Third, the first and second thing 111 are done simultaneously. 113 3. The RPCSEC_GSSv2 Protocol 115 The RPCSEC_GSSv2 protocol is now explained. The entire protocol is 116 not presented. Instead the differences between RPCSEC_GSSv2 and 117 RPCSEC_GSSv1 are shown. 119 3.1. New Version Number 121 const RPCSEC_GSS_VERS_1 = 1; 122 const RPCSEC_GSS_VERS_2 = 2; /* new */ 124 struct rpc_gss_cred_t { 125 union switch (unsigned int version) { /* version of 126 RPCSEC_GSS */ 127 case RPCSEC_GSS_VERS_1: 128 case RPCSEC_GSS_VERS_2: /* new */ 129 struct { 130 rpc_gss_proc_t gss_proc; /* control procedure */ 131 unsigned int seq_num; /* sequence number */ 132 rpc_gss_service_t service; /* service used */ 133 opaque handle<>; /* context handle */ 134 } rpc_gss_cred_vers_1_t; 136 As is apparent from the above, the RPCSEC_GSSv2 credential has the 137 same format as the RPCSSEC_GSSv1 credential. By setting the version 138 field to 2, this indicates that the initiator and target support 139 channel bindings. 141 3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL 143 enum rpc_gss_proc_t { 144 RPCSEC_GSS_DATA = 0, 145 RPCSEC_GSS_INIT = 1, 146 RPCSEC_GSS_CONTINUE_INIT = 2, 147 RPCSEC_GSS_DESTROY = 3, 148 RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ 149 }; 151 struct rpc_gss_chan_bind_input { 152 unsigned int rgcbi_seq_num; 153 opaque rgcbi_chan_bindings<>; 154 }; 156 struct rpc_gss_bind_channel_arg { 157 int rgbca_chan_bind_type; 158 opaque rgbca_MIC_hdr<>; 159 opaque rgbca_MIC_chan_bindings<>; 160 }; 162 struct rpc_gss_bind_channel_res { 163 opaque rgbcr_MIC_seq<>; 164 opaque rgbcr_MIC_chan_bind<>; 165 }; 167 Once an RPCSEC_GSSv2 handle has been established over a secure 168 channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL. Targets MUST 169 support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and 170 RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be 171 used. Unlike those two requests, the arguments of the NULL procedure 172 are not overloaded, because the argument and result of 173 RPCSEC_GSS_BIND_CHANNEL will fit in the RPC verifier. Like 174 RPCSEC_GSS_DATA, the seq_num field is set as if the procedure was 175 RPCSEC_GSS_DATA. The service is set to rpc_gss_svc_none, and the 176 handle is set to that of established RPCSEC_GSS handle. The 177 argument, of data type rpc_gss_bind_channel_arg is placed in the 178 request's verifier, with the RPC flavor set to RPCSEC_GSS. The field 179 rgbca_chan_bind_type identifies the type of channel binding the 180 client is using. The field rgbca_MIC_hdr is the GSS_GetMIC() 181 resulted of the RPC header (up to and including the credential. The 182 field rgbca_MIC_chan_bindings is equal to the result of GSS_GetMIC() 183 a value of data type rpc_gss_chan_bind_input. 185 The content of rpcs_gss_chan_bind_input is composed as follows. The 186 field rgcbi_seq_num is the same as the seq_num in the credential. 187 The field rgcbi_chan_bindings contains the actual channel bindings. 189 If the target verifies rgbca_MIC_hdr, then it will return a result. 190 Otherwise an RPC level error is returned. See section 5.3.3.4.2 of 191 [2]. If the target does not recognize rgbca_chan_bind_type, it will 192 return a zero length rgbcr_MIC_chan_bind. If the target fails to 193 verify rgbca_MIC_chan_bindings, it will return an error as per 194 section 5.3.3.4.2 of [2]. 196 The result pf RPCSEC_GSS_BIND_CHANNEL is returned in 197 rpc_gss_bind_channel_res in the RPC verifier of the reply. The 198 flavor of the verifier is set to RPCSEC_GSS. The field rgbcr_MIC_seq 199 is the result of the target's execution of GSS_GetMIC() on the 200 seq_num in the credential. The field rgbcr_MIC_chan_bind is the 201 result of the target's execution of GSS_GetMIC() on the a value of 202 data type rpc_gss_chan_bind_input. After the client successfully 203 verifies both MICs, the RPCSEC_GSS context is now associated with the 204 secure channel. 206 3.3. New Security Service - rpc_gss_svc_channel_prot 208 enum rpc_gss_service_t { 209 /* Note: the enumerated value for 0 is reserved. */ 210 rpc_gss_svc_none = 1, 211 rpc_gss_svc_integrity = 2, 212 rpc_gss_svc_privacy = 3, 213 rpc_gss_svc_channel_prot = 4 /* new */ 214 }; 216 The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is 217 being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed 218 successfully, and the secure channel still exists. When 219 rpc_gss_svc_channel_prot is used, the RPC requests and replies are 220 similar to those of rpc_gss_svc_none except that the verifiers on the 221 request and reply always have the flavor set to AUTH_NONE, and the 222 contents are zero length. 224 4. Implementation Notes 226 Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been 227 performed on an RPCSEC_GSSv2 context handle, the initiator's 228 implementation may map application requests for rpc_gss_svc_none and 229 rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And 230 if the secure channel has privacy enabled, requests for 231 rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. 233 5. Acknowledgements 235 Nico Williams had the idea for extending RPCSEC_GSS to support 236 channel bindings. 238 6. Security Considerations 240 The security considerations are the same as [2]. 242 7. IANA Considerations 244 The rgbca_chan_bind_type field of the RPCSEC_GSS_BIND_CHANNEL 245 arguments requires an IANA registry. Values less than zero, are 246 reserved for experimentation, and do not have to be registered. 247 Values greater than or equal to zeor should be registered with IANA 248 in order to enable interoperability. An entry in the registry must 249 include the 32 bit binding type, and a reference to an RFC that 250 describes the channel and its bindings, including how the bindings 251 are constructed. 253 8. Normative References 255 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 256 Levels", March 1997. 258 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 259 Specification", RFC 2203, September 1997. 261 Author's Address 263 Mike Eisler 264 NetApp 265 5765 Chase Point Circle 266 Colorado Springs, CO 80919 267 USA 269 Phone: +1-719-599-9026 270 Email: email2mre-ietf@yahoo.com 272 Full Copyright Statement 274 Copyright (C) The IETF Trust (2008). 276 This document is subject to the rights, licenses and restrictions 277 contained in BCP 78, and except as set forth therein, the authors 278 retain all their rights. 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 283 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 284 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 285 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Intellectual Property 290 The IETF takes no position regarding the validity or scope of any 291 Intellectual Property Rights or other rights that might be claimed to 292 pertain to the implementation or use of the technology described in 293 this document or the extent to which any license under such rights 294 might or might not be available; nor does it represent that it has 295 made any independent effort to identify any such rights. Information 296 on the procedures with respect to rights in RFC documents can be 297 found in BCP 78 and BCP 79. 299 Copies of IPR disclosures made to the IETF Secretariat and any 300 assurances of licenses to be made available, or the result of an 301 attempt made to obtain a general license or permission for the use of 302 such proprietary rights by implementers or users of this 303 specification can be obtained from the IETF on-line IPR repository at 304 http://www.ietf.org/ipr. 306 The IETF invites any interested party to bring to its attention any 307 copyrights, patents or patent applications, or other proprietary 308 rights that may cover technology that may be required to implement 309 this standard. Please address the information to the IETF at 310 ietf-ipr@ietf.org. 312 Acknowledgment 314 Funding for the RFC Editor function is provided by the IETF 315 Administrative Support Activity (IASA).