idnits 2.17.1 draft-ietf-nfsv4-ccm-01.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 679 has weird spacing: '...arg_ctx value...' == Line 781 has weird spacing: '...kup the corre...' == Line 1157 has weird spacing: '...ecurity assoc...' == Line 1405 has weird spacing: '...for the purpo...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Note that in the above table CCM_ERR_TKN_WRAP and CCM_ERR_TKN_VER_MIC MUST not be returned by the target. But if they are, then the initiator reports GSS_S_FAILURE. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: * CCM contexts created during one session or transport connection SHOULD not be used for subsequent sessions or transport connections. In other words, full initiator to target authentication SHOULD occur each time a session or transport connection is established. Otherwise, there is nothing preventing an attacker from using a CCM context from one authenticated session or connection to trivially establish another, unauthenticated session or connection. For efficiency, a CCM-BIND context from a previous session MAY be used to establish a CCM-MIC context. -- 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 7649 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) -- Looks like a reference, but probably isn't: '20' on line 373 == Missing Reference: 'FIPS' is mentioned on line 395, but not defined == Missing Reference: 'IKEv1' is mentioned on line 603, but not defined == Unused Reference: 'SSHv2' is defined on line 1311, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1832 (Obsoleted by RFC 4506) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) -- Duplicate reference: RFC2119, mentioned in 'RFC2409', was also mentioned in 'RFC2119'. == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-07 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-15 -- Obsolete informational reference (is this intentional?): RFC 1831 (Obsoleted by RFC 5531) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 7 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 N. Williams 5 Sun Microsystems, Inc. 6 May 2003 8 The Channel Conjunction Mechanism (CCM) for GSS 9 draft-ietf-nfsv4-ccm-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 ABSTRACT 35 This document describes a suite of new mechanisms under the GSS 36 [RFC2743]. Some protocols, such as RPCSEC_GSS [RFC2203], use GSS to 37 authenticate every message transfer, thereby incurring significant 38 overhead due to the costs of cryptographic computation. While 39 hardware-based cryptographic accelerators can mitigate such overhead, 40 it is more likely that acceleration will be available for lower layer 41 protocols, such as IPsec [RFC2401] than for upper layer protocols 42 like RPCSEC_GSS. CCM can be used as a way to allow GSS mechanism- 43 independent upper layer protocols to leverage the data stream 44 protections of lower layer protocols, without the inconvenience of 45 modifying the upper layer protocol to do so. 47 TABLE OF CONTENTS 49 1. Conventions Used in this Document . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Example Application of CCM . . . . . . . . . . . . . . . . . 4 53 3.2. A Suite of CCM Mechanisms . . . . . . . . . . . . . . . . . . 4 54 3.3. QOPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Token Formats . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4.1. Mechanism Object Identifier . . . . . . . . . . . . . . . . . 6 57 4.2. Tokens for the CCM-BIND mechanisms . . . . . . . . . . . . . 6 58 4.3. Context Establishment Tokens for CCM-BIND Mechanisms . . . . 6 59 4.3.1. Initial Context Token for CCM-BIND . . . . . . . . . . . . 7 60 4.3.2. Subsequent Context Tokens for CCM-BIND . . . . . . . . . . 7 61 4.3.2.1. Subsequent Initiator Context Initialization Token for 62 CCM-BIND . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3.2.2. Response Token for CCM-BIND . . . . . . . . . . . . . . . 7 64 4.4. MIC Token for CCM-BIND . . . . . . . . . . . . . . . . . . . 7 65 4.5. Wrap Token for CCM-BIND . . . . . . . . . . . . . . . . . . . 7 66 4.6. Other Tokens for CCM-BIND . . . . . . . . . . . . . . . . . . 8 67 4.7. Tokens for CCM-MIC . . . . . . . . . . . . . . . . . . . . . 8 68 4.8. Context Establishment Tokens for CCM-MIC . . . . . . . . . . 8 69 4.8.1. Initial Context Token for CCM-MIC . . . . . . . . . . . . . 8 70 4.8.2. Subsequent Context Tokens for CCM-MIC . . . . . . . . . . . 9 71 4.8.2.1. Subsequent Initiator Context Initialization Token for 72 CCM-MIC . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.8.2.2. Response Token for CCM-MIC . . . . . . . . . . . . . . 10 74 4.9. MIC Token for CCM-MIC . . . . . . . . . . . . . . . . . . . 12 75 4.10. Wrap Token for CCM-MIC . . . . . . . . . . . . . . . . . . 12 76 4.11. Context Deletion Token . . . . . . . . . . . . . . . . . . 12 77 4.12. Exported Context Token . . . . . . . . . . . . . . . . . . 12 78 4.13. Other Tokens for CCM-MIC . . . . . . . . . . . . . . . . . 12 79 5. GSS Channel Bindings for Common Secure Channel Protocols . . 12 80 5.1. GSS Channel Bindings for IKEv1 . . . . . . . . . . . . . . 13 81 5.2. GSS Channel Bindings for IKEv2 . . . . . . . . . . . . . . 13 82 5.3. GSS Channel Bindings for SSHv2 . . . . . . . . . . . . . . 13 83 5.4. GSS Channel Bindings for TLS . . . . . . . . . . . . . . . 13 84 6. Use of Channel Bindings with CCM-BIND and SPKM . . . . . . . 13 85 7. CCM-KEY and Anonymous IPsec . . . . . . . . . . . . . . . . . 14 86 8. Other Protocol Issues for CCM . . . . . . . . . . . . . . . . 14 87 9. Implementation Issues . . . . . . . . . . . . . . . . . . . . 15 88 9.1. Management of gss_targ_ctx . . . . . . . . . . . . . . . . 15 89 9.2. CCM-BIND Versus CCM-MIC . . . . . . . . . . . . . . . . . . 15 90 9.3. Initiating CCM-MIC Contexts . . . . . . . . . . . . . . . . 16 91 9.4. Accepting CCM-MIC Contexts . . . . . . . . . . . . . . . . 17 92 9.5. Non-Token Generating GSS-API Routines . . . . . . . . . . . 17 93 9.6. CCM-MIC and GSS_Delete_sec_context() . . . . . . . . . . . 17 94 9.7. GSS Status Codes . . . . . . . . . . . . . . . . . . . . . 18 95 9.7.1. Status Codes for CCM-BIND . . . . . . . . . . . . . . . . 18 96 9.7.2. Status Codes for CCM-MIC . . . . . . . . . . . . . . . . 18 97 9.7.2.1. CCM-MIC: GSS_Accept_sec_context() status codes . . . . 18 98 9.7.2.2. CCM-MIC: GSS_Init_sec_context() status codes . . . . . 19 99 9.8. Channel Bindings on the Target . . . . . . . . . . . . . . 20 100 10. Advice for NFSv4 Implementors . . . . . . . . . . . . . . . 21 101 11. Man in the Middle Attacks without CCM-KEY . . . . . . . . . 21 102 12. Security Considerations . . . . . . . . . . . . . . . . . . 22 103 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25 104 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 105 15. Normative References . . . . . . . . . . . . . . . . . . . . 27 106 16. Informative References . . . . . . . . . . . . . . . . . . . 28 107 17. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 108 18. IPR Notices . . . . . . . . . . . . . . . . . . . . . . . . 29 109 19. Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 29 111 1. Conventions Used in this Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Introduction 119 The GSS framework provides a general means for authenticating clients 120 and servers, as well as providing a general means for encrypting and 121 integrity protecting data exchanged during a session. GSS specifies 122 formats for a set of tokens for authentication, integrity, and 123 privacy. The formats consist of a mechanism independent form, and a 124 mechanism dependent form. An example of a set of mechanism dependent 125 forms is the Kerberos V5 mechanism definition [RFC1964]. 127 It is possible for a protocol to use GSS for one time authentication, 128 or for per message authentication. An example of the former is DAFS 129 [DAFS]. An example of the latter is RPCSEC_GSS. Obviously, it is 130 more secure to authenticate each message. On the other hand, it is 131 also more expensive. However, suppose the data stream of the upper 132 layer protocol (the layer using GSS) is protected at a lower layer 133 protocol from tampering, such as via a cryptographic checksum. If 134 so, it may not be necessary to additionally authenticate each message 135 of the upper layer protocol. Instead, it may suffice to use GSS to 136 authenticate at the beginning of the upper layer protocol's session. 138 To take advantage of one time authentication, existing consumers of 139 GSS that authenticate exclusively on each message have to change. 140 One way to change is to modify the protocol that is using GSS. This 141 has disadvantages including, introducing a protocol incompatibility, 142 and effectively introducing another authentication paradigm. Another 143 way to change, is the basis of the proposal in this document: the 144 Channel Conjunction Mechanism (CCM). CCM allows a GSS initiator and 145 target to conjunct (bind) a secure session (or channel) at one 146 protocol layer with (e.g. IPsec) a security context of a non-CCM GSS 147 mechanism. Since CCM is yet another mechanism under the GSS, the 148 effect is that there are no modifications to the protocol the GSS 149 consumer is using. 151 3. Overview 153 CCM is a "wrapper" mechanism over the set of all other GSS 154 mechanisms. When CCM creates a context, it invokes an underlying 155 mechanism to create a child context. CCM determines the underlying 156 mechanism by examining the mechanism object identifier (OID) that it 157 is called with. The prefix will always be the OID of CCM, and the 158 suffix will be the OID of the underlying mechanism. The context 159 initiation and acceptance entry points of CCM wrap the resulting the 160 context tokens with a CCM header. 162 3.1. Example Application of CCM 164 Let us use RPCSEC_GSS and NFSv4 [RFC3530] as our example. Basic 165 understanding of the RPCSEC_GSS protocol is assumed. If an NFSv4 166 client uses the wrong security mechanism, the server returns the 167 NFS4ERR_WRONGSEC error. The client can then use NFSv4's SECINFO 168 operation to ask the server which GSS mechanism to use. 170 Let us say the client and server are using Kerberos V5 [RFC1964] to 171 secure the traffic. Suppose the TCP connection NFSv4 uses is secured 172 and encrypted with IPsec. It is therefore not necessary for 173 NFSv4/RPCSEC_GSS to use integrity or privacy. Fortunately, 174 RPCSEC_GSS has an authentication mode, whereby only the header of 175 each remote procedure call and response is integrity protected. So, 176 this minimizes the overhead somewhat, but there is still the cost of 177 the headers being checksummed. Since IPsec is protecting the 178 connection, incurring even that minimal per remote procedure call 179 overhead may not be necessary. 181 Enter CCM. The server detects that the connection is protected with 182 IPsec. Via SECINFO, the client is informed that it should use 183 CCM/Kerberos V5. Via the RPCSEC_GSS protocol, the server 184 authenticates the end-user on the client with Kerberos V5. The 185 context tokens exchanged over RPCSEC_GSS are wrapped inside CCM 186 tokens. 188 3.2. A Suite of CCM Mechanisms 190 CCM consists of a suite of GSS mechanisms. CCM-NULL, CCM-ADDR, and 191 CCM-KEY bind a GSS mechanism context to a secure channel via GSS 192 channel bindings (see section 1.1.6 of RFC2743). As noted in 193 RFC2743, the purpose of channel bindings are to limit the scope 194 within which an intercepted GSS context token can be used by an 195 attacker. CCM-KEY requires the use of channel bindings that are 196 derived from the secure channel's encryption keys. CCM-ADDR requires 197 the use of channel bindings that are derived from network addresses 198 associated with the secure channel. For environments where it is not 199 feasible to use key-based channel bindings (e.g., the programming 200 interfaces to get them are not available) or address-based channel 201 bindings (e.g., the secure channel may be constructed over a path 202 that requires the use of Network Address Translation), CCM-NULL is 203 also defined. CCM-NULL requires the use of null channel bindings. 205 As discussed later in this document CCM-MIC exists for the purpose of 206 optimizing the use of CCM. 208 Implementations that claim compliance with this document are REQUIRED 209 to implement CCM-KEY and CCM-MIC. CCM-NULL and CCM-ADDR 210 implementation are OPTIONAL. Specifications that make normative 211 references to CCM are free to mandate any subset of the suite CCM 212 mechanisms. 214 Because the GSS channel bindings to IPsec [RFC2401, RFC2409, IKEv2] 215 have not been previously defined, and to ensure the usefulness of 216 CCM, they are defined in this document. 218 Also, the SPKM (1, 2 and 3) [RFC2025, RFC2847] mechanism is not clear 219 on how channel bindings work with SPKM; a simple clarification is 220 provided. 222 CCM-MIC is intended to reduce the instances of full GSS context 223 establishment to a per- {initiator principal, target} tuple. CCM-MIC 224 is used to establish a new context by proving that the initiator and 225 target both have a previously established, unexpired GSS context; the 226 proof is accomplished by exchanging MICs made with the previously 227 established GSS context. The CCM-MIC context creation entry points 228 utilize the CCM_REAL_QOP (discussed later Overview section) in the 229 value to generate and verify the MICs. The type of channel bindings 230 used when initiating CCM-MIC contexts MUST match that used when 231 creating the previously established context. 233 3.3. QOPs 235 The CCM mechanisms provide two QOPs: the default QOP (0) that amounts 236 to no protection, and a QOP (CCM_REAL_QOP, defined as value 1) that 237 maps to the default QOP of the underlying GSS mechanism. The MIC 238 tokens for CCM are zero length values. When qop_req is 0, the wrap 239 output tokens for CCM are equal to the input tokens. 241 [ XXX - We assume that applications can cope with zero length 242 MICs. We propose that implementations try and find out. We may 243 revisit this by requiring a small (8-32 bits) MIC token. 244 However, given that the C bindings of GSS allocates the MIC on 245 the heap, this could introduce an unnecessary and expensive 246 allocation, we suggest applications be fixed to deal with zero 247 length tokens. ] 249 4. Token Formats 251 This section discusses the protocol visible tokens that GSS consumers 252 exchange when using CCM. 254 4.1. Mechanism Object Identifier 256 There are two classes of Mechanism object identifiers (OIDs) for CCM. 257 The first class consists of the channel binding specific OIDs, and 258 will be referred to as the CCM-BIND mechanisms: 260 {iso(1)identified-organization(3)dod(6)internet(1)security(5) 261 mechanisms(5)ccm-family(TBD1)ccm-bind(1)ccm-null(1)} 263 {iso(1)identified-organization(3)dod(6)internet(1)security(5) 264 mechanisms(5)ccm-family(TBD1)ccm-bind(1)ccm-addr(2)} 266 {iso(1)identified-organization(3)dod(6)internet(1)security(5) 267 mechanisms(5)ccm-family(TBD1)ccm-bind(1)ccm-key(3)} 269 The above three object identifiers are not complete mechanism OIDs. 270 Complete CCM mechanism OIDs MUST consist of one of the above OIDs as 271 prefix, followed by a real mechanism OID, such as that of Kerberos V5 272 as defined in [RFC1964]. The second class consists of a single OID 273 for the CCM-MIC mechanism. 275 {iso(1)identified-organization(3)dod(6)internet(1)security(5) 276 mechanisms(5)ccm-family(TBD1)ccm-mic(2)} 278 The CCM-MIC OID is a complete mechanism OIDs, and is not a prefix. 280 GSS defines the generic part of a token in ASN.1 encoding. GSS does 281 not require ASN.1 for the mechanism specific part of a token. 283 4.2. Tokens for the CCM-BIND mechanisms 285 4.3. Context Establishment Tokens for CCM-BIND Mechanisms 287 The CCM-BIND context establishment tokens are simple wrappers around 288 a real GSS mechanism's tokens. The CCM-BIND mechanisms use the same 289 number context token exchanges as required by they underlying real 290 mechanism. 292 4.3.1. Initial Context Token for CCM-BIND 294 GSS requires that the initial context token from the initiator to the 295 target use the format as described in section 3.1 of RFC2743. The 296 format consists of a mechanism independent prefix, and a mechanism 297 dependent suffix. The mechanism independent token includes the 298 MechType field. The MechType MUST be equal to the OID of CCM-NULL, 299 CCM-ADDR, or CCM-KEY. The mechanism dependent portion of the Initial 300 Context Token is always equal to the full InitialContextToken as 301 returned by the underlying real mechanism. This will include yet 302 another MechType, which will have the underlying mechanism's OID. 304 4.3.2. Subsequent Context Tokens for CCM-BIND 306 A subsequent context token can be any subsequent context token from 307 the initiator context initialization entry point, or any response 308 context from the target's context acceptance entry point. The GSS 309 specification [RFC2743] does not prescribe any format. 311 4.3.2.1. Subsequent Initiator Context Initialization Token for CCM-BIND 313 A SubsequentContextToken for a CCM-BIND mechanism is equal to that 314 returned by the initiator's context initialization routine of the 315 underlying real mechanism. 317 4.3.2.2. Response Token for CCM-BIND 319 The response token for a CCM-BIND mechanism is equal to that returned 320 by the target's context acceptance routine of the underlying real 321 mechanism. 323 4.4. MIC Token for CCM-BIND 325 This token corresponds to the PerMsgToken type as defined in section 326 3.1 of RFC2743. When the qop_req is the default QOP (0), then the 327 PerMsgToken is a quantity zero bits in length. A programming API 328 that calls GSS_GetMIC() with the default QOP will thus produce an 329 octet string of zero length. 331 When the qop_req is CCM_REAL_QOP (1), then PerMsgToken is whatever 332 the underlying real mechanism returns from GSS_GetMIC() when passed 333 the default QOP value (0). 335 4.5. Wrap Token for CCM-BIND 337 This token corresponds to the SealedMessage type as defined in 338 section 3.1 of RFC2743. When the qop_req is the default QOP (0), 339 then the SealedMessage token is equal to the unmodified input to 340 GSS_Wrap(). 342 When the qop_req is CCM_REAL_QOP (1), then SealedMessage is whatever 343 the underlying real mechanism returns from GSS_Wrap(), when passed 344 the default QOP value (0). 346 4.6. Other Tokens for CCM-BIND 348 All other tokens are what the real underlying mechanism returns as a 349 token. 351 4.7. Tokens for CCM-MIC 353 4.8. Context Establishment Tokens for CCM-MIC 355 4.8.1. Initial Context Token for CCM-MIC 357 The initial context token from the initiator to the target uses the 358 format as described in section 3.1 of RFC2743. The format consists 359 of a mechanism independent prefix, and a mechanism dependent suffix. 360 The mechanism independent token includes the MechType field. The 361 MechType MUST be equal to the OID of CCM-MIC. RFC2743 refers to the 362 mechanism dependent token as the innerContextToken. This is the 363 CCM-MIC specific token and is XDR [RFC1832] encoded as follows, using 364 XDR description language: 366 typedef struct { 367 unsigned int ctx_sh_number; 368 unsigned int rand; 369 } CCM_nonce_t; 371 typedef struct { 372 CCM_nonce_t nonce; 373 opaque gss_targ_ctx[20]; 374 opaque chan_bindings<>; 375 } CCM_MIC_unwrapped_init_token_t; 377 /* 378 * The result of CCM_MIC_unwrapped_init_token_t after 379 * Invoking GSS_GetMIC() on it. qop_req is CCM_REAL_QOP, and 380 * conf_flag is FALSE. 381 */ 382 typedef opaque CCM_MIC_wrapped_init_token_t<>; 384 Once an initiator has established an initial CCM context with a 385 target via a CCM-BIND mechanism, the additional contexts can be 386 established via the CCM-MIC mechanism. The disadvantage of re- 387 establishing additional contexts via the CCM-BIND route is that the 388 underlying mechanism context set up must be repeated, which can be 389 expensive. Whereas, the CCM-MIC mechanism route merely requires that 390 the first CCM context's underlying mechanism context be available to 391 produce an integrity checksum. The initial context token for CCM-MIC 392 is computed as follows. 394 * The gss_targ_ctx is computed as the SHA-1 checksum of the 395 concatenation of SHA-1 [FIPS] checksums of the context tokens 396 exchanged by the CCM-BIND mechanism in the order in which they 397 were processed. For example, the context handle identifier for a 398 CCM-KEY context exchange over a Kerberos V5 context exchange 399 would be: SHA-1( { SHA-1(CCM-KEY's initiator's token), SHA- 400 1(CCM-KEY's target's token)) }. Since the SHA-1 standard 401 mandates a 160 bit output, (20 octets), gss_targ_ctx is a fixed 402 length, 20 octet string. 404 * The subfield nonce.rand is set a random or pseudo random value. 405 It is provided so as to ensure more variability of the the mic 406 that GSS will calculate when CCM_MIC_unwrapped_init_token_t is 407 GSS_Wrap()ed into CCM_MIC_wrapped_init_token_t. 409 * The subfield nonce.ctx_sh_number is the identifier of the CCM- 410 MIC context relative to the CCM-BIND context (as identified by 411 gss_targ_ctx) that the initiator is assigning. The value for 412 ctx_sh_number is selected by the initiator such that it is 413 larger than any previous ctx_sh_number for the given 414 gss_targ_ctx. This way, the target need only keep track of the 415 largest ctx_sh_number received. Once ctx_sh_number has reached 416 the maximum value for an unsigned 32 bit integer, the given 417 gss_targ_ctx can no longer be used. 419 * Once the above fields are calculated, GSS_Wrap() is performed on 420 the CCM_MIC_unwrapped_init_token_t value, to produce a 421 CCM_MIC_wrapped_init_token_t value that becomes the initial 422 context token to send to the target. 424 4.8.2. Subsequent Context Tokens for CCM-MIC 426 A subsequent context token can be any subsequent context token from 427 the initiator context initialization entry point, or any response 428 context from the target's context acceptance entry point. The GSS 429 specification [RFC2743] does not prescribe any format. 431 4.8.2.1. Subsequent Initiator Context Initialization Token for CCM-MIC 433 As CCM-MIC has only one round trip for context token exchange, there 434 are no subsequent initiator context tokens. 436 4.8.2.2. Response Token for CCM-MIC 438 The CCM response token, in XDR encoding is: 440 typedef enum { 441 CCM_OK = 0, 443 /* 444 * gss_targ_ctx was malformed. 445 */ 446 CCM_ERR_HANDLE_MALFORMED = 1, 448 /* 449 * GSS context corresponding to gss_targ_ctx expired. 450 */ 452 CCM_ERR_HANDLE_EXPIRED = 2, 454 /* 455 * gss_targ_ctx was not found. 456 */ 457 CCM_ERR_HANDLE_NOT_FOUND = 3, 459 /* 460 * The ctx_sh_number has already been received 461 * by the target. Or the maximum ctx_sh_number has 462 * been previously received. 463 */ 464 CCM_ERR_TKN_REPLAY = 4, 466 /* 467 * Channel binding type mismatch between CCM-BIND context 468 * and the CCM-MIC initial context. 469 */ 470 CCM_ERR_CHAN_MISMATCH = 5, 472 /* 473 * The GSS_Unwrap() failed on initial context token 474 */ 475 CCM_ERR_TKN_UNWRAP = 6, 477 /* 478 * The GSS_GetMIC() called failed on the target(). 479 */ 481 CCM_ERR_TKN_GET_MIC = 7, 483 /* 484 * The GSS_Wrap() failed on the initiator. Not reported 485 * by target. 486 */ 488 CCM_ERR_TKN_WRAP = 8, 490 /* 491 * The GSS_VerifyMIC() failed on the initiator. Not 492 * reported by target. 493 */ 495 CCM_ERR_TKN_VER_MIC = 9 497 } CCM_MIC_status_t; 499 /* 500 * GSS errors returned by the underlying mechanism 501 */ 502 typedef struct { 503 unsigned int gss_major; 504 unsigned int gss_minor; 505 } CCM_MIC_real_gss_err_t; 507 /* 508 * The response context token for CCM-MIC. 509 */ 510 typedef union switch (CCM_MIC_status status) { 511 case CCM_OK: 512 opaque mic_init_tkn<>; 513 case CCM_ERR_TKN_UNWRAP: 514 case CCM_ERR_TKN_GET_MIC: 515 CCM_real_gss_err_t gss_err; 516 default: 517 void; 518 } CCM_MIC_resp_t; 520 If a value of the status field is CCM_OK, then the CCM-MIC context 521 has been established on the target. The field mic_init_tkn is equal 522 to the output of GSS_GetMIC() (qop_req is CCM_REAL_QOP (1)) on the 523 entire and original token that came from the initiator. In other 524 words, the input_token value to GSS_Accept_sec_context(). This is 525 necessary because the inner token from the initiator is wrapped with 526 GSS_Wrap(), and thus contains a MIC. If we performed GSS_GetMIC() on 527 the unwrapped inner token, then for some underlying mechanisms, we 528 would end up with a mic_init_tkn in the response token equal to what 529 was embedded in the request token. 531 If the status field is CCM_ERR_TKN_UNWRAP or CCM_ERR_TKN_GET_MIC, 532 then gss_err.gss_major and gss_err.minor are set to the major and 533 minor GSS statuses as returned by GSS_Unwrap() or GSS_GetMIC(). The 534 values for the gss_major field are as defined in [RFC2744]. The 535 values for the gss_minor field are both mechanism dependent and 536 mechanism implemented dependent. They are nonetheless potentially 537 useful as debugging aids. 539 4.9. MIC Token for CCM-MIC 541 The MIC token for CCM-MIC is the same as the MIC token for CCM-BIND. 543 4.10. Wrap Token for CCM-MIC 545 The wrap token for CCM-MIC is the same as the wrap token for CCM- 546 BIND. 548 4.11. Context Deletion Token 550 The context deletion token for CCM-MIC is a zero length token. 552 4.12. Exported Context Token 554 The Exported context token for CCM-MIC is implementation defined. 556 4.13. Other Tokens for CCM-MIC 558 All other tokens are the same as corresponding tokens for CCM-BIND. 560 5. GSS Channel Bindings for Common Secure Channel Protocols 562 For CCM-KEY to be useful and secure, CCM-KEY MUST be used in 563 conjunction with channel bindings to bind GSS authentication at the 564 application layer to a lower layer in the network that provides 565 cryptographic session protection. 567 To date only network address type channel bindings have been defined 568 for GSS [RFC2743]. But the GSS also allows for channel bindings of 569 "transformations of encryption keys" [RFC2743]. The actual generic 570 representation of channel bindings is defined in the C-Bindings of 571 the GSS-API [RFC2744]. 573 Modern secure transports generally define some quantity or quantities 574 which are either derived from the session keys (or from key exchange 575 material) or which are securely exchanged in such a way that both 576 peers of any one connection or association can arrive at the same 577 derived quantities, while a man-in-the-middle cannot make these 578 quantities match for both peers. Signatures of these quantities can 579 be exchanged to prove that there is no man-in-the-middle (because a 580 man-in-the-middle cannot cause them to be the same for both peers). 581 These quantities correspond to what the GSS terms "transformations of 582 encryption keys" that are referred to in [RFC2743]. 584 Where a secure transport clearly defines a session identifier 585 securely derived from session keys or key exchange material, that 586 identifier MUST be used as the GSS channel bindings data when CCM- 587 BIND is used to bind GSS to that transport. 589 This section defines four forms of "transformations of encryption 590 keys," one for IKEv1, one for IKEv2, one for SSHv2 and one for TLS. 591 All four forms are to be used as the value of the "application_data" 592 field of the gss_channel_bindings_struct type defined in [RFC2744]. 594 5.1. GSS Channel Bindings for IKEv1 596 IKEv1 does not define a single value which can be used -- by both the 597 IPsec initiator and responder of an IPsec SA -- to identify a given 598 SA. IKEv1 does, however, define public values derived from the IKEv1 599 key exchange: 'HASH_I' and 'HASH_R'. 601 For IKEv1, the GSS channel bindings data to use with CCM-KEY consists 602 of the concatenation of HASH_I and HASH_R octet string values, in 603 that order, from the underlying IPsec session being bound to [IKEv1]. 605 5.2. GSS Channel Bindings for IKEv2 607 IKEv2 peers assign and exchange 8-octet "Security Parameters Index" 608 (SPI) values, such that a pair of SPIs suffices to uniquely identify 609 a given IPsec security association. 611 For IKEv2 the GSS channel bindings data to use with CCM-KEY is simply 612 the concatenation of the SPIi and SPIr values, in that order, which 613 identify the IPsec SA being bound to. 615 5.3. GSS Channel Bindings for SSHv2 617 SSHv2 defines a session ID derived from the initial key exchange of 618 an SSHv2 connection; this value is not secret and is the same for 619 both the client and the server for any given connection. 621 For SSHv2 the GSS channel bindings data for use with CCM-KEY consists 622 of the SSHv2 session ID. 624 5.4. GSS Channel Bindings for TLS 626 XXX - This section is To Be Defined. 628 6. Use of Channel Bindings with CCM-BIND and SPKM 630 Whereas the Kerberos V5 mechanism specification [RFC1964] is quite 631 detailed with respect to the use of GSS channel bindings, the same is 632 not true for SPKM, which merely provides a field named "channelId" 633 for passing channel bindings data, as octet strings, from initiators 634 to acceptors. No interpretation is given in RFC2025 for the value of 635 the channelId field. Therefore SPKM requires some clarification to 636 be usable with channel bindings and CCM-KEY: The channelId field of 637 SPKM Context-Data ASN.1 structure MUST be set to the checksum of the 638 channel bindings data that is defined for the Kerberos V5 mechanism 639 [RFC1964], using SHA-1 instead of MD5 as the hash algorithm. 641 [Note: This checksum can be computed independently of the GSS 642 language bindings used by the application, even though RFC1964 643 references the C-Bindings of the GSS-API [RFC2744] in the 644 construction of this checksum (read the RFC1964 text carefully).] 646 7. CCM-KEY and Anonymous IPsec 648 For sites that do not use IPsec, but use Kerberos V5, SPKM, or 649 LIPKEY, deploying IPsec, a PKI infrastructure and certificates for 650 use with IKE may prove quite difficult to deploy just for secure 651 application (e.g., NFS) performance improvements. Such sites could 652 avoid the need to deploy a PKI and certificates to all clients and 653 server by using "anonymous IPsec" for the application (e.g., NFS 654 with/ RPCSEC_GSS) and CCM-KEY. 656 Though there is no such thing as "anonymous IPsec," the effect can be 657 achieved by using self-signed certificates. 659 By using anonymous IPsec with the application and CCM-KEY, the full 660 benefit of offloading session cryptography from upper layer protocol 661 layer to the IP layer can be had without having to deploy an 662 authentication infrastructure for IPsec. 664 8. Other Protocol Issues for CCM 666 CCM-BIND is a trivial mechanism, and normally will return the same 667 major status code as the underlying real mechanism, including 668 GSS_S_COMPLETE as returned by GSS_Init_sec_context(). However, the 669 first time GSS_Init_sec_context is called on a CCM-BIND mechanism, if 670 the underlying real mechanism returns GSS_S_COMPLETE, CCM-BIND's 671 GSS_Init_sec_context() entry point MUST return GSS_S_CONTINUE_NEEDED 672 to the caller. This way, the initiator will receive another context 673 token from the target, even if the underlying real mechanism context 674 set up is done. The CCM-BIND initiator will need to record state 675 that indicates that the underlying mechanism has reached a completely 676 established state (and so is uninterested in any token the target 677 returns). This way, the initiator can process every token produced 678 by the target's GSS_Accept_sec_context() routine and so calculate 679 gss_targ_ctx value that matches that of the target. 681 9. Implementation Issues 683 The "over the wire" aspects of CCM have been completely specified. 684 However, GSS is usually implemented as an Application Programming 685 Interface (the GSS-API), and security mechanisms are often 686 implemented as modules that are plugged into the GSS-API. It is 687 useful to discuss implementation issues and workable resolutions. 688 The reader is cautioned that the authors have not implemented CCM, so 689 what follows is at best a series of educated guesses. 691 9.1. Management of gss_targ_ctx 693 The gss_targ_ctx value is computed by the initiator and target based 694 on SHA-1 computations of the CCM-BIND context tokens. There is a 695 space/time trade off between the initiator and target storing the 696 sequence of context tokens until needed by CCM-BIND, versus computing 697 the SHA-1 checksums and then disposing of the context tokens when 698 CCM-BIND no longer needs them. If it is likely there will be CCM-MIC 699 contexts created for the CCM-BIND context, and if the sequence of 700 context tokens requires more space than a 20 octet SHA-1 value, then 701 the tradeoff is obvious. 703 Since the bit space of all possible sequences of CCM-BIND context 704 tokens is larger than the 160 bit space of possible SHA-1 checksums, 705 in theory two or more different CCM-BIND contexts will produce 706 produce the same SHA-1 context, and thus for CCM-MIC context 707 initiation, there will be ambiguity as to which CCM-BIND context the 708 initiator is binding to. The target can resolve this ambiguity by 709 attempting to unwrap the inner context token from the CCM-MIC 710 initiator for each matching CCM-BIND context. In theory no more than 711 one GSS_Unwrap() attempt for each matching CCM-BIND context will 712 succeed. If multiple succeed, then clearly the underlying mechanism 713 is doing poor job at generating "unique" session keys. CCM 714 implementations that detect this SHOULD log it so that the problem in 715 the underlying mechanism can be discovered and fixed. 717 9.2. CCM-BIND Versus CCM-MIC 719 The first time a CCM context is needed between an principal on the 720 initiator and a principal on the target, the initiator has no choice 721 but to create an underlying mechanism context via a CCM-BIND context 722 token exchange. Once that is done, subsequent CCM contexts between 723 the initiator and target can be created via CCM-MIC. CCM-MIC context 724 establishment is better because no more than one round trip is 725 necessary to establish a CCM context, and because the overhead of the 726 establishing a real, underlying mechanism context is avoided. 728 9.3. Initiating CCM-MIC Contexts 730 The key issue is how to associate an CCM-BIND established security 731 context with a new CCM-MIC context, There no existing interfaces 732 defined in the GSS-API for associating one GSS context with another. 733 This then is the key issue for implementations of CCM-MIC. 735 We will assume that GSS-API implementation is in the C programming 736 language and therefore the GSS-API C bindings [RFC2744] are being 737 used. The CCM mechanism implementation will have a table that maps 738 gss_targ_ctx values to gss_ctx_id_t values (see section 5.19 of 739 [RFC2744]). The latter are GSS-API context handles as returned by 740 gss_init_sec_context(). The former are the context handles as 741 returned in a response token from the CCM target. In addition, each 742 CCM context has a reference to its underlying mechanism context. 744 Let us suppose the application decides it will use CCM-MIC. CCM-MIC 745 has a well known mechanism OID which the application can check for. 746 The point where the initiator calls GSS_Init_sec_context(), is a 747 logical place to associate an existing CCM-BIND context with a new 748 CCM-MIC context. Here is where special CCM handling is necessary in 749 order to associate a security context with a CCM context. We discuss 750 several approaches. 752 1. The first approach is for the CCM-MIC's GSS_Init_sec_context() 753 entry point to pass as the claimant_cred_handle the 754 output_context_handle as returned by GSS_Init_sec_context() for 755 a previously created CCM-BIND context. Such an approach may 756 work well with applications that normally pass 757 GSS_C_NO_CREDENTIAL as the claimant_cred_handle. 759 2. The second approach derives from the observation that normally, 760 the first time GSS_Init_sec_context() is called, the input_token 761 field is NULL and the initial context_handle (type gss_ctx_id_t) 762 is also NULL. The input_token is supposed to be the token 763 received from the target's context acceptance routine, which has 764 the XDR type CCM_MIC_resp_t. Overloading the input_token is one 765 way. By passing in a non-null input_token, and a NULL pointer 766 to the context_handle (using the C bindings calling conventions 767 for gss_init_sec_context()), this will tell the CCM-MIC 768 initiator that input_token containing information to to 769 associate a new CCM-MIC context with an existing CCM-BIND 770 context. In the C programming language, we could thus have have 771 input_token containing: 773 typedef struct { 774 gss_ctx_id_t context_ptr; 775 } CCM_MIC_initiator_bootstrap_t; 777 The CCM entry point for creating contexts on the initiator side 778 would, if being called for the first time (*context_handle is 779 NULL), interpret the presence of the input token with an invalid 780 status as the CCM_MIC_initiator_bootstrap_t. It would use 781 context_ptr to lookup the corresponding gss_targ_ctx in the 782 aforementioned gss_ctx_id_t to gss_targ_ctx mapping table. It 783 would then proceed to generate an output token encoded as XDR 784 type CCM_MIC_init_t, described in the section entitled "Initial 785 Context Token for CCM-MIC". 787 Regardless of the approach taken, the first time GSS_Init_sec_context 788 is called, assuming success, it will return GSS_S_CONTINUE_NEEDED, 789 because it will need to process the token returned by the target. 790 The second time it is called, assuming success, it will return 791 GSS_S_COMPLETE. 793 9.4. Accepting CCM-MIC Contexts 795 The CCM-MIC target receives an opaque gss_targ_ctx value as part of 796 the mechanism dependent part of the initial context token. 797 Originally, this opaque handle came from the target as a result of 798 previously creating a context via a CCM-BIND context exchange. If 799 the opaque handle is still valid, then the target can easily 800 determine the original CCM-BIND context, and from that, the CCM-BIND 801 mechanism's context. With the underlying context, GSS_VerifyMIC() 802 can be invoked (with a qop_req of CCM_REAL_QOP (1)) to verify the 803 mic_nonce of the input token, and GSS_GetMIC() can be used to 804 generate the mic_init_tkn field of the output token. By comparing 805 the ctx_sh_number in the initiator's token with highest value 806 recorded by the target, the target takes care to ensure that 807 initiator has not replayed a short token. 809 9.5. Non-Token Generating GSS-API Routines 811 Since the CCM module will record the underlying mechanism's context 812 pointer in its internal data structures, this provides a simple 813 answer to what to do when GSS-API is invoked on a CCM context that 814 does not generate any tokens for the GSS peer. When CCM is called 815 for such an operation, it simply re-invokes the GSS-API call, but on 816 the recorded underlying context. 818 9.6. CCM-MIC and GSS_Delete_sec_context() 820 The CCM-MIC entry point for GSS_Delete_sec_context() should not call 821 the underlying mechanism's GSS_Delete_sec_context() routine. If it 822 did, this would effectively delete all CCM-MIC context's associating 823 with the same underlying mechanism. 825 9.7. GSS Status Codes 827 9.7.1. Status Codes for CCM-BIND 829 CCM-BIND mechanisms define no minor status codes. If the underlying 830 mechanism is not available, then a CCM-BIND mechanism will return 831 GSS_S_BAD_MECH and minor status of zero. Otherwise, it will return 832 whatever major and minor status codes the underlying mechanism 833 returns. 835 9.7.2. Status Codes for CCM-MIC 837 Generally, major and minor status codes for will be whatever major 838 and minor status codes the underlying CCM-BIND mechanism returns. 839 However, for GSS_Init_sec_context() and GSS_Accept_sec_context(), 840 this is not the case because the those operations are invoking 841 routines (GSS_Wrap() and GSS_Unwrap()) that have major statuses that 842 are not subsets of the legal status returns from 843 GSS_Init_sec_context() and GSS_Accept_sec_context(). Moreover, in 844 some cases for GSS_Init_sec_context(), the minor and major status are 845 driven from the target, and the target's codes will not always be 846 among the legal set for GSS_Init_sec_context(). 848 9.7.2.1. CCM-MIC: GSS_Accept_sec_context() status codes 850 The minor status code for GSS_Accept_sec_context is always from the 851 set defined in the CCM_MIC_status_t type. If GSS_Unwrap() reports a 852 major status failure, then the minor status will be 853 CCM_ERR_TKN_UNWRAP, and the reported major status will what 854 GSS_Unwrap() reports, with exceptions as according to the following 855 table: 856 major status code from GSS_Unwrap major status code reported 857 by GSS_Accept_sec_context 858 to caller. 859 ----------------------------------------------------------------- 860 GSS_S_BAD_SIG GSS_S_BAD_SIG 861 GSS_S_CONTEXT_EXPIRED GSS_S_DEFECTIVE_TOKEN 862 GSS_S_GAP_TOKEN GSS_S_DEFECTIVE_TOKEN 863 GSS_S_UNSEQ_TOKEN GSS_S_DUPLICATE_TOKEN 865 If GSS_GetMIC() reports a major status failure, then the minor status 866 will be CCM_ERR_TKN_GET_MIC, and the reported major status will be 867 what GSS_GetMIC() reports, with exceptions as according to the 868 following table: 869 major status code from GSS_GetMIC major status code reported 870 by GSS_Accept_sec_context() 871 to caller. 873 ------------------------------------------------------------------ 874 GSS_S_BAD_QOP GSS_S_FAILURE 875 GSS_S_CONTEXT_EXPIRED GSS_S_DEFECTIVE_TOKEN 877 The target will always report the actual GSS major and minor codes to 878 the initiator. The initiator will map the GSS major code as 879 described in the next subsection. 881 9.7.2.2. CCM-MIC: GSS_Init_sec_context() status codes 883 The minor status code for GSS_Init_sec_context is always from the set 884 defined in the CCM_MIC_status_t type. 886 If the minor status code came from the target, then that will always 887 be what GSS_Init_sec_context() reports. The most of the minor codes 888 from the target are to be mapped to the major status code as follows: 889 minor status code major status code 890 from target reported to caller of 891 GSS_Init_sec_context() 892 ---------------------------------------------------- 893 CCM_OK GSS_S_COMPLETE 894 CCM_ERR_HANDLE_MALFORMED GSS_S_DEFECTIVE_TOKEN 895 CCM_ERR_HANDLE_EXPIRED GSS_S_CREDENTIALS_EXPIRED 896 CCM_ERR_HANDLE_NOT_FOUND GSS_S_CREDENTIALS_EXPIRED 897 CCM_ERR_TKN_REPLAY GSS_S_DUPLICATE_TOKEN 898 CCM_ERR_CHAN_MISMATCH GSS_S_BAD_BINDINGS 899 CCM_ERR_TKN_WRAP GSS_S_FAILURE 900 CCM_ERR_TKN_VER_MIC GSS_S_FAILURE 902 Note that in the above table CCM_ERR_TKN_WRAP and CCM_ERR_TKN_VER_MIC 903 MUST not be returned by the target. But if they are, then the 904 initiator reports GSS_S_FAILURE. 906 If the minor status code from the target is CCM_ERR_TKN_UNWRAP or 907 CCM_ERR_TKN_GET_MIC, then the target will also report the major 908 status code it got from GSS_Unwrap() or GSS_GetMIC(). The major 909 status from the target will be be reported by GSS_Init_sec_context() 910 to its caller with exceptions as according to the following table: 911 major status code from target major status code reported 912 by GSS_Init_sec_context() 913 to caller 914 ----------------------------------------------------------------- 915 GSS_S_BAD_QOP GSS_S_FAILURE 916 GSS_S_BAD_SIG GSS_S_BAD_SIG 917 GSS_S_CONTEXT_EXPIRED GSS_S_DEFECTIVE_TOKEN 918 GSS_S_GAP_TOKEN GSS_S_DEFECTIVE_TOKEN 919 GSS_S_UNSEQ_TOKEN GSS_S_DUPLICATE_TOKEN 921 If GSS_Wrap() fails on the initiator, then the minor status will be 922 CCM_ERR_TKN_WRAP, and the major status will what GSS_Wrap() reports, 923 with exceptions as according to the following table: 924 major status code from GSS_Wrap major status code reported 925 by GSS_Init_sec_context() 926 to caller 927 --------------------------------------------------------------- 928 GSS_S_CONTEXT_EXPIRED GSS_S_DEFECTIVE_TOKEN 929 or 930 GSS_S_DEFECTIVE_CREDENTIAL 932 GSS_S_BAD_QOP GSS_S_FAILURE 934 If GSS_VerifyMIC() fails on the initiator, then the minor status will 935 be CCM_ERR_TKN_VER_MIC, and the major status will what 936 GSS_VerifyMIC() reports, with exceptions as according to the 937 following table: 938 major status code from GSS_VerifyMIC major status code reported 939 by GSS_Init_sec_context() 940 to caller 941 --------------------------------------------------------------- 942 GSS_S_CONTEXT_EXPIRED GSS_S_DEFECTIVE_TOKEN 943 GSS_S_GAP_TOKEN GSS_S_DEFECTIVE_TOKEN 944 GSS_S_UNSEQ_TOKEN GSS_S_DUPLICATE_TOKEN 946 9.8. Channel Bindings on the Target 948 When an application invokes GSS_Accept_sec_context() on a CCM token, 949 it won't know if channel bindings are required or not. Of course, it 950 could inspect the OID of the input_token and determine the channel 951 bindings directly if it is a CCM-BIND token, but normally 952 applications will not parse the mechanism OID in an input token. And 953 in any case, such inspection for a CCM-MIC token provides no 954 information about channel bindings to the target application. 956 The application on the target will have to try 957 GSS_Accept_sec_context() without channel bindings. If the target CCM 958 mechanism requires channel bindings (as indicated by the 959 GSS_S_BAD_BINDINGS), then the application will have to re-invoke 960 GSS_Accept_sec_context() with the right channel bindings. If the 961 channel bindings are the wrong type, then the CCM mechanism will 962 indicate GSS_S_BAD_BINDINGS again. The application will have to 963 iterate through all the valid types of bindings. The application can 964 avoid this iteration if the bindings includes both, address and key 965 bindings if at all possible. The CCM mechanisms should use only 966 those parts of the application-provided bindings that they care for. 968 10. Advice for NFSv4 Implementors 970 The NFSv4.0 specification does not mandate CCM, so clients and 971 servers should not insist on its use. When a server wants a client 972 to try to use CCM, it can return a NFS4ERR_WRONGSEC error to the 973 client. The client will then follow up with a SECINFO request. The 974 response to the SECINFO request should list first the CCM-BIND 975 mechanisms it supports, second the CCM-MIC mechanism (if supported), 976 and finally, the conventional security flavors the server will accept 977 for access to file object. If the client supports CCM, it will use 978 it. Otherwise, it will have to stick with a conventional flavor. 980 Since the CCM-MIC OID is general, rather than a separate CCM-MIC OID 981 for every real mechanism, the NFS server will have be careful to make 982 sure that a CCM-MIC context is authorized access an object. For 983 example suppose /export is exported such that SPKM-3 is the 984 authorized underlying mechanism, and CCM-NULL + SPKM-3 and CCM-MIC 985 are similarly authorized to access /export. Suppose CCM-NULL is 986 created over a Kerberos V5 context, and then CCM-MIC is used to 987 derived a context from the CCM-NULL context. If the NFS server 988 simply records that the OID of CCM-MIC is authorized to access 989 /export, then Kerberos V5 authenticated users will be mistakenly 990 allowed access. Instead, the server needs to examine what context 991 the CCM-MIC context is associated with, and check that context's OID 992 against the authorized list of OIDs for /export. 994 11. Man in the Middle Attacks without CCM-KEY 996 In this example, NFS with/ RPCSEC_GSS will be the application, and 997 IPsec the secure channel. 999 Man in the middle (MITM) avoidance means making sure that the client 1000 and server are the same at both layers, NFS and IPsec, but since the 1001 principal names at the one layer will be radically different from the 1002 names at the other, how can one be certain that there is no MITM at 1003 the IPsec layer before leaving it to IPsec to provide session 1004 protection to the NFS layer? The answer is to use channel bindings, 1005 which, conceptually, are an exchange, at the NFS/GSS layer, of 1006 signatures of the principal names or session ID/keys involved at the 1007 IPsec layer. 1009 Consider an attacker who can cause a client's IPsec stack to 1010 establish an SA with the attacker, instead of the server intended by 1011 the NFS layer (this is accomplished by spoofing the DNS server). 1012 Suppose further that the attacker can fool the client's IPsec layer 1013 without also fooling its NFS/RPCSEC_GSS layer (for example, if 1014 Kerberos V5 is being used as the real mechanism, and avoids the use 1015 of DNS to canonicalize the server principal name -- admittedly, this 1016 avoidance is unlikely -- a DNS spoof attack will be detected by the 1017 NFS client, because the Kerberos Key Distribution Center (KDC) 1018 generates tickets associated with pairs of principals, not host 1019 names). Suppose that the attacker's host is in part of the site's 1020 IPsec infrastructure (perhaps the attacker broke into that host). 1021 Then the attacker might be able to act as a MITM between the client 1022 and the server who gets all the plain text and even gets to modify 1023 it, if CCM-NULL is wrapping Kerberos V5 at the RPCSEC_GSS level. 1024 Both, the client and the server would see that IPsec is in use 1025 between them, but they would each see a different ID for its IPsec 1026 peer. Channel bindings are used to prove that the client and server 1027 each see the same two peer names at the lower (in this case, IPsec) 1028 layer, and therefore with CCM-KEY there is no MITM. 1030 DNSSEC would of course defeat the attack, but DNSSEC was not, at the 1031 time this document was written, in widespread use. 1033 12. Security Considerations 1035 There are many considerations for the use CCM, since it is reducing 1036 security at one protocol layer in trade for equivalent security at 1037 another layer. In this discussion, we will assume that cryptography 1038 is being used in the application and lower protocol layers. 1040 * CCM should not be used whenever the combined key 1041 strength/algorithm strength of the lower protocol layer securing 1042 the connection is weaker than what the underlying GSS context 1043 can provide. 1045 * CCM should not be used if the lower level protocol does not 1046 offer comparable or superior security services to that the 1047 application would achieve with GSS. For example, if the lower 1048 level protocol offers integrity, but the application wants 1049 privacy, then CCM is inappropriate. 1051 * The use of CCM contexts over secured connections can be 1052 characterized nearly secure instead of as secure as using the 1053 underlying GSS context for protecting each application message 1054 procedure call. The reason is that applications can multiplex 1055 the traffic of multiple principals over a single connection and 1056 so the ciphertext in the traffic is encrypted with multiple 1057 session keys. Whereas, a secure connection method such as IPsec 1058 is protected with per host session keys. Therefore, an attacker 1059 has more cipher text per session key to perform cryptanalysis 1060 via connections protected with IPsec, versus connections 1061 protected with GSS. 1063 * Related to the previous bullet, the management of private keys 1064 for a secure channel is often outside the control of the user of 1065 CCM. If the secure channel's private keys are compromised, then 1066 all users of the secure channel are compromised. 1068 * CCM contexts created during one session or transport connection 1069 SHOULD not be used for subsequent sessions or transport 1070 connections. In other words, full initiator to target 1071 authentication SHOULD occur each time a session or transport 1072 connection is established. Otherwise, there is nothing 1073 preventing an attacker from using a CCM context from one 1074 authenticated session or connection to trivially establish 1075 another, unauthenticated session or connection. For efficiency, 1076 a CCM-BIND context from a previous session MAY be used to 1077 establish a CCM-MIC context. 1079 If the application protocol using CCM has no concept of a 1080 session and does not use a connection oriented transport, then 1081 there is no sequence of state transitions that tie the CCM 1082 context creation steps with the subsequent message traffic of 1083 the application protocol. Thus it can be hard to assert that 1084 the subsequent message traffic is truly originated by the CCM 1085 initiator's principal. For this reason, CCM SHOULD NOT be used 1086 with applications that do not have sessions or do not use 1087 connection oriented transports. 1089 * The underlying secure channel SHOULD be end to end, from 1090 initiator to the target. It is permissible for the user to 1091 configure the underlying secure channel to not be end to end, 1092 but this should only be done if user has confidence in the 1093 intermediate end points. For example, suppose the application 1094 is being used behind a firewall that performs network address 1095 translation. It is possible to have an IPsec secure channel 1096 from the initiator to the firewall, and a second secure channel 1097 from the firewall to the target, but not from the initiator to 1098 the target. So, if the firewall is compromised by an attacker 1099 in the middle, the use of CCM to avoid per message 1100 authentication is useless. Furthermore, without channel 1101 bindings mandated by CCM-KEY, it is not possible for the 1102 initiator and target to enforce end to end channel security. Of 1103 course, if the initiator's node created a IP-layer tunnel 1104 between it and the target, end to end channel security would be 1105 achieved, but without the use of CCM-KEY, the initiator and 1106 target applications would have no way of knowing that. 1108 * It has been stated that it is not uncommon to find IPsec 1109 deployments where multiple nodes share common private keys 1110 [Black]. The use of CCM is discouraged in such environments, 1111 since the compromise of one node compromises all the other nodes 1112 sharing the same private key. 1114 * Applications using CCM MUST ensure that the binding between the 1115 CCM context and the secure channel is legitimate for each 1116 message that references the CCM context. In other words, the 1117 referenced CCM context in a message MUST be established in the 1118 same secure channel as the message. The use of CCM-KEY enforces 1119 this binding. 1121 * When the same secure channel is multiplexing traffic for 1122 multiple users, the initiator has to ensure the CCM context is 1123 only accessible to the initiator principal that has established 1124 it in the first place. One possible way to ensure that is by 1125 placing CCM contexts in the privileged address space offering 1126 only controlled indexed access. 1128 * CCM does not unnecessarily inflate the scope of the trust 1129 domain, as does for example AUTH_SYS [RFC1831] over IPSec. By 1130 requiring the authentication in the CCM context initialization 1131 (using a previously established context), the trust domain does 1132 not extend to the client. 1134 * Both the traditional mechanisms and CCM rely on the security of 1135 the client to protect locally logged on users. Compromise of 1136 the client impacts all users on the same client. CCM does not 1137 make the problem worse. 1139 * The CCM context MUST be established over the same secure channel 1140 that the subsequent message traffic will be using. This way, 1141 the binding between the initial authentication and the 1142 subsequent traffic is ensured. Again, the use of CCM-KEY is one 1143 way to assert this binding. 1145 * The section entitled "CCM-KEY and Anonymous IPsec", suggests a 1146 method for simulating anonymous IPsec via self-signed 1147 certificates. If one is careless, this is will neuter all IPsec 1148 authentication, a real problem for those applications not using 1149 CCM-KEY. The use of the self-signed certificates in IPsec 1150 should be restricted by port in the IPsec Security Policy 1151 Database (SPD) only to those application using CCM-KEY. Note 1152 however, that port selector support is OPTIONAL in IPsec. 1154 * If an application is using IPsec and is not using CCM-KEY, then 1155 then the site where the application is deployed should configure 1156 the IPsec SPD to carefully limit the ports and nodes that are 1157 allowed create security associations to application targets. 1159 * CCM-KEY's IPsec bindings use public SA information, and CCM- 1160 ADDR's bindings are simply public network addresses. If the 1161 secure channel is IPsec, and non-anonymous certificates are used 1162 with IKE, then a MITM cannot spoof the target's and initiator's 1163 IP addresses, because the attacker will presumably be unable to 1164 spoof the Certificate Authority that signed the certificates. 1165 Thus, when IPsec is used as the secure channel, and non- 1166 anonymous certificates are used with IKE, CCM-ADDR is as secure 1167 as CCM-KEY. 1169 * CCM contexts should not be used forever without re- 1170 authenticating periodically via the underlying mechanism. One 1171 rational approach is for the CCM context to persist no longer 1172 than the underlying mechanism context. Implementing this via 1173 the GSS-API is simple. Applications can periodically invoke 1174 gss_context_time() to find out how long the context will be 1175 valid. Moreover, CCM can enforce this by invoking 1176 gss_context_time() and the system time of day API to get an 1177 expiration date when the CCM mechanism is established. Each 1178 subsequent call can check the time of day against the 1179 expiration, and if expired, return GSS_S_CONTEXT_EXPIRED. 1181 13. IANA Considerations 1183 XXX Note 1 to IANA: The CCM-BIND mechanism OID prefixes and the CCM- 1184 MIC mechanism OID must be assigned and registered by IANA. Please 1185 look for TBD1 in this document and notify the RFC Editor what value 1186 you have assigned. 1188 XXX Note 1 to RFC Editor: When IANA has made the OID assignments, 1189 please do the following: 1191 * Delete the "XXX Note 1 to RFC Editor: ..." paragraph. 1193 * Replace occurrences of TBD1 with the value assigned by IANA. 1195 * Replace the "XXX Note 1 to IANA: ..." paragraph with: 1196 OIDs for the CCM-BIND mechanism prefix, and for the CCM-MIC 1197 mechanism have been assigned by, and registered with IANA, 1198 with this document as the reference. 1200 XXX Note 2 to IANA: Please assign RPC flavor numbers for values 1201 currently place held in this document as TBD2 through TBD10. Also 1202 please establish the registry that RFC2623 mandates. 1204 XXX Note 2 to RFC Editor: When IANA has made the RPC flavor number 1205 assignments, please do the following: 1207 * Delete the "XXX Note 2 to RFC Editor: ..." paragraph. 1209 * Replace occurrences of TBD2 through and including TBD10 withe 1210 flavor number assignments from IANA. 1212 Section 6, "IANA Considerations" of [RFC2623] established a registry 1213 for mapping GSS mechanism OIDs to RPC pseudo flavor numbers. This 1214 registry was augmented in the NFSv4 specification [RFC3530] with 1215 several more entries. This document adds the following entries to 1216 the registry: 1218 1 == number of pseudo flavor 1219 2 == name of pseudo flavor 1220 3 == mechanism's OID 1221 4 == quality of protection 1222 5 == RPCSEC_GSS service 1224 1 2 3 4 5 1225 -------------------------------------------------------------- 1226 TBD2 ccm-mic 1.3.6.1.5.5.TBD1.2 0 rpc_gss_svc_none 1228 TBD3 ccm-null-krb5 1.3.6.1.5.5.TBD1.1.1. 0 rpc_gss_svc_none 1229 1.2.840.113554.1.2.2 1231 TBD4 ccm-addr-krb5 1.3.6.1.5.5.TBD1.1.2. 0 rpc_gss_svc_none 1232 1.2.840.113554.1.2.2 1234 TBD5 ccm-key-krb5 1.3.6.1.5.5.TBD1.1.3. 0 rpc_gss_svc_none 1235 1.2.840.113554.1.2.2 1237 TBD6 ccm-null-spkm3 1.3.6.1.5.5.TBD1.1.1. 0 rpc_gss_svc_none 1238 1.3.6.1.5.5.1.3 1240 TBD6 ccm-addr-spkm3 1.3.6.1.5.5.TBD1.1.2. 0 rpc_gss_svc_none 1241 1.3.6.1.5.5.1.3 1243 TBD7 ccm-key-spkm3 1.3.6.1.5.5.TBD1.1.3. 0 rpc_gss_svc_none 1244 1.3.6.1.5.5.1.3 1246 TBD8 ccm-null-lipkey 1.3.6.1.5.5.TBD1.1.1. 0 rpc_gss_svc_none 1247 1.3.6.1.5.5.1.3 1249 TBD9 ccm-addr-lipkey 1.3.6.1.5.5.TBD1.1.2. 0 rpc_gss_svc_none 1250 1.3.6.1.5.5.1.3 1252 TBD10 ccm-addr-lipkey 1.3.6.1.5.5.TBD1.1.3. 0 rpc_gss_svc_none 1253 1.3.6.1.5.5.1.3 1255 14. Acknowledgements 1257 Dave Noveck, for the observation that NFS version 4 servers could 1258 downgrade from integrity service to plain authentication service if 1259 IPsec was enabled. David Black, Peng Dai, Sam Hartman, and Julian 1260 Satran, for their critical comments. Much of the text for the 1261 "Security Considerations" section comes directly from David and Peng. 1263 15. Normative References 1265 [RFC1832] 1266 R. Srinivasan, RFC1832, "XDR: External Data Representation 1267 Standard", August, 1995. 1269 [RFC2025] 1270 C. Adams, RFC2025: "The Simple Public-Key GSS-API Mechanism 1271 (SPKM)," October 1996, Status: Standards Track. 1273 [RFC2119] 1274 S. Bradner, RFC2119, "Key words for use in RFCs to Indicate 1275 Requirement Levels," March 1997. 1277 [RFC2401] 1278 S. Kent, R. Atkinson, RFC2401, "Security Architecture for the 1279 Internet Protocol ", November, 1998. 1281 [RFC2409] 1282 D. Harkins and D. Carrel, RFC2119: "The Internet Key Exchange 1283 (IKE)," November 1998. 1285 [RFC2743] 1286 J. Linn, RFC2743, "Generic Security Service Application Program 1287 Interface Version 2, Update 1", January, 2000. 1289 [RFC2744] 1290 J. Wray, RFC2744, "Generic Security Service API Version 2 : C- 1291 bindings", January, 2000. 1293 [RFC2847] 1294 M. Eisler, RFC2847: "LIPKEY - A Low Infrastructure Public Key 1295 Mechanism Using SPKM," June 2000, Status: Standards Track. 1297 [FIPS]U.S. Department of Commerce / National Institute of Standards 1298 and Technology, FIPS PUB 180-1, "Secure Hash Standard", May 11, 1299 1993. 1301 [IKEv2] 1302 C. Kaufman, draft-ietf-ipsec-ikev2-07.txt: "Internet Key 1303 Exchange (IKEv2) Protocol," A work in progress, April 2003. 1305 XXX - Note 3 to RFC Editor: In the event this work in progress 1306 is not approved for publication when the CCM document is, then 1307 the sections of the CCM document that refer to IKEv2 in a 1308 normative manner are to be removed for submission as a separate 1309 document. 1311 [SSHv2] 1312 T. Ylonen et. al., draft-ietf-secsh-transport-15.txt: "SSH 1313 Transport Layer Protocol," A work in progress, September 2002. 1315 XXX - Note 4 to RFC Editor: In the event this work in progress 1316 is not approved for publication when the CCM document is, then 1317 the sections of the CCM document that refer to SSHv2 in a 1318 normative manner are to be removed for submission as a separate 1319 document. 1321 16. Informative References 1323 [RFC1831] 1324 R. Srinivasan, RFC1831, "RPC: Remote Procedure Call Protocol 1325 Specification Version 2", August, 1995. 1327 [RFC1964] 1328 J. Linn, RFC1964, "The Kerberos Version 5 GSS-API Mechanism", 1329 June 1996. 1331 [RFC2203] 1332 M. Eisler, A. Chiu, L. Ling, RFC2203, "RPCSEC_GSS Protocol 1333 Specification", September, 1997. 1335 [RFC2623] 1336 M. Eisler, RFC2623, "NFS Version 2 and Version 3 Security Issues 1337 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", June 1338 1999. 1340 [RFC3530] 1341 S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. 1342 Eisler, D. Noveck, RFC3530, "Network File System (NFS) version 4 1343 Protocol", April 2003. 1345 [Black] 1346 D. Black, EMail message on the NFSv4 working group alias, 1347 February 28, 2003. 1349 [DAFS] 1350 Mark Wittle (Editor), "DAFS Direct Access File System Protocol, 1351 Version: 1.00", September 1, 2001. 1353 17. Authors' Addresses 1355 Mike Eisler 1356 5765 Chase Point Circle 1357 Colorado Springs, CO 80919 1358 USA 1360 Phone: 719-599-9026 1361 EMail: mike@eisler.com 1363 Nicolas Williams 1364 Sun Microsystems, Inc. 1365 5300 Riata Trace CT 1366 Austin, TX 78727 1367 USA 1369 EMail: nicolas.williams@sun.com 1371 18. IPR Notices 1373 The IETF takes no position regarding the validity or scope of any 1374 intellectual property or other rights that might be claimed to 1375 pertain to the implementation or use of the technology described in 1376 this document or the extent to which any license under such rights 1377 might or might not be available; neither does it represent that it 1378 has made any effort to identify any such rights. Information on the 1379 IETF's procedures with respect to rights in standards-track and 1380 standards-related documentation can be found in BCP-11. Copies of 1381 claims of rights made available for publication and any assurances of 1382 licenses to be made available, or the result of an attempt made to 1383 obtain a general license or permission for the use of such 1384 proprietary rights by implementors or users of this specification can 1385 be obtained from the IETF Secretariat. 1387 The IETF invites any interested party to bring to its attention any 1388 copyrights, patents or patent applications, or other proprietary 1389 rights which may cover technology that may be required to practice 1390 this standard. Please address the information to the IETF Executive 1391 Director. 1393 19. Copyright Notice 1395 Copyright (C) The Internet Society (2003). All Rights Reserved. 1397 This document and translations of it may be copied and furnished to 1398 others, and derivative works that comment on or otherwise explain it 1399 or assist in its implementation may be prepared, copied, published 1400 and distributed, in whole or in part, without restriction of any 1401 kind, provided that the above copyright notice and this paragraph are 1402 included on all such copies and derivative works. However, this 1403 document itself may not be modified in any way, such as by removing 1404 the copyright notice or references to the Internet Society or other 1405 Internet organizations, except as needed for the purpose of 1406 developing Internet standards in which case the procedures for 1407 copyrights defined in the Internet Standards process must be 1408 followed, or as required to translate it into languages other than 1409 English. 1411 The limited permissions granted above are perpetual and will not be 1412 revoked by the Internet Society or its successors or assigns. 1414 This document and the information contained herein is provided on an 1415 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1416 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1417 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1418 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1419 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.