idnits 2.17.1 draft-ietf-nfsv4-ccm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2401], [RFC2743], [RFC2203]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 353 has weird spacing: '...alue of tkn_b...' == Line 448 has weird spacing: '...scribed in th...' == Line 474 has weird spacing: '...kup the corre...' == Line 747 has weird spacing: '...for the purpo...' -- 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 (May 2003) is 7651 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: 'RFC3010' is mentioned on line 117, but not defined ** Obsolete undefined reference: RFC 3010 (Obsoleted by RFC 3530) == Missing Reference: 'RFC2847' is mentioned on line 604, but not defined == Unused Reference: 'RFC3530' is defined on line 690, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) -- Obsolete informational reference (is this intentional?): RFC 1831 (Obsoleted by RFC 5531) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 3010 (ref. 'RFC3530') (Obsoleted by RFC 3530) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Eisler 3 Internet-Draft Network Appliance, Inc. 4 Document: draft-ietf-nfsv4-ccm-00.txt May 2003 6 CCM: The Credential Cache GSS Mechanism 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 ABSTRACT 32 This document describes a new mechanism under the GSS [RFC2743]. 33 Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to authenticate 34 every message transfer, thereby incurring significant overhead due to 35 the costs of cryptographic computation. While hardware-based 36 cryptographic accelerators can mitigate such overhead, it is more 37 likely that acceleration will be available for lower layer protocols, 38 such as IPsec [RFC2401] than for upper layer protocols like 39 RPCSEC_GSS. CCM can be used as a way to allow GSS mechanism- 40 independent upper layer protocols to leverage the data stream 41 protections of lower layer protocols, without the inconvenience of 42 modifying the upper layer protocol to do so. 44 TABLE OF CONTENTS 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. Overview of CCM . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Token Formats . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3.1. Mechanism Object Identifier . . . . . . . . . . . . . . . . 4 50 3.2. Context Establishment Tokens . . . . . . . . . . . . . . . . 4 51 3.2.1. Initial Context Token . . . . . . . . . . . . . . . . . . 4 52 3.2.2. Subsequent Context Tokens . . . . . . . . . . . . . . . . 6 53 3.2.2.1. Subsequent Initiator Context Initialization Token . . . 6 54 3.2.2.2. Response Token . . . . . . . . . . . . . . . . . . . . . 6 55 3.3. MIC Token . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.4. Wrap Token . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 3.5. Delete Token . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Implementation Issues . . . . . . . . . . . . . . . . . . . . 8 59 4.1. Long Tokens Versus Short Tokens . . . . . . . . . . . . . . 9 60 4.2. Initiating Contexts Via Short Tokens . . . . . . . . . . . . 9 61 4.3. Accepting Contexts Via Short Tokens . . . . . . . . . . . 10 62 4.4. Non-Token Generating GSS-API Routines . . . . . . . . . . 11 63 4.5. Minor Status Codes . . . . . . . . . . . . . . . . . . . . 11 64 5. Advice for NFSv4 Implementors . . . . . . . . . . . . . . . 11 65 6. Security Considerations . . . . . . . . . . . . . . . . . . 11 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 68 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 69 10. Informative References . . . . . . . . . . . . . . . . . . 14 70 11. Author's Address . . . . . . . . . . . . . . . . . . . . . 15 71 12. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 15 72 13. Copyright Notice . . . . . . . . . . . . . . . . . . . . . 16 74 1. Introduction 76 The GSS framework provides a general means for authenticating clients 77 and servers, as well as providing a general means for encrypting and 78 integrity protecting data exchanged during a session. GSS specifies 79 formats for a set of tokens for authentication, integrity, and 80 privacy. The formats consist of a mechanism independent form, and a 81 mechanism dependent form. An example of a set of mechanism dependent 82 forms is the Kerberos V5 mechanism definition [RFC1964]. 84 It is possible for a protocol to use GSS for one time authentication, 85 or for per message authentication. An example of the former is DAFS 86 [DAFS]. An example of the latter is RPCSEC_GSS. Obviously, it is 87 more secure to authenticate each message. On the other hand, it is 88 also more expensive. However, suppose the data stream of the upper 89 layer protocol (the layer using GSS) is protected at a lower layer 90 protocol from tampering, such as via a cryptographic checksum. If so, 91 it may not be necessary to additionally authenticate each message of 92 the upper layer protocol. Instead, it may suffice to use GSS to 93 authenticate at the beginning of the upper layer protocol's session. 95 To take advantage of one time authentication, existing consumers of 96 GSS that authenticate exclusively on each message have to change. One 97 way to change is to modify the protocol that is using GSS. This has 98 disadvantages including, introducing a protocol incompatibility, and 99 effectively introducing another authentication paradigm. Another way 100 to change, is the basis of the proposal in this document: the 101 Credential Cache Mechanism (CCM). CCM allows a GSS initiator and 102 target to bind to a security context of a non-CCM mechanism. Since 103 CCM is yet another mechanism under the GSS, the effect is that there 104 are no modifications to the protocol the GSS consumer is using. 106 2. Overview of CCM 108 CCM is a "wrapper" mechanism over the set of all other GSS-API 109 mechanisms. When CCM creates a context, it invokes an underlying 110 mechanism to create a child context. CCM determines the underlying 111 mechanism by examining the mechanism object identifier (OID) that it 112 is called with. The prefix will always be the OID of CCM, and the 113 suffix will be the OID of the underlying mechanism. The context 114 initiation and acceptance entry points of CCM wrap the resulting the 115 context tokens with a CCM header. 117 Let us use RPCSEC_GSS and NFSv4 [RFC3010] as an example. Basic 118 understanding of the RPCSEC_GSS protocol is assumed. If an NFSv4 119 client uses the wrong security mechanism, the server returns the 120 NFS4ERR_WRONGSEC error. The client can then use NFSv4's SECINFO 121 operation to ask the server which GSS mechanism to use. 123 Let us say the client and server are using Kerberos V5 [RFC1964] to 124 secure the traffic. Suppose the TCP connection NFSv4 uses is secured 125 with IPsec. It is therefore not necessary for NFSv4/RPCSEC_GSS to use 126 integrity or privacy. Fortunately, RPCSEC_GSS has an authentication 127 mode, whereby only the header of each remote procedure call and 128 response is integrity protected. So, this minimizes the overhead 129 somewhat, but there is still the cost of the headers being 130 checksummed. Since IPsec is protecting the connection, incurring even 131 that minimal per remote procedure call overhead may not be necessary. 133 Enter CCM. The server detects that the connection is protected with 134 IPsec. Via SECINFO, the client is informed that it should use 135 CCM/Kerberos V5. Via the RPCSEC_GSS protocol, the server 136 authenticates the end-user on the client with Kerberos V5. The 137 context tokens exchanged over RPCSEC_GSS are wrapped inside CCM 138 tokens. 140 3. Token Formats 142 This section discusses the protocol visible tokens that GSS consumers 143 exchange when using CCM. 145 3.1. Mechanism Object Identifier 147 The object identifier used by CCM is: 149 {iso(1)identified-organization(3)dod(6)internet(1)security(5) 150 mechanisms(5)ccm-family( Too Be Defined/Registered with IANA, 151 but at time of this writing, slot 11 was available )ccm-1(1)} 153 This object identifier is not a complete mechanism OID. Complete CCM 154 mechanism OIDs must consist of the CCM prefix OID, followed by a real 155 mechanism OID, such as that of Kerberos V5 as defined in [RFC1964]. 157 GSS defines the generic part of a token in ASN.1 encoding. GSS does 158 not require ASN.1 for the mechanism specific part of a token. 160 This document uses XDR [RFC1832] encoding for the CCM specific part 161 of each token. 163 3.2. Context Establishment Tokens 165 3.2.1. Initial Context Token 167 GSS requires that the initial context token from the initiator to the 168 target use the format as described in section 3.1 of RFC2743. The 169 format consists of a mechanism independent prefix, and a mechanism 170 dependent suffix. The mechanism independent token includes the 171 MechType field. Note that MechType must contain the prefix CCM OID 172 followed by the underlying mechanism OID. This is necessary so that 173 the target's context acceptance entry point knows that CCM is being 174 used, and which underlying mechanism is being used. 176 RFC2743 refers to the mechanism dependent token as the 177 innerContextToken. This is the CCM specific token and is defined as 178 follows, in XDR description language: 180 /* creation of CCM context via new underlying context */ 181 typedef struct { 182 opaque wrapped_token<>; 183 } CCM_wrapped_token_t; 185 typedef enum { 186 CCM_DIR_I_TO_T = 0, /* initiator to target */ 187 CCM_DIR_T_TO_I = 1 /* target to initiator */ 188 } CCM_direction_t; 190 typedef struct { 191 CCM_direction_t dir; 192 unsigned int ctx_sh_number; 194 } CCM_nonce_t; 196 /* creation of CCM context via existing underlying context */ 197 typedef struct { 198 CCM_nonce_t nonce; 199 opaque ccm_ctx_handle<>; 200 opaque mic_nonce<>; 201 } CCM_wrapped_mic_t; 203 typedef enum { 204 CCM_TKN_LONG = 0, 205 CCM_TKN_SHORT = 1 206 } CCM_tkn_type_t; 208 /* innerContextToken */ 209 typedef union switch (CCM_tkn_type_t tkn_type) { 210 case CCM_TKN_LONG: 211 CCM_wrapped_token_t long_token; 212 case CCM_TKN_SHORT: 213 CCM_wrapped_mic_t short_token; 214 } CCM_ict_t; 216 When tkn_type is CCM_TKN_LONG, the initiator is simultaneously 217 initiating a CCM context and an underlying mechanism context, thereby 218 producing a long token. A long token is the most straightforward way 219 to create a CCM context, though as will be described later, not 220 necessarily the most efficient way. The long_token's wrapped_token 221 field contains an entire InitialContextToken as generated by the 222 underlying mechanism's context initiation end point. 224 Once an initiator has established an initial CCM context with a 225 target, additional contexts can be established via the CCM_TKN_LONG 226 route or the CCM_TKN_SHORT route. The disadvantage of the 227 CCM_TKN_LONG route is that the underlying mechanism context set up 228 must be repeated, which can be time consuming. Whereas, the 229 CCM_TKN_SHORT route merely requires that the first CCM context's 230 underlying mechanism context be available to produce an integrity 231 checksum. When an application wants to use CCM over multiple 232 sessions and/or multiple connections, it can either generate long 233 tokens with each new session or connection or it can generate short 234 tokens. The short_token is computed as follows. The ccm_ctx_handle 235 is what was returned by the target in response to the creation of a 236 context from a long token request. It uniquely identifies the 237 target's previously created context. The subfield nonce.dir is set 238 to CCM_DIR_I_TO_T. The subfield nonce.ctx_sh_number is the 239 identifier of the short_token relative to the long_token that the 240 initiator is assigning. The value for ctx_sh_number is selected by 241 the initiator such that it is larger than any previous ctx_sh_number 242 for given ccm_ctx_handle. This way, the target need only keep track 243 of the largest ctx_sh_number received. The mic_nonce field is equal 244 to the output of Gss_GetMIC() as applied to the nonce field, using 245 the underlying mechanism's context. 247 3.2.2. Subsequent Context Tokens 249 A subsequent context token can be any subsequent context token from 250 the initiator context initialization entry point, or any response 251 context from the target's context acceptance entry point. The GSS 252 specification [RFC2743] does not prescribe any format. 254 3.2.2.1. Subsequent Initiator Context Initialization Token 256 The subsequent initiator context initialization token is encoded in 257 XDR and has the previously described type of type CCM_ict_t. Note 258 that the value of the field tkn_type will always be CCM_TKN_LONG in a 259 subsequent context token. 261 3.2.2.2. Response Token 263 The CCM response token, in XDR encoding is: 265 typedef enum { 266 CCM_OK = 0, 268 /* 269 * Target does not support short tokens 270 */ 271 CCM_SHORT_TKN_NOT_SUPP = 1, 273 /* 274 * ccm_ctx_handle was malformed. 275 */ 276 CCM_HANDLE_MALFORMED = 2, 278 /* 279 * GSS context corresponding to ccm_ctx_handle expired. 280 */ 282 CCM_HANDLE_EXPIRED = 3, 284 /* 285 * ccm_ctx_handle was not found. 286 */ 287 CCM_HANDLE_NOT_FOUND = 4, 289 /* 290 * The ctx_sh_number has already been received 291 * by the target. 293 */ 294 CCM_SHORT_TKN_REPLAY = 5, 296 /* 297 * The underlying mechanism had an error. 298 */ 299 CCM_UNDER_MECH_ERR = 6 300 } CCM_status_t; 302 typedef struct { 303 CCM_status_t status; 304 bool sh_tkn_supp; 305 union switch (CCM_tkn_type_t tkn_type) { 306 case CCM_TKN_LONG: 307 opaque ccm_ctx_handle<>; 308 case CCM_TKN_SHORT: 309 CCM_nonce_t nonce; 310 } tkn_body; 311 /* 312 * Either the underlying context token (CCM_TKN_LONG) or 313 * a MIC token (CCM_TKN_SHORT) of the nonce. 314 */ 315 opaque tkn_stuff<>; 316 } CCM_real_rict_t; 318 /* response token */ 319 typedef union switch (bool response_token) { 320 case TRUE: 321 CCM_real_rict_t resp; 322 case FALSE: 323 void; 324 } CCM_rict_t; 326 If a value of the status response token is CCM_OK, then the CCM 327 context has either been established on the target, or the process of 328 context establishment will continue (because the underlying 329 mechanism's context acceptance entry point returns 330 GSS_S_CONTINUED_NEEDED to the caller). The target must always set 331 the response_token boolean type to TRUE. The reason for this 332 convolution will be apparent in the section entitled "Implementation 333 Issues". 335 Support for short tokens is optional. If they are supported, then 336 sh_tkn_supp is set to TRUE, otherwise it is set to FALSE. If 337 sh_tkn_supp is FALSE, then ccm_ctx_handle should be a zero length 338 string; there's no point in returning a useful ccm_ctx_handle if 339 short tokens are not supported. 341 If the response token is in response to a long_token, then tkn_type 342 is set to CCM_TKN_LONG, and tkn_stuff is equal to the output_token as 343 returned by the underlying mechanism's context acceptance routine on 344 the target. The value of tkn_body.ccm_ctx_handle is selected such 345 that it uniquely identifies the CCM context handle, so that it can be 346 referred to for the purpose creating subsequent tokens via the 347 CCM_TKN_SHORT route. 349 If the response token is in response to a long_token, then tkn_type 350 is set to CCM_TKN_SHORT, and tkn_stuff is equal to the output of a 351 GSS_GetMIC() of tkn_body.nonce using the context the underlying 352 mechanism. The value of tkn_body.nonce.dir is set to CCM_DIR_T_TO_I. 353 The value of tkn_body.nonce.ctx_sh_number is set to the value of 354 ctx_sh_number that was in the initiator's context token. 356 3.3. MIC Token 358 This token corresponds to the PerMsgToken type as defined in section 359 3.1 of RFC2743. 361 typedef void CCM_mic_t; 363 The CCM_mic_t token is a void value because CCM performs no integrity 364 checksum. A programming API that calls GSS_GetMIC() will thus produce 365 an octet string of zero length. 367 3.4. Wrap Token 369 This token corresponds to the SealedMessage type as defined in 370 section 3.1 of RFC2743. 372 typedef opaque CCM_wrap_t<>; 374 This token is always equal to the input provided to GSS_Wrap(). 376 3.5. Delete Token 378 This token is output from GSS_Delete_sec_context(). 380 typedef opaque CCM_del_t<>; 382 This token is always equal to whatever token the underlying 383 mechanism's GSS_Delete_sec_context entry point produces. 385 4. Implementation Issues 387 The "over the wire" aspects of CCM have been completely specified. 388 However, GSS is usually implemented as an Application Programming 389 Interface (the GSS-API), and security mechanisms are often 390 implemented as modules that are plugged into the GSS-API. It is 391 useful to discuss implementation issues and workable resolutions. 392 The reader is cautioned that the author has not implemented CCM, so 393 what follows is at best a series of educated guesses. 395 4.1. Long Tokens Versus Short Tokens 397 The first time a CCM context is needed between an principal on the 398 initiator and a principal on the target, the initiator has no choice 399 but to create an underlying mechanism context via the long token 400 context exchange. Once that is done, subsequent CCM tokens between 401 the initiator and target can use short tokens. Short tokens are 402 better because with them, no more than one round trip is necessary to 403 establish a CCM context, and because the overhead of the underlying 404 mechanism context establishment is avoided. 406 4.2. Initiating Contexts Via Short Tokens 408 The key issue is how to associate an CCM established security context 409 with a new CCM context. There are no existing interfaces defined 410 existing programming language bindings of GSS-API for doing so. This 411 section suggests one possible implementation approach. 413 We will assume that GSS-API implementation is in the C programming 414 language and therefore the GSS-API C bindings [RFC2744] are being 415 used. The CCM mechanism implementation will have a table that maps 416 ccm_ctx_handle values to gss_ctx_id_t values (see section 5.19 of 417 [RFC2744]). The latter are GSS-API context handles as returned by 418 gss_init_sec_context(). The former are the context handles as 419 returned in a response token from the CCM target. In addition, each 420 CCM context has a reference to its underlying mechanism context. 422 Let us suppose the application decides it will use CCM. CCM has a 423 well known mechanism OID. The point where the initiator calls 424 GSS_Init_sec_context(), is a logical place to associate an existing 425 CCM context with a new CCM context. Here is where special CCM 426 handling is necessary in order to associate a security context with a 427 CCM context. GSS_Init_sec_context() accepts several different inputs. 428 Normally, the first time GSS_Init_sec_context() is called, the 429 input_token field is NULL. Overloading the input_token is one way to 430 associate a new CCM with the an existing CCM security context. In 431 XDR description language, we can thus imagine the following CCM 432 initial input token format: 434 typedef struct { 435 opaque context_ptr<>; 436 } CCM_initiator_bootstrap_t; 438 typedef union switch (bool response_token) { 439 case TRUE: 441 CCM_real_rict_t resp; 442 case FALSE: 443 CCM_initiator_bootstrap_t bootstrap; 444 } CCM_init_sec_context_input_token_t; 446 If this was a response token, then the response_token field will be 447 set to TRUE, and the token processed as if it came from the target as 448 described in the section entitled "Response Token". Otherwise, the 449 caller sets response_token to FALSE. The caller fills in the 450 variable length array bootstrap.context_ptr with the number of octets 451 necessary to store a pointer to a GSS-API security context. In the C 452 programming language, we would thus have something like: 454 /* 455 * What follows is not what an XDR compiler would produce, 456 * but instead is a optimal form for C programming 457 * environments. 458 */ 459 typedef struct { 460 gss_ctx_id_t context_ptr; 461 } CCM_initiator_bootstrap_t; 463 typedef struct { 464 bool response_token; 465 union { 466 CCM_status_t status; 467 CCM_initiator_bootstrap_t bootstrap; 468 } u; 469 } CCM_init_sec_context_input_token_t; 471 The CCM entry point for creating contexts on the initiator side 472 would, if being called for the first time, interpret the presence of 473 the input token as a CCM_initiator_bootstrap_t type. It uses 474 bootstrap.context_ptr to lookup the corresponding ccm_ctx_handle in 475 the aforementioned gss_ctx_id_t to ccm_ctx_handle mapping table. It 476 would then proceed to generate an output token formatted as a 477 CCM_TKN_SHORT initial context token as described in section entitled 478 "Initial Context Token". 480 The first time GSS_Init_sec_context is called, assuming success, it 481 will return GSS_S_CONTINUE_NEEDED, because it will need to process 482 the token returned by the target. The second time it is called, 483 assuming success, it will return GSS_S_COMPLETE, provided the 484 underlying mechanism also returns GSS_S_COMPLETE. 486 4.3. Accepting Contexts Via Short Tokens 488 The CCM target receives an opaque ccm_ctx_handle value as part of the 489 mechanism dependent part of initial context token. Originally, this 490 opaque handle came from the target as a result of previously creating 491 a context via a long token. If the opaque handle is still valid, 492 then the target can easily determine the original CCM context, and 493 from that, the underlying mechanism's context. With the underlying 494 context, GSS_VerifyMIC() can be invoked to verify the mic_nonce of 495 the input token, and GSS_GetMIC() can be used to generate the 496 mic_none of the output token. By comparing the ctx_sh_number in the 497 initiator's token with highest value recorded by the target, the 498 target takes care to ensure that initiator has not replayed a short 499 token. 501 4.4. Non-Token Generating GSS-API Routines 503 Since the CCM module will record the underlying mechanism's context 504 pointer in its internal data structures, this provides a simple 505 answer to what to do when GSS-API is invoked on a CCM context that 506 does not generate any tokens for the GSS peer. When CCM is called for 507 such an operation, it simply re-invokes the GSS-API call, but on the 508 recorded underlying context. 510 4.5. Minor Status Codes 512 The values defined in CCM_status_t serve as the minor status codes 513 for CCM. 515 5. Advice for NFSv4 Implementors 517 The NFSv4.0 specification does not mandate CCM, so clients and 518 servers should not insist on its use. When a server wants a client 519 to try to use CCM, it can return a NFS4ERR_WRONGSEC error to the 520 client. The client will then follow up with a SECINFO request. The 521 response to the SECINFO request should list first a CCM mechanism and 522 then the conventional security flavors the server will accept for 523 access to file object. If the client supports CCM, it will use it. 524 Otherwise, it will have to stick with a conventional flavor. 526 6. Security Considerations 528 There are many considerations for the use CCM, since it is reducing 529 security at one protocol layer in trade for equivalent security at 530 another layer. In this discussion, we will assume that cryptography 531 is being used in the application and lower protocol layers. 533 * CCM should not be used whenever the combined key 534 strength/algorithm strength of the lower protocol layer securing 535 the connection is weaker than what the underlying GSS context 536 can provide. 538 * CCM should not be used if the lower level protocol does not 539 offer comparable or superior security services to that the 540 application would achieve with GSS. For example, if the lower 541 level protocol offers integrity, but the application wants 542 privacy, then CCM is inappropriate. 544 * The use of CCM contexts over secured connections can be 545 characterized nearly secure instead of as secure as using the 546 underlying GSS context for protecting each application message 547 procedure call. The reason is that applications can multiplex 548 the traffic of multiple principals over a single connection and 549 so the ciphertext in the traffic is encrypted with multiple 550 session keys. Whereas, a secure connection method such as IPsec 551 is protected with per host session keys. Therefore, an attacker 552 has more cipher text per session key to perform cryptanalysis 553 via connections protected with IPsec, versus connections 554 protected with GSS. 556 * Related to the previous bullet, the management of private keys 557 for a secure channel is often outside the control of the user of 558 CCM. If the secure channel's private keys are compromised, then 559 all users of the secure channel are compromised. 561 * CCM contexts created during one session or transport connection 562 should not be used for subsequent sessions or transport 563 connections. In other words, full initiator to target 564 authentication should occur each time a session or transport 565 connection is established. Otherwise, there is nothing 566 preventing an attacker from using a CCM context from one 567 authenticated session or connection to trivially established 568 another, unauthenticated session or connection. For efficiency, 569 it is permissible to use a CCM context from a previous session 570 to establish another CCM context via a short token. 572 If the application protocol using CCM has no concept of a 573 session and does not use a connection oriented transport, then 574 there is no sequence of state transitions that tie the CCM 575 context creation steps with the subsequent message traffic of 576 the application protocol. Thus it can be hard to assert that 577 the subsequent message traffic is truly originated by the CCM 578 initiator's principal. For this reason, CCM is not appropriate 579 for use with applications that do not have sessions or do not 580 use connection oriented transports. 582 * The underlying secure channel should be end to end, from 583 initiator to the target. It is permissible for the user to 584 configure the underlying secure channel to not be end to end, 585 but this should only be done if user has confidence in the 586 intermediate end points. For example, suppose the application is 587 being used behind a firewall that performs network address 588 translation. It is possible to have an IPsec secure channel from 589 the initiator to the firewall, and a second secure channel from 590 the firewall to the target, but not from the initiator to the 591 target. So, if the firewall is compromised by an attacker in the 592 middle, the use of CCM to avoid per message authentication is 593 useless. Furthermore, without channel bindings, it is not 594 possible for the initiator and target to enforce end to end 595 channel security. Of course, if the initiator's node created a 596 IP-layer tunnel between it and the target, end to end channel 597 security would be achieved, but the initiator and target 598 applications would have no way of knowing that. 600 A future variant of CCM will mandate the implementation of 601 channel bindings for IPsec, SSH, and TLS, such that the session 602 keying material of each of the aforementioned three protocols 603 will be available to underlying mechanisms like Kerberos V5 and 604 SPKM [RFC2847]. This will allow an initiator and target to 605 enforce end to end channel security that cannot be compromised 606 by an attacker in the middle. This variant is not specified in 607 this document because the session-key-based channel bindings in 608 GSS-API and in specific mechanisms are not fully specified. 610 * It has been stated that it is not uncommon to find IPsec 611 deployments where multiple nodes share common private keys 612 [Black]. The use of CCM is discouraged in such environments, 613 since the compromise of one node compromises all the other nodes 614 sharing the same private key. 616 * Applications using CCM must ensure that the binding between the 617 CCM context and the secure channel is legitimate for each 618 message that references the CCM context. In other words, the 619 referenced CCM context in a message must be established in the 620 same secure channel as the message. 622 * When the same secure channel is multiplexing traffic for 623 multiple users, the initiator has to ensure the CCM context is 624 only accessible to the initiator principal that has established 625 it in the first place. One possible way to ensure that is by 626 placing CCM contexts in the privileged address space offering 627 only controlled indexed access. 629 * CCM does not unnecessarily inflate the scope of the trust 630 domain, as does for example AUTH_SYS [RFC1831] over IPSec. By 631 requiring the authentication in the CCM context initialization 632 (using a previously established context), the trust domain does 633 not extend to the client. 635 * Both the traditional mechanisms and CCM rely on the security of 636 the client to protect locally logged on users. Compromise of the 637 client impact all users on the same client. CCM does not make 638 the problem worse. 640 * The CCM context must be established over the same secure channel 641 that the subsequent message traffic will be using. This may, the 642 binding between the initial authentication and the subsequent 643 traffic is ensured. 645 7. IANA Considerations 647 Other than the registration of the CCM OID prefix, there are no IANA 648 considerations. 650 8. Acknowledgements 652 Dave Noveck, for the observation that NFS version 4 servers could 653 downgrade from integrity service to plain authentication service if 654 IPsec was enabled. David Black, Peng Dai, Sam Hartman, Julian Satran, 655 and Nicolas Williams for their critical comments. Much of the text 656 for the "Security Considerations" section comes directly from Peng. 658 9. Normative References 660 [RFC2743] 661 J. Linn, Internet RFC2743, "Generic Security Service Application 662 Program Interface Version 2, Update 1", January, 2000. 664 [RFC1832] 665 R. Srinivasan, Internet RFC1832, "XDR: External Data 666 Representation Standard", August, 1995. 668 10. Informative References 670 [RFC1831] 671 R. Srinivasan, Internet RFC1831, "RPC: Remote Procedure Call 672 Protocol Specification Version 2", August, 1995. 674 [RFC1964] 675 J. Linn, Internet RFC1964, "The Kerberos Version 5 GSS-API 676 Mechanism", June 1996. 678 [RFC2203] 679 M. Eisler, A. Chiu, L. Ling, Internet RFC2203, "RPCSEC_GSS 680 Protocol Specification", September, 1997. 682 [RFC2401] 683 S. Kent, R. Atkinson, RFC2401, "Security Architecture for the 684 Internet Protocol ", November, 1998. 686 [RFC2744] 687 J. Wray, RFC2744, "Generic Security Service API Version 2 : C- 688 bindings", January, 2000. 690 [RFC3530] 691 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 692 Eisler, D. Noveck, RFC3010, "Network File System (NFS) version 4 693 Protocol", April 2003. 695 [Black] 696 D. Black, Email message on the NFSv4 working group alias, 697 February 28, 2003. 699 [DAFS] 700 Mark Wittle (Editor), "DAFS Direct Access File System Protocol, 701 Version: 1.00", September 1, 2001. 703 11. Author's Address 705 Mike Eisler 706 5765 Chase Point Circle 707 Colorado Springs, CO 80919 708 USA 710 Phone: 719-599-9026 711 EMail: mike@eisler.com 713 12. IPR Notices 715 The IETF takes no position regarding the validity or scope of any 716 intellectual property or other rights that might be claimed to 717 pertain to the implementation or use of the technology described in 718 this document or the extent to which any license under such rights 719 might or might not be available; neither does it represent that it 720 has made any effort to identify any such rights. Information on the 721 IETF's procedures with respect to rights in standards-track and 722 standards-related documentation can be found in BCP-11. Copies of 723 claims of rights made available for publication and any assurances of 724 licenses to be made available, or the result of an attempt made to 725 obtain a general license or permission for the use of such 726 proprietary rights by implementors or users of this specification can 727 be obtained from the IETF Secretariat. 729 The IETF invites any interested party to bring to its attention any 730 copyrights, patents or patent applications, or other proprietary 731 rights which may cover technology that may be required to practice 732 this standard. Please address the information to the IETF Executive 733 Director. 735 13. Copyright Notice 737 Copyright (C) The Internet Society (2003). All Rights Reserved. 739 This document and translations of it may be copied and furnished to 740 others, and derivative works that comment on or otherwise explain it 741 or assist in its implementation may be prepared, copied, published 742 and distributed, in whole or in part, without restriction of any 743 kind, provided that the above copyright notice and this paragraph are 744 included on all such copies and derivative works. However, this 745 document itself may not be modified in any way, such as by removing 746 the copyright notice or references to the Internet Society or other 747 Internet organizations, except as needed for the purpose of 748 developing Internet standards in which case the procedures for 749 copyrights defined in the Internet Standards process must be 750 followed, or as required to translate it into languages other than 751 English. 753 The limited permissions granted above are perpetual and will not be 754 revoked by the Internet Society or its successors or assigns. 756 This document and the information contained herein is provided on an 757 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 758 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 759 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 760 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 761 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.