idnits 2.17.1 draft-ietf-nfsv4-rpcsec-gss-v2-06.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 587. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 611. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2203, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 223 has weird spacing: '... opaque rgs...' == Line 224 has weird spacing: '... opaque rgs...' (Using the creation date from RFC2203, updated by this document, for RFC5378 checks: 1996-07-24) -- 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 (October 9, 2008) is 5676 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) == Missing Reference: '0' is mentioned on line 371, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-btns-connection-latching-07 -- Obsolete informational reference (is this intentional?): RFC 1831 (ref. '8') (Obsoleted by RFC 5531) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 M. Eisler 3 Internet-Draft NetApp 4 Updates: 2203 (if approved) October 9, 2008 5 Intended status: Standards Track 6 Expires: April 12, 2009 8 RPCSEC_GSS Version 2 9 draft-ietf-nfsv4-rpcsec-gss-v2-06.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 12, 2009. 36 Abstract 38 This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. 39 Version 2 is the same as Version 1 but adds support for channel 40 bindings. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [1]. 48 Table of Contents 50 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 51 2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 4 52 3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . 5 53 3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . 5 54 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 5 55 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . 6 56 3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . 10 57 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 10 58 5. Native GSS Channel Bindings . . . . . . . . . . . . . . . . . 10 59 6. Operational Recommendation for Deployment . . . . . . . . . . 10 60 7. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 11 61 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 66 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Intellectual Property and Copyright Statements . . . . . . . . . . 15 70 1. Introduction and Motivation 72 This document describes RPCSEC_GSS version 2 (RPCSEC_GSSv2). 73 RPCSEC_GSSv2 is the same as RPCSEC_GSS version 1 (RPCSEC_GSSv1) [2] 74 except that support for channel bindings [3] has been added. The 75 primary motivation for channel bindings is to securely take advantage 76 of hardware assisted encryption that might exist at lower levels of 77 the networking protocol stack, such as at the Internet Protocol (IP) 78 layer in the form of IPsec (see [6] and [7] for information on IPsec 79 channel bindings). The secondary motivation is that even if lower 80 levels are not any more efficient at encryption than the RPCSEC_GSS 81 layer, if encryption is occurring at the lower level, it can be 82 redundant at the RPCSEC_GSS level. 84 RPCSEC_GSSv2 and RPCSEC_GSSv1 are protocols that exchange tokens 85 emitted by the Generic Security Services (GSS) framework, which is 86 defined in [4], and differ only in the support for GSS channel 87 bindings in RPCSEC_GSSv2. GSS itself supports channel bindings, and 88 in theory RPCSEC_GSSv2 could use native GSS channel bindings to 89 achieve the effects described in this section. However, as Section 90 1.1.6 of [4] states, not all implementations of all GSS mechanisms 91 support channel bindings. This is sufficient justification for the 92 approach taken in this document: modify the RPCSEC_GSS protocol to 93 support channel bindings independent of the capabilities of the GSS 94 mechanism being used. 96 Once an RPCSEC_GSS target and initiator are mutually assured that 97 they are each using the same secure, end to end channel, the overhead 98 of computing message integrity codes (MICs) for authenticating and 99 integrity protecting RPC requests and replies can be eliminated 100 because the channel is performing the same function. Similarly, if 101 the channel also provides confidentiality, the overhead of RPCSEC_GSS 102 privacy protection can also be eliminated. 104 The XDR description is provided in this document in a way that makes 105 it simple for the reader to extract into a ready to compile form. 106 The reader can feed this document into the following shell script to 107 produce the machine readable XDR description of RPCSEC_GSSv2: 109 #!/bin/sh 110 grep "^ *///" | sed 's?^ *///??' 112 I.e. if the above script is stored in a file called "extract.sh", and 113 this document is in a file called "spec.txt", then the reader can do: 115 sh extract.sh < spec.txt > rpcsec_gss_v2.x 117 The effect of the script is to remove leading white space from each 118 line of the specification, plus a sentinel sequence of "///". 120 2. Channel Bindings Explained 122 If a channel between two parties is secure, there must be shared 123 information between the two parties. This information might be 124 secret or not. The requirement for secrecy depends on the specifics 125 of the channel. 127 For example, the shared information could be the concatenation of the 128 public key of the source and destination of the channel (where each 129 public key has a corresponding private key). Suppose the channel is 130 not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are 131 two channels, one from the initiator to the MITM, and one from the 132 MITM to the target. The MITM cannot simply force each channel to use 133 the same public keys, because a public key derives from a private 134 key, and the key management system for each node will surely assign 135 unique or random private keys. At most, the MITM can force one end 136 of each channel to use the same public key. The MIC of the public 137 keys from the initiator will not be verified by the target, because 138 at least one of the public keys will be different. Similarly, the 139 MIC of the public keys from the target will not be verified by the 140 initiator because at least one of the public keys will be different. 142 A higher layer protocol using the secure channel can safely exploit 143 the channel to the mutual benefit of the higher level parties if each 144 higher level party can prove: 146 o They each know the channel's shared information. 148 o The proof of the knowledge of the shared information is in fact 149 being conveyed by each of the higher level parties, and not some 150 other entities. 152 RPCSEC_GSSv2 simply adds an optional round trip that has the 153 initiator compute a GSS MIC on the channel binding's shared 154 information, and sends the MIC to the target. The target verifies 155 the MIC, and in turn sends its own MIC of the shared information to 156 the initiator which verifies the target's MIC. This accomplishes 157 three things. First the initiator and target are mutually 158 authenticated. Second, the initiator and target prove they know the 159 channel's shared information, and thus are using the same channel. 160 Third, the first and second things are done simultaneously. 162 3. The RPCSEC_GSSv2 Protocol 164 The RPCSEC_GSSv2 protocol will now be explained. The entire protocol 165 is not presented. Instead the differences between RPCSEC_GSSv2 and 166 RPCSEC_GSSv1 are shown. 168 3.1. Compatibility with RPCSEC_GSSv1 170 The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2. 172 3.2. New Version Number 174 /// enum rpc_gss_service_t { 175 /// /* Note: the enumerated value for 0 is reserved. */ 176 /// rpc_gss_svc_none = 1, 177 /// rpc_gss_svc_integrity = 2, 178 /// rpc_gss_svc_privacy = 3, 179 /// rpc_gss_svc_channel_prot = 4 /* new */ 180 /// }; 181 /// 182 /// enum rpc_gss_proc_t { 183 /// RPCSEC_GSS_DATA = 0, 184 /// RPCSEC_GSS_INIT = 1, 185 /// RPCSEC_GSS_CONTINUE_INIT = 2, 186 /// RPCSEC_GSS_DESTROY = 3, 187 /// RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ 188 /// }; 189 /// 190 /// struct rpc_gss_cred_vers_1_t { 191 /// rpc_gss_proc_t gss_proc; /* control procedure */ 192 /// unsigned int seq_num; /* sequence number */ 193 /// rpc_gss_service_t service; /* service used */ 194 /// opaque handle<>; /* context handle */ 195 /// }; 196 /// 197 /// const RPCSEC_GSS_VERS_1 = 1; 198 /// const RPCSEC_GSS_VERS_2 = 2; /* new */ 199 /// 200 /// union rpc_gss_cred_t switch (unsigned int rgc_version) { 201 /// case RPCSEC_GSS_VERS_1: 202 /// case RPCSEC_GSS_VERS_2: /* new */ 203 /// rpc_gss_cred_vers_1_t rgc_cred_v1; 204 /// }; 205 /// 207 Figure 1 209 As is apparent from the above, the RPCSEC_GSSv2 credential has the 210 same format as the RPCSEC_GSSv1 credential (albeit corrected so that 211 the definition is in legal XDR description language that is also 212 compatible with [8]. Hence the field "version", a keyword in [8], is 213 replaced with rgc_version). By setting the rgc_version field to 2, 214 this indicates that the initiator and target support channel 215 bindings. 217 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL 219 /// struct rgss2_bind_chan_MIC_in_args { 220 /// opaque rbcmia_bind_chan_hash<>; 221 /// }; 222 /// 223 /// typedef opaque rgss2_chan_pref<>; 224 /// typedef opaque rgss2_oid<>; 225 /// 226 /// struct rgss2_bind_chan_verf_args { 227 /// rgss2_chan_pref rbcva_chan_bind_prefix; 228 /// rgss2_oid rbcva_chan_bind_oid_hash; 229 /// opaque rbcva_chan_mic<>; 230 /// }; 231 /// 233 Figure 2 235 Once an RPCSEC_GSSv2 handle has been established over a secure 236 channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 1). 237 Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT 238 and RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be 239 used. Unlike those two requests, the arguments of the NULL procedure 240 are not overloaded, because the verifier is of sufficient size for 241 the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to 242 RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc 243 were set to RPCSEC_GSS_DATA. The service field is set to 244 rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS 245 handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT. 247 The RPCSEC_GSS_BIND_CHANNEL request is similar to the RPCSEC_GSS_DATA 248 request in that the verifiers of both contain MICs. As described in 249 Section 5.3.1 of [2], when gss_proc is RPCSEC_GSS_DATA, the verifier 250 of an RPC request is set to the output of GSS_GetMIC() on the RPC 251 header. When gss_proc is RPCSEC_GSS_BIND_CHANNEL the verifier of an 252 RPC request is set to the XDR encoding on a value of data type 253 rgss2_bind_chan_verf_args, which includes a MIC as described below. 254 The rgss2_bind_chan_verf_args data type consists of three fields: 256 o rbcva_chan_bind_prefix. This is the channel binding prefix as 257 described in [3] up to, but excluding the colon (ASCII 0x3A) that 258 separates the prefix from the suffix. 260 o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of 261 the hash algorithm used to compute rbcmia_bind_chan_hash. This 262 field contains an OID encoded in ASN.1 as used by GSS-API in the 263 mech_type argument to GSS_Init_sec_context ([4]). See [5] for the 264 OIDs of the SHA one-way hash algorithms. 266 o rbcva_chan_mic. This is the output of GSS_GetMIC() on the 267 concatenation of the XDR encoded RPC header ("up to and including 268 the credential" as per [2]) and the XDR encoding of an instance of 269 type data rgss2_bind_chan_MIC_in_args. The data type 270 rgss2_bind_chan_MIC_in_args consists of one field, 271 rbcmia_bind_chan_hash, which is a hash of the channel bindings as 272 defined in [3]. The channel bindings are a "canonical octet 273 string encoding of the channel bindings", starting "with the 274 channel bindings prefix followed by a colon (ASCII 0x3A)." The 275 reason a hash of the channel bindings and not the actual channel 276 bindings are used to compute rbcva_chan_mic is that some channel 277 bindings, such as those composed of public keys, can be relatively 278 large, and thus place a higher space burden on the implementations 279 to manage. One way hashes consume less space. 281 /// enum rgss2_bind_chan_status { 282 /// RGSS2_BIND_CHAN_OK = 0, 283 /// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1, 284 /// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2 285 /// }; 286 /// 287 /// union rgss2_bind_chan_res switch 288 /// (rgss2_bind_chan_status rbcr_stat) { 289 /// 290 /// case RGSS2_BIND_CHAN_OK: 291 /// void; 292 /// 293 /// case RGSS2_BIND_CHAN_PREF_NOTSUPP: 294 /// rgss2_chan_pref rbcr_pref_list<>; 295 /// 296 /// case RGSS2_BIND_CHAN_HASH_NOTSUPP: 297 /// rgss2_oid rbcr_oid_list<>; 298 /// }; 299 /// 300 /// struct rgss2_bind_chan_MIC_in_res { 301 /// unsigned int rbcmr_seq_num; 302 /// opaque rbcmr_bind_chan_hash<>; 303 /// rgss2_bind_chan_res rbcmr_res; 304 /// }; 305 /// 306 /// struct rgss2_bind_chan_verf_res { 307 /// rgss2_bind_chan_res rbcvr_res; 308 /// opaque rbcvr_mic<>; 309 /// }; 310 /// 312 Figure 3 314 The RPCSEC_GSS_BIND_CHANNEL reply is similar to the RPCSEC_GSS_DATA 315 reply in that the verifiers of both contain MICs. When gss_proc is 316 RPCSEC_GSS_DATA, the verifier of an RPC reply is set to the output of 317 GSS_GetMIC() on the seq_num of the credential of the corresponding 318 request (as described in Section 5.3.3.2 of [2]). When gss_proc is 319 RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the 320 XDR encoding of an instance of data type rgss2_bind_chan_verf_res, 321 which includes a MIC as described below. The data type 322 rgss2_bind_chan_verf_res consists of two fields. 324 o rbcvr_res. The data type of this field is rgss2_bind_chan_res. 325 The rgss2_bind_chan_res data type is a switched union consisting 326 of three cases switched on the status contained in the rbcr_stat 327 field. 329 * RGSS2_BIND_CHAN_OK. If this status is returned, the target 330 accepted the channel bindings, and successfully verified 331 rbcva_chan_mic in the request. No additional results will be 332 in rbcvr_res. 334 * RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the 335 target did not support the prefix in the rbcva_chan_bind_prefix 336 field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL 337 request was rejected. The target returned a list of prefixes 338 it does support in the field rbcr_pref_list. Note that a 339 channel can have multiple channel bindings each with different 340 prefixes. The initiator is free to pick its preferred prefix. 341 If the target does not support the prefix, the status 342 RGSS2_BIND_CHAN_PREF_NOTSUPP will be returned, and the 343 initiator can select its next most preferred prefix among the 344 prefixes the target does support. 346 * RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the 347 target did not support the hash algorithm identified in the 348 rbcva_chan_bind_hash_oid field of the arguments, and thus the 349 RPCSEC_GSS_BIND_CHANNEL request was rejected. The target 350 returned a list of OIDs of hash algorithms it does support in 351 the field rbcr_oid_list. The array rbcr_oid_list MUST have one 352 or more elements. 354 o rbcvr_mic. The value of this field is equal to the output of 355 GSS_GetMIC() on the XDR encoding of an instance of data type 356 rgss2_bind_chan_MIC_in_res. The data type 357 rgss2_bind_chan_MIC_in_res consists of three fields. 359 * rbcmr_seq_num. The value of this field is equal the field 360 seq_num in the RPCSEC_GSS credential (data type 361 rpc_gss_cred_vers_1_t). 363 * rbcmr_bind_chan_hash. This is the result of the one way hash 364 of the channel bindings (including the prefix). If rbcr_stat 365 is not RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm 366 that is used to compute rbcmr_bind_chan_hash is that identified 367 by the rbcva_chan_bind_oid_hash field in the arguments to 368 RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is 369 RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to 370 compute rbcmr_bind_chan_hash is that identified by 371 rbcr_oid_list[0] in the results. 373 * rbcmr_res. The value of this field is equal to the value of 374 the rbcvr_res field. 376 3.4. New Security Service - rpc_gss_svc_channel_prot 378 RPCSEC_GSSv2 targets MUST support rpc_gss_svc_channel_prot. 380 The rpc_gss_svc_channel_prot service (Figure 1) is valid only if 381 RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has 382 been executed successfully, and the secure channel still exists. 383 When rpc_gss_svc_channel_prot is used, the RPC requests and replies 384 are similar to those of rpc_gss_svc_none except that the verifiers on 385 the request and reply always have the flavor set to AUTH_NONE, and 386 the contents are zero length. 388 Note that even though NULL verifiers are used when 389 rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are 390 used. In order to identify the principal sending the request, the 391 same credential is used as before, except that service field is set 392 to rpc_gss_svc_channel_prot. 394 4. Version Negotiation 396 An initiator that supports version 2 of RPCSEC_GSS simply issues an 397 RPCSEC_GSS request with the rgc_version field set to 398 RPCSEC_GSS_VERS_2. If the target does not recognize 399 RPCSEC_GSS_VERS_2, the target will return an RPC error per section 400 5.1 of [2]. 402 The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned 403 by version 2 of a target with version 1 of the same target. The 404 initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by 405 version 1 of a target with version 2 of the same target. 407 5. Native GSS Channel Bindings 409 To ensure interoperability, implementations of RPCSEC_GSSv2 SHOULD 410 NOT transfer tokens between the initiator and target that use native 411 GSS channel bindings (as defined in Section 1.1.6 of [4]). 413 6. Operational Recommendation for Deployment 415 RPCSEC_GSSv2 is a superset of RPCSEC_GSSv1, and so can be used in all 416 situations where RPCSEC_GSSv1 is used. RPCSEC_GSSv2 should be used 417 when the new functionality, channel bindings, is desired or needed. 419 7. Implementation Notes 421 Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been 422 performed on an RPCSEC_GSSv2 context handle, the initiator's 423 implementation may map application requests for rpc_gss_svc_none and 424 rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And 425 if the secure channel has privacy enabled, requests for 426 rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. 428 8. Acknowledgements 430 Nicolas Williams had the idea for extending RPCSEC_GSS to support 431 channel bindings. Alex Burlyga, Lars Eggert, Pasi Eronen, and Dan 432 Romascanu reviewed the document and gave valuable feed back for 433 improving its readability. 435 9. Security Considerations 437 The base security considerations consist of: 439 o All security considerations from [2]. 441 o All security considerations from [3]. 443 o All security considerations from the actual secure channel being 444 used. 446 Even though RPCSEC_GSS_DATA requests that use 447 rpc_gss_svc_channel_prot protection do not involve construction of 448 more GSS tokens, nonetheless, the target SHOULD stop allowing 449 RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection 450 once the GSS context expires. 452 With the use of channel bindings, it becomes extremely critical that 453 the message integrity code (MIC) used by the GSS mechanism that 454 RPCSEC_GSS is using be difficult to forge. While this requirement is 455 true for RPCSEC_GSSv1, and indeed any protocol that uses GSS MICs, 456 the distinction in the seriousness is that for RPCSEC_GSSv1, forging 457 a single MIC at most allows the attacker to succeed in injecting one 458 bogus request. Whereas, with RPCSEC_GSSv2 combined with channel 459 bindings, by forging a single MIC all the attacker will succeed in 460 injecting bogus requests as long as the channel exists. An example 461 illustrates. Suppose we have an RPCSEC_GSSv1 initiator, a man in the 462 middle (MITM), an RPCSEC_GSSv1 target, and an RPCSEC_GSSv2 target. 463 The attack is as follows. 465 o The MITM intercepts the initiator's RPCSEC_GSSv1 RPCSEC_GSS_INIT 466 message and changes the version number from 1 to 2 before 467 forwarding to the RPCSEC_GSSv2 target, and changes the reply's 468 version number from 2 to 1 before forwarding to the RPCSEC_GSSv1 469 initiator. Neither the client nor the server notice. 471 o Once the RPCSEC_GSS handle is in an established state, the 472 initiator sends its first RPCSEC_GSS_DATA request. The MITM 473 constructs an RPCSEC_GSS_BIND_CHANNEL request, using the message 474 integrity code (MIC) of the RPCSEC_GSS_DATA request. It is likely 475 the RPCSEC_GSSv2 target will reject the request. The MITM 476 continues to re-iterate each time the initiator sends another 477 RPCSEC_GSS_DATA request. With enough iterations, the probability 478 of a MIC from an RPCSEC_GSS_DATA being successfully verified in 479 the forged RPCSEC_GSS_BIND_CHANNEL increases. Once the MITM 480 succeeds, it can send RPCSEC_GSS_DATA requests with a security 481 service of rpc_gss_svc_channel_prot, which does not have MICs in 482 the RPC request's verifier. 484 The implementation of RPCSEC_GSSv2 can use at least two methods to 485 thwart these attacks. 487 o The target SHOULD require a stronger MIC (e.g. if HMACs are used 488 for the MICs, require the widest possible HMAC in terms of bit 489 length that the GSS mechanism supports) when sending an 490 RPCSEC_GSS_BIND_CHANNEL request instead of an RPCSEC_GSS_DATA 491 request. If HMACs are being used, and the target expects N 492 RPCSEC_GSS_DATA requests to be sent on the context before it 493 expires, then the target SHOULD require an HMAC for 494 RPCSEC_GSS_BIND_CHANNEL that is log base 2 N bits longer than what 495 it normally requires for RPCSEC_GSS_DATA requests. If a long 496 enough MIC is not available, then the target could artificially 497 limit the number of RPCSEC_GSS_DATA requests it will allow on the 498 context before deleting the context. 500 o Each time an RPCSEC_GSSv2 target experiences a failure to verify 501 the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD reduce 502 the lifetime of the underlying GSS context, by a significant 503 fraction, thereby preventing the MITM from using the established 504 context for its attack. A possible heuristic is that the if the 505 target believes the possibility that failure to verify the MIC was 506 because of an attack is X percent, then contexts lifetime would be 507 reduced by X percent. For simplicity, an implement might set X to 508 be 50 percent, so that the context lifetime is halved on each 509 failed verification of an RPCSEC_GSS_BIND_CHANNEL request and thus 510 rapidly reduced to zero on subsequent requests. For example, with 511 a context like time of 8 hours (or 28800 seconds), 15 failed 512 attempts by the MITM would cause the context to be destroyed. 514 A method of mitigation that was considered was to protect the 515 RPCSEC_GSS version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and 516 RPCSEC_GSS_CONTINUE_INIT tokens. Thus the version number of 517 RPCSEC_GSS would be in the tokens. This method does not completely 518 mitigate the attack; it just moves the MIC guessing to the 519 RPCSEC_GSS_INIT message. In addition without changing GSS, or the 520 GSS mechanism, there is no way to include the RPCSEC_GSS version 521 number in the tokens. So for these reasons this method was not 522 selected. 524 10. IANA Considerations 526 None. 528 11. References 530 11.1. Normative References 532 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 533 Levels", RFC 2119, March 1997. 535 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 536 Specification", RFC 2203, September 1997. 538 [3] Williams, N., "On the Use of Channel Bindings to Secure 539 Channels", RFC 5056, November 2007. 541 [4] Linn, J., "Generic Security Service Application Program 542 Interface Version 2, Update 1", RFC 2743, January 2000. 544 [5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 545 and Identifiers for RSA Cryptography for use in the Internet 546 X.509 Public Key Infrastructure Certificate and Certificate 547 Revocation List (CRL) Profile", RFC 4055, June 2005. 549 11.2. Informative References 551 [6] Williams, N., "IPsec Channels: Connection Latching", 552 draft-ietf-btns-connection-latching-07 (work in progress), 553 April 2008. 555 [7] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 556 and Public Keys", draft-williams-ipsec-channel-binding-01 (work 557 in progress), April 2008. 559 [8] Srinivasan, R., "RPC: Remote Procedure Call Protocol 560 Specification Version 2", RFC 1831, August 1995. 562 Author's Address 564 Mike Eisler 565 NetApp 566 5765 Chase Point Circle 567 Colorado Springs, CO 80919 568 US 570 Phone: +1-719-599-9026 571 Email: mike@eisler.com 573 Full Copyright Statement 575 Copyright (C) The IETF Trust (2008). 577 This document is subject to the rights, licenses and restrictions 578 contained in BCP 78, and except as set forth therein, the authors 579 retain all their rights. 581 This document and the information contained herein are provided on an 582 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 583 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 584 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 585 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 586 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 587 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 589 Intellectual Property 591 The IETF takes no position regarding the validity or scope of any 592 Intellectual Property Rights or other rights that might be claimed to 593 pertain to the implementation or use of the technology described in 594 this document or the extent to which any license under such rights 595 might or might not be available; nor does it represent that it has 596 made any independent effort to identify any such rights. Information 597 on the procedures with respect to rights in RFC documents can be 598 found in BCP 78 and BCP 79. 600 Copies of IPR disclosures made to the IETF Secretariat and any 601 assurances of licenses to be made available, or the result of an 602 attempt made to obtain a general license or permission for the use of 603 such proprietary rights by implementers or users of this 604 specification can be obtained from the IETF on-line IPR repository at 605 http://www.ietf.org/ipr. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights that may cover technology that may be required to implement 610 this standard. Please address the information to the IETF at 611 ietf-ipr@ietf.org.