idnits 2.17.1 draft-ietf-nfsv4-rpcsec-gss-v2-02.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 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 320. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 327. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 333. 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 24, 2008) is 5904 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 24, 2008 5 Expires: August 27, 2008 7 RPCSEC_GSS Version 2 8 draft-ietf-nfsv4-rpcsec-gss-v2-02.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 27, 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. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . . 4 57 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 4 58 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . . 5 59 3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . . 6 60 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 6 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 9. Normative References . . . . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Intellectual Property and Copyright Statements . . . . . . . . . . 8 69 1. Introduction and Motivation 71 RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version 72 1 (RPCSEC_GSSv1) except that support for channel bindings has been 73 added. The primary motivation for channel bindings is to securely 74 take advantage of hardware assisted encryption that might exist at 75 lower levels of the networking protocol stack, such as at the 76 Internet Protocol (IP) layer in the form of IPsec. The secondary 77 motivation is that even if lower levels are not any more efficient at 78 encryption than the RPCSEC_GSS layer, if encryption is occurring at 79 the lower level, it can be redundant at the RPCSEC_GSS level. 81 Once an RPCSEC_GSS target and initiator are mutually assured that 82 they are each using the same secure, end to end channel, the overhead 83 of computing message integrity codes (MICs) for authenticating and 84 integrity protecting RPC requests and replies can be eliminated 85 because the channel is performing the same function. Similarly, if 86 the channel also provides confidentiality, the overhead of RPCSEC_GSS 87 privacy protect can also be eliminated. 89 2. Channel Bindings Explained 91 If a channel between two parties is secure, there must be shared 92 information between the two parties. This information might be 93 secret or not. The requirement for secrecy depends on the specifics 94 of the channel. 96 For example, the shared information could be the concatenation of the 97 public key of the source and destination of the channel (where each 98 public key has a corresponding private key). Suppose the channel is 99 not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are 100 two channels, one from the initiator to the MITM, and one from the 101 MITM to the target. The MITM cannot simply force each channel to use 102 the same public keys, because the public keys come from private keys, 103 and the key management system for each node will surely assign unique 104 or random private keys. At most the MITM can force one end of each 105 channel to use the same public key. The MIC of public keys from the 106 initiator will not be verified by the target, because at least one of 107 public keys will be different. Similarly, the MIC of the public keys 108 from the target will not be verified by the initiator because at 109 least one of the public keys will be different. 111 A higher layer protocol using the secure channel can safely exploit 112 the channel to the mutual benefit of the higher level parties if each 113 higher level party can prove: 115 o They each know the channel's shared information. 117 o The proof of the knowledge of the shared information is in fact 118 being conveyed by each of the higher level parties, and not some 119 other entities. 121 RPCSEC_GSSv2 simply adds an optional round trip that has the 122 initiator compute a GSS MIC on the channel binding's shared 123 information, and sends the MIC to the target. The target verifies 124 the MIC, and in turn sends its own MIC of the shared information to 125 the initiator which verifies the target's MIC. This accomplishes 126 three things. First the initiator and target are mutually 127 authenticated. Second, the initiator and target prove they know the 128 channel's shared information, and thus are using the same channel. 129 Third, the first and second things are done simultaneously. 131 3. The RPCSEC_GSSv2 Protocol 133 The RPCSEC_GSSv2 protocol will now be explained. The entire protocol 134 is not presented. Instead the differences between RPCSEC_GSSv2 and 135 RPCSEC_GSSv1 are shown. 137 3.1. Compatibility with RPCSEC_GSSv1 139 The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2. 141 3.2. New Version Number 143 const RPCSEC_GSS_VERS_1 = 1; 144 const RPCSEC_GSS_VERS_2 = 2; /* new */ 146 struct rpc_gss_cred_t { 147 union switch (unsigned int version) { /* version of 148 RPCSEC_GSS */ 149 case RPCSEC_GSS_VERS_1: 150 case RPCSEC_GSS_VERS_2: /* new */ 151 struct { 152 rpc_gss_proc_t gss_proc; /* control procedure */ 153 unsigned int seq_num; /* sequence number */ 154 rpc_gss_service_t service; /* service used */ 155 opaque handle<>; /* context handle */ 156 } rpc_gss_cred_vers_1_t; 158 As is apparent from the above, the RPCSEC_GSSv2 credential has the 159 same format as the RPCSSEC_GSSv1 credential. By setting the version 160 field to 2, this indicates that the initiator and target support 161 channel bindings. 163 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL 165 enum rpc_gss_proc_t { 166 RPCSEC_GSS_DATA = 0, 167 RPCSEC_GSS_INIT = 1, 168 RPCSEC_GSS_CONTINUE_INIT = 2, 169 RPCSEC_GSS_DESTROY = 3, 170 RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ 171 }; 173 struct rpc_gss_chan_bind_input { 174 opaque rgcbi_chan_bindings<>; 175 }; 177 Once an RPCSEC_GSSv2 handle has been established over a secure 178 channel, the client MAY issue RPCSEC_GSS_BIND_CHANNEL. Targets MUST 179 support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT and 180 RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be 181 used. Unlike those two requests, the arguments of the NULL procedure 182 are not overloaded, because the verifier is of sufficient size for 183 the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to 184 RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc 185 were set to RPCSEC_GSS_DATA. The service field is set to 186 rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS 187 handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT. 189 When gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC request is 190 set to the output of GSS_GetMIC() on the RPC header as described in 191 Section 5.3.1 of [2]. When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the 192 verifier of an RPC request is set to the output of GSS_GetMIC() on 193 the concatenation of the RPC header ("up to and including the 194 credential") and the XDR encoding of an instance of type data 195 rpc_gss_chan_bind_input. 197 Similarly when gss_proc is RPCSEC_GSS_DATA, the verifier of an RPC 198 reply is set to the output of GSS_GetMIC() on the seq_num of the 199 credential of the corresponding request (as described in Section 200 5.3.3.2 of [2]). When gss_proc is RPCSEC_GSS_BIND_CHANNEL, the 201 verifier of an RPC reply is set to the ouput of GSS_GetMIC() on the 202 concantenation of the seq_num and the XDR encoding of an instance of 203 data type rpc_gss_chan_bind_input. 205 The content of rpc_gss_chan_bind_input has a single field, 206 rgcbi_chan_bindings. The rgcbi_chan_bindings field consists of 207 channel bindings as defined in [3]. The channel bindings are a 208 "canonical octet string encoding of the channel bindings", starting 209 "with the channel bindings prefix followed by a colon (ASCII 0x3A)." 210 Thus the channel bindings of the initiator are verified when the 211 target verifies the verifier via GSS_VerifyMIC(). Similarly, the 212 channel bindings of the target are verified when the initiator 213 verifies the verifier of the RPC reply via GSS_VerifyMIC(). Errors 214 are handled the same way as described in Section 5.3.3.4.2 of [2]. 216 3.4. New Security Service - rpc_gss_svc_channel_prot 218 enum rpc_gss_service_t { 219 /* Note: the enumerated value for 0 is reserved. */ 220 rpc_gss_svc_none = 1, 221 rpc_gss_svc_integrity = 2, 222 rpc_gss_svc_privacy = 3, 223 rpc_gss_svc_channel_prot = 4 /* new */ 224 }; 226 The rpc_gss_svc_channel_prot service is valid only if RPCSEC_GSSv2 is 227 being used, an RPCSEC_GSS_BIND_CHANNEL procedure has been executed 228 successfully, and the secure channel still exists. When 229 rpc_gss_svc_channel_prot is used, the RPC requests and replies are 230 similar to those of rpc_gss_svc_none except that the verifiers on the 231 request and reply always have the flavor set to AUTH_NONE, and the 232 contents are zero length. 234 Note that even though NULL verifiers are used when 235 rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are 236 used. The same credential is used as before, except that service 237 field is set to rpc_gss_svc_channel_prot. 239 4. Version Negotiation 241 An initiator that supports version 2 of RPCSEC_GSS simply issues an 242 RPCSEC_GSS request with the version field set to RPCSEC_GSS_VERS_2. 243 If the target does not recognize RPCSEC_GSS_VERS_2, the target will 244 return an RPC error per section 5.1 of [2]. 246 The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned 247 by version 2 of a target with version 1 of the same target. The 248 initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by 249 version 1 of a target with version 2 of the same target. 251 5. Implementation Notes 253 Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been 254 performed on an RPCSEC_GSSv2 context handle, the initiator's 255 implementation may map application requests for rpc_gss_svc_none and 256 rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And 257 if the secure channel has privacy enabled, requests for 258 rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. 260 6. Acknowledgements 262 Nico Williams had the idea for extending RPCSEC_GSS to support 263 channel bindings. 265 7. Security Considerations 267 The security considerations are the same as [2]. 269 8. IANA Considerations 271 None. 273 9. Normative References 275 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 276 Levels", March 1997. 278 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 279 Specification", RFC 2203, September 1997. 281 [3] Williams, N., "On the Use of Channel Bindings to Secure 282 Channels", RFC 5056, November 2007. 284 Author's Address 286 Mike Eisler 287 NetApp 288 5765 Chase Point Circle 289 Colorado Springs, CO 80919 290 USA 292 Phone: +1-719-599-9026 293 Email: email2mre-ietf@yahoo.com 295 Full Copyright Statement 297 Copyright (C) The IETF Trust (2008). 299 This document is subject to the rights, licenses and restrictions 300 contained in BCP 78, and except as set forth therein, the authors 301 retain all their rights. 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 307 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 308 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Intellectual Property 313 The IETF takes no position regarding the validity or scope of any 314 Intellectual Property Rights or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; nor does it represent that it has 318 made any independent effort to identify any such rights. Information 319 on the procedures with respect to rights in RFC documents can be 320 found in BCP 78 and BCP 79. 322 Copies of IPR disclosures made to the IETF Secretariat and any 323 assurances of licenses to be made available, or the result of an 324 attempt made to obtain a general license or permission for the use of 325 such proprietary rights by implementers or users of this 326 specification can be obtained from the IETF on-line IPR repository at 327 http://www.ietf.org/ipr. 329 The IETF invites any interested party to bring to its attention any 330 copyrights, patents or patent applications, or other proprietary 331 rights that may cover technology that may be required to implement 332 this standard. Please address the information to the IETF at 333 ietf-ipr@ietf.org. 335 Acknowledgment 337 Funding for the RFC Editor function is provided by the IETF 338 Administrative Support Activity (IASA).