idnits 2.17.1 draft-ietf-nfsv4-rpcsec-gss-v2-05.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 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. 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 207 has weird spacing: '... opaque rgs...' == Line 208 has weird spacing: '... opaque rgs...' -- 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 (August 18, 2008) is 5730 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 349, 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 (==), 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 August 18, 2008 5 Expires: February 19, 2009 7 RPCSEC_GSS Version 2 8 draft-ietf-nfsv4-rpcsec-gss-v2-05.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 February 19, 2009. 35 Abstract 37 This Internet-Draft describes version 2 of the RPCSEC_GSS protocol. 38 Version 2 is the same as Version 1 but adds support for channel 39 bindings. 41 Requirements Language 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 45 document are to be interpreted as described in RFC 2119 [1]. 47 Table of Contents 49 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 3 50 2. Channel Bindings Explained . . . . . . . . . . . . . . . . . . 3 51 3. The RPCSEC_GSSv2 Protocol . . . . . . . . . . . . . . . . . . 4 52 3.1. Compatibility with RPCSEC_GSSv1 . . . . . . . . . . . . . 4 53 3.2. New Version Number . . . . . . . . . . . . . . . . . . . . 5 54 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL . . . . . . . . . 6 55 3.4. New Security Service - rpc_gss_svc_channel_prot . . . . . 9 56 4. Version Negotiation . . . . . . . . . . . . . . . . . . . . . 9 57 5. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 9 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 Intellectual Property and Copyright Statements . . . . . . . . . . 14 67 1. Introduction and Motivation 69 RPCSEC_GSS version 2 (RPCSEC_GSSv2) is the same as RPCSEC_GSS version 70 1 (RPCSEC_GSSv1) [2] except that support for channel bindings [3] has 71 been added. The primary motivation for channel bindings is to 72 securely take advantage of hardware assisted encryption that might 73 exist at lower levels of the networking protocol stack, such as at 74 the Internet Protocol (IP) layer in the form of IPsec (see [6] and 75 [7] for information on IPsec channel bindings). 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 protection can also be eliminated. 88 The XDR description is provided in this document in a way that makes 89 it simple for the reader to extract into a ready to compile form. 90 The reader can feed this document into the following shell script to 91 produce the machine readable XDR description of RPCSEC_GSSv2: 93 #!/bin/sh 94 grep "^ *///" | sed 's?^ *///??' 96 I.e. if the above script is stored in a file called "extract.sh", and 97 this document is in a file called "spec.txt", then the reader can do: 99 sh extract.sh < spec.txt > rpcsec_gss_v2.x 101 The effect of the script is to remove leading white space from each 102 line of the specification, plus a sentinel sequence of "///". 104 2. Channel Bindings Explained 106 If a channel between two parties is secure, there must be shared 107 information between the two parties. This information might be 108 secret or not. The requirement for secrecy depends on the specifics 109 of the channel. 111 For example, the shared information could be the concatenation of the 112 public key of the source and destination of the channel (where each 113 public key has a corresponding private key). Suppose the channel is 114 not end-to-end, i.e. a man-in-the-middle (MITM) exists, and there are 115 two channels, one from the initiator to the MITM, and one from the 116 MITM to the target. The MITM cannot simply force each channel to use 117 the same public keys, because a public key derives from a private 118 key, and the key management system for each node will surely assign 119 unique or random private keys. At most, the MITM can force one end 120 of each channel to use the same public key. The MIC of the public 121 keys from the initiator will not be verified by the target, because 122 at least one of the public keys will be different. Similarly, the 123 MIC of the public keys from the target will not be verified by the 124 initiator because at least one of the public keys will be different. 126 A higher layer protocol using the secure channel can safely exploit 127 the channel to the mutual benefit of the higher level parties if each 128 higher level party can prove: 130 o They each know the channel's shared information. 132 o The proof of the knowledge of the shared information is in fact 133 being conveyed by each of the higher level parties, and not some 134 other entities. 136 RPCSEC_GSSv2 simply adds an optional round trip that has the 137 initiator compute a GSS MIC on the channel binding's shared 138 information, and sends the MIC to the target. The target verifies 139 the MIC, and in turn sends its own MIC of the shared information to 140 the initiator which verifies the target's MIC. This accomplishes 141 three things. First the initiator and target are mutually 142 authenticated. Second, the initiator and target prove they know the 143 channel's shared information, and thus are using the same channel. 144 Third, the first and second things are done simultaneously. 146 3. The RPCSEC_GSSv2 Protocol 148 The RPCSEC_GSSv2 protocol will now be explained. The entire protocol 149 is not presented. Instead the differences between RPCSEC_GSSv2 and 150 RPCSEC_GSSv1 are shown. 152 3.1. Compatibility with RPCSEC_GSSv1 154 The functionality of RPCSEC_GSSv1 is fully supported by RPCSEC_GSSv2. 156 3.2. New Version Number 158 /// enum rpc_gss_service_t { 159 /// /* Note: the enumerated value for 0 is reserved. */ 160 /// rpc_gss_svc_none = 1, 161 /// rpc_gss_svc_integrity = 2, 162 /// rpc_gss_svc_privacy = 3, 163 /// rpc_gss_svc_channel_prot = 4 /* new */ 164 /// }; 165 /// 166 /// enum rpc_gss_proc_t { 167 /// RPCSEC_GSS_DATA = 0, 168 /// RPCSEC_GSS_INIT = 1, 169 /// RPCSEC_GSS_CONTINUE_INIT = 2, 170 /// RPCSEC_GSS_DESTROY = 3, 171 /// RPCSEC_GSS_BIND_CHANNEL = 4 /* new */ 172 /// }; 173 /// 174 /// struct rpc_gss_cred_vers_1_t { 175 /// rpc_gss_proc_t gss_proc; /* control procedure */ 176 /// unsigned int seq_num; /* sequence number */ 177 /// rpc_gss_service_t service; /* service used */ 178 /// opaque handle<>; /* context handle */ 179 /// }; 180 /// 181 /// const RPCSEC_GSS_VERS_1 = 1; 182 /// const RPCSEC_GSS_VERS_2 = 2; /* new */ 183 /// 184 /// union rpc_gss_cred_t switch (unsigned int rgc_version) { 185 /// case RPCSEC_GSS_VERS_1: 186 /// case RPCSEC_GSS_VERS_2: /* new */ 187 /// rpc_gss_cred_vers_1_t rgc_cred_v1; 188 /// }; 189 /// 191 Figure 1 193 As is apparent from the above, the RPCSEC_GSSv2 credential has the 194 same format as the RPCSEC_GSSv1 credential (albeit corrected so that 195 the definition is in legal XDR description language that is also 196 compatible with [8]. Hence the field "version", a keyword in [8], is 197 replaced with rgc_version). By setting the rgc_version field to 2, 198 this indicates that the initiator and target support channel 199 bindings. 201 3.3. New Procedure - RPCSEC_GSS_BIND_CHANNEL 203 /// struct rgss2_bind_chan_MIC_in_args { 204 /// opaque rbcmia_bind_chan_hash<>; 205 /// }; 206 /// 207 /// typedef opaque rgss2_chan_pref<>; 208 /// typedef opaque rgss2_oid<>; 209 /// 210 /// struct rgss2_bind_chan_verf_args { 211 /// rgss2_chan_pref rbcva_chan_bind_prefix; 212 /// rgss2_oid rbcva_chan_bind_oid_hash; 213 /// opaque rbcva_chan_mic<>; 214 /// }; 215 /// 217 Figure 2 219 Once an RPCSEC_GSSv2 handle has been established over a secure 220 channel, the initiator MAY issue RPCSEC_GSS_BIND_CHANNEL (Figure 1). 221 Targets MUST support RPCSEC_GSS_BIND_CHANNEL. Like RPCSEC_GSS_INIT 222 and RPCSEC_GSS_CONTINUE_INIT requests, the NULL RPC procedure MUST be 223 used. Unlike those two requests, the arguments of the NULL procedure 224 are not overloaded, because the verifier is of sufficient size for 225 the purpose of RPCSEC_GSS_BIND_CHANNEL. The gss_proc field is set to 226 RPCSEC_GSS_BIND_CHANNEL. The seq_num field is set as if gss_proc 227 were set to RPCSEC_GSS_DATA. The service field is set to 228 rpc_gss_svc_none. The handle field is set to that of an RPCSEC_GSS 229 handle as returned by RPCSEC_GSS_INIT or RPCSEC_GSS_CONTINUE_INIT. 231 The RPCSEC_GSS_BIND_CHANNEL request is similar to the RPCSEC_GSS_DATA 232 request in that the verifiers of both contain MICs. As described in 233 Section 5.3.1 of [2], when gss_proc is RPCSEC_GSS_DATA, the verifier 234 of an RPC request is set to the output of GSS_GetMIC() on the RPC 235 header. When gss_proc is RPCSEC_GSS_BIND_CHANNEL the verifier of an 236 RPC request is set to the XDR encoding on a value of data type 237 rgss2_bind_chan_verf_args, which includes a MIC as described below. 238 The rgss2_bind_chan_verf_args data type consists of three fields: 240 o rbcva_chan_bind_prefix. This is the channel binding prefix as 241 described in [3] up to, but excluding the colon (ASCII 0x3A) that 242 separates the prefix from the suffix. 244 o rbcva_chan_bind_hash_oid. This is the object identifier (OID) of 245 the hash algorithm used to compute rbcmia_bind_chan_hash. This 246 field contains an OID encoded in ASN.1 as used by GSS-API in the 247 mech_type argument to GSS_Init_sec_context ([4]). See [5] for the 248 OIDs of the SHA one-way hash algorithms. 250 o rbcva_chan_mic. This is the output of GSS_GetMIC() on the 251 concatenation of the XDR encoded RPC header ("up to and including 252 the credential" as per [2]) and the XDR encoding of an instance of 253 type data rgss2_bind_chan_MIC_in_args. The data type 254 rgss2_bind_chan_MIC_in_args consists of one field, 255 rbcmia_bind_chan_hash, which is a hash of the channel bindings as 256 defined in [3]. The channel bindings are a "canonical octet 257 string encoding of the channel bindings", starting "with the 258 channel bindings prefix followed by a colon (ASCII 0x3A)." The 259 reason a hash of the channel bindings and not the actual channel 260 bindings are used to compute rbcva_chan_mic is that some channel 261 bindings, such as those composed of public keys, can be relatively 262 large, and thus place a higher space burden on the implementations 263 to manage. One way hashes consume less space. 265 /// enum rgss2_bind_chan_status { 266 /// RGSS2_BIND_CHAN_OK = 0, 267 /// RGSS2_BIND_CHAN_PREF_NOTSUPP = 1, 268 /// RGSS2_BIND_CHAN_HASH_NOTSUPP = 2 269 /// }; 270 /// 271 /// union rgss2_bind_chan_res switch 272 /// (rgss2_bind_chan_status rbcr_stat) { 273 /// 274 /// case RGSS2_BIND_CHAN_OK: 275 /// void; 276 /// 277 /// case RGSS2_BIND_CHAN_PREF_NOTSUPP: 278 /// rgss2_chan_pref rbcr_pref_list<>; 279 /// 280 /// case RGSS2_BIND_CHAN_HASH_NOTSUPP: 281 /// rgss2_oid rbcr_oid_list<>; 282 /// }; 283 /// 284 /// struct rgss2_bind_chan_MIC_in_res { 285 /// unsigned int rbcmr_seq_num; 286 /// opaque rbcmr_bind_chan_hash<>; 287 /// rgss2_bind_chan_res rbcmr_res; 288 /// }; 289 /// 290 /// struct rgss2_bind_chan_verf_res { 291 /// rgss2_bind_chan_res rbcvr_res; 292 /// opaque rbcvr_mic<>; 293 /// }; 294 /// 296 Figure 3 298 The RPCSEC_GSS_BIND_CHANNEL reply is similar to the RPCSEC_GSS_DATA 299 reply in that the verifiers of both contain MICs. When gss_proc is 300 RPCSEC_GSS_DATA, the verifier of an RPC reply is set to the output of 301 GSS_GetMIC() on the seq_num of the credential of the corresponding 302 request (as described in Section 5.3.3.2 of [2]). When gss_proc is 303 RPCSEC_GSS_BIND_CHANNEL, the verifier of an RPC reply is set to the 304 XDR encoding of an instance of data type rgss2_bind_chan_verf_res, 305 which includes a MIC as described below. The data type 306 rgss2_bind_chan_verf_res consists of two fields. 308 o rbcvr_res. The data type of this field is rgss2_bind_chan_res. 309 The rgss2_bind_chan_res data type is a switched union consisting 310 of three cases switched on the status contained in the rbcr_stat 311 field. 313 * RGSS2_BIND_CHAN_OK. If this status is returned, the server 314 accepted the channel bindings, and successfully verified 315 rbcva_chan_mic in the request. No additional results will be 316 in rbcvr_res. 318 * RGSS2_BIND_CHAN_PREF_NOTSUPP. If this status is returned, the 319 server did not support the prefix in the rbcva_chan_bind_prefix 320 field of the arguments, and thus the RPCSEC_GSS_BIND_CHANNEL 321 request was rejected. The server returned a list of prefixes 322 it does support in the field rbcr_pref_list. 324 * RGSS2_BIND_CHAN_HASH_NOTSUPP. If this status is returned, the 325 server did not support the hash algorithm identified in the 326 rbcva_chan_bind_hash_oid field of the arguments, and thus the 327 RPCSEC_GSS_BIND_CHANNEL request was rejected. The server 328 returned a list of OIDs of hash algorithms it does support in 329 the field rbcr_oid_list. The array rbcr_oid_list MUST have one 330 or more elements. 332 o rbcvr_mic. The value of this field is equal to the output of 333 GSS_GetMIC() on the XDR encoding of an instance of data type 334 rgss2_bind_chan_MIC_in_res. The data type 335 rgss2_bind_chan_MIC_in_res consists of three fields. 337 * rbcmr_seq_num. The value of this field is equal the field 338 seq_num in the RPCSEC_GSS credential (data type 339 rpc_gss_cred_vers_1_t). 341 * rbcmr_bind_chan_hash. This is the result of the one way hash 342 of the channel bindings (including the prefix). If rbcr_stat 343 is not RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm 344 that is used to compute rbcmr_bind_chan_hash is that identified 345 by the rbcva_chan_bind_oid_hash field in the arguments to 346 RPCSEC_GSS_BIND_CHANNEL. If rbcr_stat is 347 RGSS2_BIND_CHAN_HASH_NOTSUPP, then the hash algorithm used to 348 compute rbcmr_bind_chan_hash is that identified by 349 rbcr_oid_list[0] in the results. 351 * rbcmr_res. The value of this field is equal to the value of 352 the rbcvr_res field. 354 3.4. New Security Service - rpc_gss_svc_channel_prot 356 The rpc_gss_svc_channel_prot service (Figure 1) is valid only if 357 RPCSEC_GSSv2 is being used, an RPCSEC_GSS_BIND_CHANNEL procedure has 358 been executed successfully, and the secure channel still exists. 359 When rpc_gss_svc_channel_prot is used, the RPC requests and replies 360 are similar to those of rpc_gss_svc_none except that the verifiers on 361 the request and reply always have the flavor set to AUTH_NONE, and 362 the contents are zero length. 364 Note that even though NULL verifiers are used when 365 rpc_gss_svc_channel_prot is used, non-NULL RPCSEC_GSS credentials are 366 used. In order to identify the principal sending the request, the 367 same credential is used as before, except that service field is set 368 to rpc_gss_svc_channel_prot. 370 4. Version Negotiation 372 An initiator that supports version 2 of RPCSEC_GSS simply issues an 373 RPCSEC_GSS request with the rgc_version field set to 374 RPCSEC_GSS_VERS_2. If the target does not recognize 375 RPCSEC_GSS_VERS_2, the target will return an RPC error per section 376 5.1 of [2]. 378 The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned 379 by version 2 of a target with version 1 of the same target. The 380 initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by 381 version 1 of a target with version 2 of the same target. 383 5. Implementation Notes 385 Once a successful RPCSEC_GSS_BIND_CHANNEL procedure has been 386 performed on an RPCSEC_GSSv2 context handle, the initiator's 387 implementation may map application requests for rpc_gss_svc_none and 388 rpc_gss_svc_integrity to rpc_gss_svc_channel_prot credentials. And 389 if the secure channel has privacy enabled, requests for 390 rpc_gss_svc_privacy can also be mapped to rpc_gss_svc_channel_prot. 392 6. Acknowledgements 394 Nicolas Williams had the idea for extending RPCSEC_GSS to support 395 channel bindings. Alex Burlyga and Lars Eggert reviewed the document 396 and gave valuable feed back for improving its readability. 398 7. Security Considerations 400 The base security considerations consist of: 402 o All security considerations from [2]. 404 o All security considerations from [3]. 406 o All security considerations from the actual secure channel being 407 used. 409 Even though RPCSEC_GSS_DATA requests that use 410 rpc_gss_svc_channel_prot protection do not involve construction of 411 more GSS tokens, nonetheless, the target SHOULD stop allowing 412 RPCSEC_GSS_DATA requests with rpc_gss_svc_channel_prot protection 413 once the GSS context expires. 415 With the use of channel bindings, it becomes extremely critical that 416 the message integrity code (MIC) used by the GSS mechanism that 417 RPCSEC_GSS is using be difficult to forge. While this requirement is 418 true for RPCSEC_GSSv1, and indeed any protocol that uses GSS MICs, 419 the distinction in the seriousness is that for RPCSEC_GSSv1, forging 420 a single MIC at most allows the attacker to succeed in injecting one 421 bogus request. Whereas, with RPCSEC_GSSv2 combined with channel 422 bindings, by forging a single MIC all the attacker will succeed in 423 injecting bogus requests as long as the channel exists. An example 424 illustrates. Suppose we have an RPCSEC_GSSv1 initiator, a man in the 425 middle (MITM), an RPCSEC_GSSv1 target, and an RPCSEC_GSSv2 target. 426 The attack is as follows. 428 o The MITM intercepts the initiator's RPCSEC_GSSv1 RPCSEC_GSS_INIT 429 message and changes the version number from 1 to 2 before 430 forwarding to the RPCSEC_GSSv2 target, and changes the reply's 431 version number from 2 to 1 before forwarding to the RPCSEC_GSSv1 432 initiator. Neither the client nor the server notice. 434 o Once the RPCSEC_GSS handle is in an established state, the 435 initiator sends its first RPCSEC_GSS_DATA request. The MITM 436 constructs an RPCSEC_GSS_BIND_CHANNEL request, using the message 437 integrity code (MIC) of the RPCSEC_GSS_DATA request. It is likely 438 the RPCSEC_GSSv2 target will reject the request. The MITM 439 continues to re-iterate each time the initiator sends another 440 RPCSEC_GSS_DATA request. With enough iterations, the probability 441 of a MIC from an RPCSEC_GSS_DATA being successfully verified in 442 the forged RPCSEC_GSS_BIND_CHANNEL increases. Once the MITM 443 succeeds, it can send RPCSEC_GSS_DATA requests with a security 444 service of rpc_gss_svc_channel_prot, which does not have MICs in 445 the RPC request's verifier. 447 The implementation of RPCSEC_GSSv2 can use at least two methods to 448 thwart these attacks. 450 o The target SHOULD require a stronger MIC (e.g. if HMACs are used 451 for the MICs, require the widest possible HMAC in terms of bit 452 length that the GSS mechanism supports) when sending an 453 RPCSEC_GSS_BIND_CHANNEL request instead of an RPCSEC_GSS_DATA 454 request. If HMACs are being used, and the target expects N 455 RPCSEC_GSS_DATA requests to be sent on the context before it 456 expires, then the target SHOULD require an HMAC for 457 RPCSEC_GSS_BIND_CHANNEL that is log base 2 N bits longer than what 458 it normally requires for RPCSEC_GSS_DATA requests. If a long 459 enough MIC is not available, then the target could artificially 460 limit the number of RPCSEC_GSS_DATA requests it will allow on the 461 context before deleting the context. 463 o Each time an RPCSEC_GSSv2 target experiences a failure to verify 464 the MIC of an RPCSEC_GSS_BIND_CHANNEL request, it SHOULD reduce 465 the lifetime of the underlying GSS context, by a significant 466 fraction, thereby preventing the MITM from using the established 467 context for its attack. A possible heuristic is that the if the 468 target believes the possibility that failure to verify the MIC was 469 because of an attack is X percent, then contexts lifetime would be 470 reduced by X percent. For simplicity, an implement might set X to 471 be 50 percent, so that the context lifetime is halved on each 472 failed verification of an RPCSEC_GSS_BIND_CHANNEL request and thus 473 rapidly reduced to zero on subsequent requests. For example, with 474 a context like time of 8 hours (or 28800 seconds), 15 failed 475 attempts by the MITM would cause the context to be destroyed. 477 A method of mitigation that was considered was to protect the 478 RPCSEC_GSS version number with RPCSEC_GSSv2's RPCSEC_GSS_INIT and 479 RPCSEC_GSS_CONTINUE_INIT tokens. Thus the version number of 480 RPCSEC_GSS would be in the tokens. This method does not completely 481 mitigate the attack; it just moves the MIC guessing to the 482 RPCSEC_GSS_INIT message. In addition without changing GSS, or the 483 GSS mechanism, there is no way to include the RPCSEC_GSS version 484 number in the tokens. So for these reasons this method was not 485 selected. 487 8. IANA Considerations 489 None. 491 9. References 493 9.1. Normative References 495 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 496 Levels", RFC 2119, March 1997. 498 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 499 Specification", RFC 2203, September 1997. 501 [3] Williams, N., "On the Use of Channel Bindings to Secure 502 Channels", RFC 5056, November 2007. 504 [4] Linn, J., "Generic Security Service Application Program 505 Interface Version 2, Update 1", RFC 2743, January 2000. 507 [5] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms 508 and Identifiers for RSA Cryptography for use in the Internet 509 X.509 Public Key Infrastructure Certificate and Certificate 510 Revocation List (CRL) Profile", RFC 4055, June 2005. 512 9.2. Informative References 514 [6] Williams, N., "IPsec Channels: Connection Latching", 515 draft-ietf-btns-connection-latching-07 (work in progress), 516 April 2008. 518 [7] Williams, N., "End-Point Channel Bindings for IPsec Using IKEv2 519 and Public Keys", draft-williams-ipsec-channel-binding-01 (work 520 in progress), April 2008. 522 [8] Srinivasan, R., "RPC: Remote Procedure Call Protocol 523 Specification Version 2", RFC 1831, August 1995. 525 Author's Address 527 Mike Eisler 528 NetApp 529 5765 Chase Point Circle 530 Colorado Springs, CO 80919 531 US 533 Phone: +1-719-599-9026 534 Email: mike@eisler.com 536 Full Copyright Statement 538 Copyright (C) The IETF Trust (2008). 540 This document is subject to the rights, licenses and restrictions 541 contained in BCP 78, and except as set forth therein, the authors 542 retain all their rights. 544 This document and the information contained herein are provided on an 545 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 546 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 547 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 548 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 549 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 550 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 552 Intellectual Property 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org.