idnits 2.17.1 draft-ietf-nfsv4-rpcsec-gss-v2-01.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 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 313. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 20, 2008) is 5910 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 20, 2008 5 Expires: August 23, 2008 7 RPCSEC_GSS Version 2 8 draft-ietf-nfsv4-rpcsec-gss-v2-01.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 23, 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 . . . . . . . . . . 4 58 3.3. New Security Service - rpc_gss_svc_channel_prot . . . . . . 5 59 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 64 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 8 68 1. Introduction and Motivation 70 RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version 71 1 (RPCSEC_GSSv1) except that support for channel bindings has been 72 added. The primary motivation for channel bindings is to securely 73 take advantage of hardware assisted encryption that might exist at 74 lower levels of the networking protocol stack, such as at the 75 Internet Protocol (IP) layer in the form of IPsec. The secondary 76 motivation is that even if lower levels are not any more efficient at 77 encryption than the RPCSEC_GSS layer, if encryption is occurring at 78 the lower level, it can be redundant at the RPCSEC_GSS level. 80 Once an RPCSEC_GSS target and initiator are mutually assured that 81 they are each using the same secure, end to end channel, the overhead 82 of computing message integrity codes (MICs) for authenticating and 83 integrity protecting RPC requests and replies can be eliminated 84 because the channel is performing the same function. Similarly, if 85 the channel also provides confidentiality, the overhead of RPCSEC_GSS 86 privacy protect can also be eliminated. 88 2. Channel Bindings Explained 90 If a channel between two parties is secure, there must be a shared 91 secret known between the two parties. Either this secret is an 92 inherent part of the channel, or, because the channel is secure, and 93 has the option of confidentiality, the secret can be exchanged at any 94 time. A higher layer protocol using the secure channel can safely 95 exploit the channel to the mutual benefit of the higher level parties 96 if each higher level party can prove: 98 o They each know the channel's shared secret. 100 o The proof of the knowledge of the shared secret is in fact being 101 conveyed by each of the higher level parties, and not some other 102 entities. 104 RPCSEC_GSSv2 simply adds an optional round trip that has the 105 initiator compute a GSS MIC on the channel binding secret, and send 106 the MIC to the target. The target verifies the MIC, and in turn 107 sends its own MIC of the secret back to the initiator which verifies 108 the target's MIC. This accomplishes three things. First the 109 initiator and target are mutually authenticated. Second, the 110 initiator and target prove they know the channel's shared secret, and 111 thus are using the same channel. Third, the first and second thing 112 are done simultaneously. 114 3. The RPCSEC_GSSv2 Protocol 116 The RPCSEC_GSSv2 protocol is now explained. The entire protocol is 117 not presented. Instead the differences between RPCSEC_GSSv2 and 118 RPCSEC_GSSv1 are shown. 120 3.1. New Version Number 122 const RPCSEC_GSS_VERS_1 = 1; 123 const RPCSEC_GSS_VERS_2 = 2; /* new */ 125 struct rpc_gss_cred_t { 126 union switch (unsigned int version) { /* version of 127 RPCSEC_GSS */ 128 case RPCSEC_GSS_VERS_1: 129 case RPCSEC_GSS_VERS_2: /* new */ 130 struct { 131 rpc_gss_proc_t gss_proc; /* control procedure */ 132 unsigned int seq_num; /* sequence number */ 133 rpc_gss_service_t service; /* service used */ 134 opaque handle<>; /* context handle */ 135 } rpc_gss_cred_vers_1_t; 137 As is apparent from the above, the RPCSEC_GSSv2 credential has the 138 same format as the RPCSSEC_GSSv1 credential. By setting the version 139 field to 2, this indicates that the initiator and target support 140 channel bindings. 142 3.2. New Procedure - RPCSEC_GSS_BIND_CHANNEL 144 enum rpc_gss_proc_t { 145 RPCSEC_GSS_DATA = 0, 146 RPCSEC_GSS_INIT = 1, 147 RPCSEC_GSS_CONTINUE_INIT = 2, 148 RPCSEC_GSS_DESTROY = 3, 149 RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ 150 }; 152 struct rpc_gss_chan_bind_input { 153 opaque rgcbi_chan_bindings<>; 154 }; 156 Once an RPCSEC_GSSv2 handle has been established over a secure 157 channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL. Targets MUST 158 support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and 159 RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be 160 used. Unlike those two requests, the arguments of the NULL procedure 161 are not overloaded, because the verifier is of sufficient size for 162 purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to 163 RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc 164 were set to RPCSEC_GSS_DATA. The service field is set to 165 rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS 166 handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT. 168 When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is 169 set to the output of GSS_GetMIC() on the RPC header as described in 170 Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_DATA, the verifier 171 is of an RPC request is set to the output of GSS_GetMIC() on the 172 concatenation of the RPC header ("up to and including the 173 credential") and the XDR encoding of an instance of type data 174 rpc_gss_chan_bind_input. 176 Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC 177 reply is set to the output of GSS_GetMIC() on the seq_num of the 178 credential of the corresponding request (as described in Section 179 5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the 180 verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the 181 concantenation of the seq_num and the XDR encoding of an instance of 182 data type rpc_gss_chan_bind_input. 184 The content of rpc_gss_chan_bind_input has a single field, 185 rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of 186 channel bindings as defined in [3]. The channel bindings are a 187 "canonical octet string encoding of the channel bindings", starting 188 "with the channel bindings prefix followed by a colon (ASCII 0x3A)." 190 Thus the channel bindings of the initiator are verified when the 191 target verifies the verifier via GSS_VerifyMIC(). Similarly, the 192 channel bindings of the target are verified when the initiator 193 verifies the verifier of the RPC reply via GSS_VerifyMIC(). Errors 194 are handled the same way as described in Section 5.3.3.4.2 of [2]. 196 3.3. New Security Service - rpc_gss_svc_channel_prot 198 enum rpc_gss_service_t { 199 /* Note: the enumerated value for 0 is reserved. */ 200 rpc_gss_svc_none = 1, 201 rpc_gss_svc_integrity = 2, 202 rpc_gss_svc_privacy = 3, 203 rpc_gss_svc_channel_prot = 4 /* new */ 204 }; 206 The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is 207 being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed 208 successfully, and the secure channel still exists. When 209 rpc_gss_svc_channel_prot is used, the RPC requests and replies are 210 similar to those of rpc_gss_svc_none except that the verifiers on the 211 request and reply always have the flavor set to AUTH_NONE, and the 212 contents are zero length. 214 Note that even though NULL verifiers are used when 215 rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are 216 used. The same credential is used as before, except that service 217 field is set to rpc_gss_svc_channel_prot. 219 4. Version Negotiation 221 An initiator that supports version 2 of RPCSEC_GSS simply issues an 222 RPCSEC_GSS request with the version field set to RPCSEC_GSS_VERS_2. 223 If the target does not recognize RPCSEC_GSS_VERS_2, the target will 224 return an RPC error per section 5.1 of [2]. 226 The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned 227 by version 2 of a target with version 1 of the same target. The 228 initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by 229 version 1 of a target with version 2 of the same target. 231 5. Implementation Notes 233 Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been 234 performed on an RPCSEC_GSSv2 context handle, the initiator's 235 implementation may map application requests for rpc_gss_svc_none and 236 rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And 237 if the secure channel has privacy enabled, requests for 238 rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. 240 6. Acknowledgements 242 Nico Williams had the idea for extending RPCSEC_GSS to support 243 channel bindings. 245 7. Security Considerations 247 The security considerations are the same as [2]. 249 8. IANA Considerations 251 None. 253 9. 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 [3] Williams, N., "On the Use of Channel Bindings to Secure 262 Channels", RFC 5056, November 2007. 264 Author's Address 266 Mike Eisler 267 NetApp 268 5765 Chase Point Circle 269 Colorado Springs, CO 80919 270 USA 272 Phone: +1-719-599-9026 273 Email: email2mre-ietf@yahoo.com 275 Full Copyright Statement 277 Copyright (C) The IETF Trust (2008). 279 This document is subject to the rights, licenses and restrictions 280 contained in BCP 78, and except as set forth therein, the authors 281 retain all their rights. 283 This document and the information contained herein are provided on an 284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 286 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 287 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 288 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 291 Intellectual Property 293 The IETF takes no position regarding the validity or scope of any 294 Intellectual Property Rights or other rights that might be claimed to 295 pertain to the implementation or use of the technology described in 296 this document or the extent to which any license under such rights 297 might or might not be available; nor does it represent that it has 298 made any independent effort to identify any such rights. Information 299 on the procedures with respect to rights in RFC documents can be 300 found in BCP 78 and BCP 79. 302 Copies of IPR disclosures made to the IETF Secretariat and any 303 assurances of licenses to be made available, or the result of an 304 attempt made to obtain a general license or permission for the use of 305 such proprietary rights by implementers or users of this 306 specification can be obtained from the IETF on-line IPR repository at 307 http://www.ietf.org/ipr. 309 The IETF invites any interested party to bring to its attention any 310 copyrights, patents or patent applications, or other proprietary 311 rights that may cover technology that may be required to implement 312 this standard. Please address the information to the IETF at 313 ietf-ipr@ietf.org. 315 Acknowledgment 317 Funding for the RFC Editor function is provided by the IETF 318 Administrative Support Activity (IASA).