idnits 2.17.1 draft-rfced-exp-markham-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 865 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 43 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** There are 6 instances of lines with control characters in the document. ** The abstract seems to contain references ([SG98], [DM97]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '... aware implementations MUST be able to...' RFC 2119 keyword, line 92: '... implementations SHOULD be able to int...' RFC 2119 keyword, line 120: '...very information SHOULD be bound to th...' RFC 2119 keyword, line 122: '..., the binding mechanism used SHOULD be...' RFC 2119 keyword, line 125: '...d to meet these requirements SHOULD be...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9385 days in the past. Is this intentional? 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: 'DM99' is mentioned on line 211, but not defined == Unused Reference: 'Atk95a' is defined on line 638, but no explicit reference was found in the text == Unused Reference: 'Atk95b' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'DoD85' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RA95' is defined on line 659, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1826 (ref. 'Atk95a') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'Atk95b') (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'CW98' -- Possible downref: Non-RFC (?) normative reference: ref. 'DoD85' == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'DM97') -- Possible downref: Non-RFC (?) normative reference: ref. 'DP98' -- Possible downref: Non-RFC (?) normative reference: ref. 'RA95' -- Possible downref: Non-RFC (?) normative reference: ref. 'SG98' Summary: 14 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT 2 Key Recovery Alliance TMarkham 3 INTERNET DRAFT Secure Computing Corporation 4 Catagory: Experimental August 1998 6 ISAKMP Key Recovery Extensions 7 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Distribution of this document is unlimited. 31 This contribution has been prepared to assist the Key Recovery Alliance. 32 This proposal is made by the authors as a basis of discussion. This 33 contribution should not be construed as a binding proposal on the 34 authors or their companies. Specifically, the authors and their 35 companies reserve the right to amend or modify the statements contained 36 herein. 38 Comments on this document should be sent to key-recovery@raleigh.ibm.com. 40 Table of Contents 42 1. Introduction 43 2. Requirements, Goals And Issues 44 3. Typical Use 45 4. Acknowledgments 46 5. References 47 6. Security Considerations 48 7. Author Information 49 8. Appendix - Proposed DOI Values 50 9. Full Copyright Statement 52 1. INTRODUCTION 54 ABSTRACT 56 This document describes the proposed approach for negotiating and 57 exchanging key recovery information within the Internet Security 58 Association Key Management Protocol (ISAKMP). 60 This document describes the method for transmitting the Common Key 61 Recovery Block (CKRB) when two entities establish a security association 62 using ISAKMP [DM97]. ISAKMP is used to negotiate the mechanism to carry 63 key recovery information carried within the CKRB as specified in [SG98]. 65 Section 2, Requirements, Goals And Issues, provides background 66 information on the technical approach and rational. 68 Section 3, Typical Use provides information on the Key Recovery 69 Mechanism (KRM) negotiation and use of the ISAKMP notify to carry the 70 CKRB. 72 Section 4, Acknowledgments 74 Section 5, References 76 Section 6, Author information 78 2. REQUIREMENTS, GOALS AND ISSUES 80 This section explains the proposed approach and rational for inserting 81 key recovery into ISAKMP. 83 2.1 Requirements and Goals 85 The following have been identified as requirements or goals for key 86 recovery within the context of ISAKMP. 88 o Interoperability: The key recovery mechanisms must allow 89 interoperability to the greatest extent allowed by the applicable 90 security policies. Key recovery aware implementations MUST be able to 91 interoperate with other key recovery aware implementations. Non-key 92 recovery aware implementations SHOULD be able to interoperate with key 93 recovery aware implementations. 95 o Business requirements: The key recovery mechanism must allow 96 organizations to comply with government regulations with respect to 97 the use of encryption. The mechanism must also allow an organization 98 to defend its business practices by monitoring intra- and 99 inter-organization communications within legal limits. This requires 100 that the organization must be able to intercept the CKRB at the time of 101 key establishment or periodically while the security association 102 remains active. This requires that the key recovery enabled entity 103 transmit the CKRB during the key establishment protocol and every N 104 hours during the security association. 106 o Government Requirements: Governments must be able to intercept the 107 CKRB at the time of key establishment or periodically while the 108 security association remains active. This requires that the key 109 recovery enabled entity transmit the CKRB during the key establishment 110 protocol and every N hours during the security association. 112 o ISAKMP compatibility: The key recovery approach must maintain 113 compatibility with ISAKMP. 115 o Security: The key recovery mechanisms must negligibly reduce the 116 strength of the cryptographic system. 118 2.2 Issues 120 o Subvertability: The key recovery information SHOULD be bound to the 121 ISAKMP negotiation in a way which makes it difficult to subvert the 122 key recovery function. However, the binding mechanism used SHOULD be 123 no stronger than necessary to meet the reasonable business and 124 Government evaluation criteria. Mechanisms which increase complexity 125 and cost beyond what is required to meet these requirements SHOULD be 126 avoided. 128 o Changing IETF ISAKMP: The IETF ISAKMP is not an RFC yet. 129 The key recovery mechanism must be reviewed as ISAKMP evolves. 131 2.3 Requirements Terminology 133 In this document, the words that are used to define the significance 134 of each particular requirement are usually capitalized. These words 135 are: 137 - MUST 139 This word or the adjective "REQUIRED" means that the item is an 140 absolute requirement of the specification. 142 - SHOULD 144 This word or the adjective "RECOMMENDED" means that there might 145 exist valid reasons in particular circumstances to ignore this 146 item, but the full implications should be understood and the case 147 carefully weighed before taking a different course. 149 - MAY 151 This word or the adjective "OPTIONAL" means that this item is 152 truly optional. One vendor might choose to include the item 153 because a particular marketplace requires it or because it 154 enhances the product, for example; another vendor may omit the 155 same item. 157 3. KEY RECOVERY WITHIN ISAKMP 159 3.1 Overview 161 The CKRB [SG98] may be passed across the network using two methods in 162 the ISAKMP/IPSEC environment. When key recovery is required and ISAKMP 163 is used, the CKRB MAY be transmitted in the ISAKMP notify message. 164 When key recovery is required and ISAKMP is not used, the CKRB MUST be 165 transmitted in the IPSEC Key Recovery Header (KRH). 167 ISAKMP will be used to negotiate the use of the KRM in much the same 168 way that the use of AH and ESP are negotiated. Two entities will 169 negotiate and pick a proposal which may include AH, ESP and the KRM. 170 The peer ISAKMP MUST always be notified when key recovery will be 171 applied to the IPSEC security association. Key recovery is not applied 172 to the ISAKMP Phase I security association. Some policies may allow ISAKMP to 173 negotiate the use of weaker cryptography (e.g., 40 bit) if the peer 174 device rejects the proposal(s) to do key recovery. 176 The values for the KRMs are defined in the IPSEC key recovery DOI. (A 177 draft version of the proposed DOI values are included as an appendix 178 to this document.) The KR negotiation addresses the following 179 parameters independently for initiator and responder; 181 - Key Recovery Mechanism: This is a security association 182 attribute. Example KRMs include IBM, Cylink, TIS, Any (key 183 recovery is required but any mechanism recognized by policy is 184 accepted), or none (no key recovery). 186 - KRH Interval: The KRH protocol is a header similar in concept to 187 AH. The KRH protocol is described in [CW98]. The 188 negotiation includes the interval, in seconds, at which the KRH 189 will be sent. A value of zero indicates that the KRH will never be 190 sent. 192 This negotiation and transmission of the CKRB only occurs within the 193 context of an ISAKMP phase 2 exchange. Key recovery is not applied to 194 ISAKMP phase 1 exchanges. 196 3.2 Exchange of CKRBs in ISAKMP 198 The ISAKMP proposal negotiation process allows the initiator to create 199 an ordered set of proposals. The responder is required to pick from 200 one of these proposals or send a message indicating that all proposals 201 were rejected. There are many permutations of sender and receiver 202 policies/implementations which affect interoperability. The key 203 recovery negotiation is actually a pair of negotiations due to the 204 asymmetric nature of key recovery. The initiator sends the responder 205 two sets of proposals. One proposal addresses what key recovery, if 206 any, the initiator will do. The other addresses what key recovery, if 207 any, the responder will do. 209 This subsection outlines multiple cases of exchanging the byte 210 oriented CKRB within the ISAKMP phase 2 exchange. Please see the ISAKMP 211 specification [DM99] for complete information on the negotiation 212 process. The integrity mechanisms to protect the CKRB are negotiated as 213 part of the negotiation to determine the KRM to be used. 215 The exchanges of interest are: 217 - Initiator does key recovery but responder does not 218 - Initiator does not do key recovery but responder does 219 - Initiator and responder do key recovery 221 Two entities which MUST perform key recovery could fail to negotiate 222 a security exchange if the KRM negotiation fails. A device which is 223 key recovery unaware cannot prevent the peer device from sending a 224 CKRB. The examples below provide an overview of the exchange 225 process. Detailed protocol information is contained in subsection 226 3.2.4 - Security Association and Attributes 3.2.5 - Security Protocol. 228 3.2.1 Initiator does key recovery but responder does not 230 In this example assume the initiator MUST do key recovery and the 231 responder will not issue a CKRB but will communicate with initiators 232 which issue CKRBs. 234 1. The initiator creates two ordered sets of proposals. The initiator 235 must do key recovery so all of the proposals which apply to the 236 initiator contain the KRM(s) as part of the proposed suite(s). The set 237 of proposals which apply to the responder contain key recovery and 238 non-key recovery options. These proposals are sent to the responder. 240 2. The responder picks one proposal to be applied to the initiator and 241 one proposal to be applied to the responder. If none of the initiator 242 proposals are accepted or none of the responder proposals are 243 accepted, the responder sends the initiator an error message 244 indicating the reason for the rejection. 246 The responder may not understand the proposals because of the KRM. If 247 this occurs, the initiator MAY omit the KRM from the proposals and 248 simply exchange the CKRB within the ISAKMP notify message. The 249 initiator is responsible for ensuring the lifetime of the security 250 association conforms to local policy. 252 NOTE: This could lead to situations in which key recovery is 253 supported without the explicit consent of the responder. 254 Implementations which MUST NOT support key recovery MUST terminate 255 the security association when a CKRB is received. 257 3. The initiator completes the ISAKMP exchange and sets the commit bit 258 within the ISAKMP header. This informs the responder that it must not 259 use the newly created security association until the initiator sends 260 an informational exchange carrying the notify payload indicating the 261 security association may be used. 263 4. The responder completes the ISAKMP exchange and waits for the 264 notify from the initiator. 266 5. The initiator prepares the notify payload containing the CKRBs. One 267 CKRB contains the initiator to responder key and the other CKRB contains 268 the responder to initiator key. The notify message value indicates 269 that the security association may now be used. The initiator sets the 270 encryption bit/flag to 0, indicating that the payload is not 271 encrypted, and sends this notify payload to the responder. The message 272 will be protected by the ISAKMP authentication mechanism but it will 273 not be encrypted. The authentication prevents undetected tampering 274 with the contents of the CKRBs yet allows the CKRBs to be intercepted. 275 This notify message SHOULD NOT contain payloads which require 276 confidentiality protection. 278 6. Both initiator and responder may use the security association when 279 the responder receives and processes the notify message. If the notify 280 message has been corrupted, the responder performs the standard ISAKMP 281 processing. 283 The setting and resetting of the commit bit by multiple protocols 284 within a single device is the local responsibility of that device. 285 For example, if both key recovery and ESP within the initiating device 286 set the commit bit, the logic within the initiating device determines 287 when the notify message may be sent to clear the commit bit. 289 3.2.2 Initiator does not do key recovery but responder does 291 In this example assume the initiator is not key recovery aware but the 292 responder must issue a CKRB. The responder is allowed to communicate 293 with initiators which do not issue CKRBs. 295 1. The initiator creates an ordered set of proposals. The initiator is 296 not key recovery aware so none of the proposals contain the KRM as 297 part of the proposed suite. These proposals are sent to the responder. 299 2. The responder picks one of the proposals and informs the initiator 300 which proposal was accepted. If none of the proposals are accepted, 301 the responder sends the initiator an error message indicating the 302 reason for the rejection. 304 The responder sets the commit bit within the ISAKMP header sent to the 305 initiator. This prevents use of the security association until after 306 the responder has transmitted the CKRB. The responder is responsible for 307 ensuring the lifetime of the security association conforms to local 308 policy. 310 3. The initiator completes the ISAKMP exchange and waits for the 311 notify payload from the responder. 313 4. The responder completes the ISAKMP exchange and sends the notify 314 payload containing the CKRBs. One CKRB contains the initiator to 315 responder key and the other CKRB contains the responder to initiator 316 key. The notify message value indicates that the security association 317 may now be used. The responder sets the encryption bit/flag to 0, 318 indicating that the payload is not encrypted, and sends this notify 319 payload to the initiator. The message will be protected by the ISAKMP 320 authentication mechanism but it will not be encrypted. The 321 authentication prevents undetected tampering with the contents of the 322 CKRBs yet allows the CKRBs to be intercepted. This notify message SHOULD 323 NOT contain payloads which require confidentiality protection. 325 NOTE: This could lead to situations in which key recovery is 326 supported without the explicit consent of the initiator. 327 Implementations which MUST NOT support key recovery MUST terminate 328 the security association when a CKRB is received. 330 5. Both initiator and responder may use the security association when 331 the initiator receives and processes the notify message. 333 3.2.3 Initiator and responder do key recovery 335 In this example assume both the initiator and responder do key 336 recovery. 338 1. The initiator creates two ordered sets of proposals. The initiator 339 must do key recovery so all of the proposals which apply to the 340 initiator contain the KRM as part of the proposed suite. The proposals 341 which apply to the responder allow the responder the option of doing 342 key recovery or not. These proposals are sent to the responder. 344 2. The responder picks one of the initiator proposals and one of the 345 responder proposals and informs the initiator which proposals were 346 accepted. If none of the initiator proposals or none of the responder 347 proposals are accepted, the responder sends the initiator an error 348 message indicating the reason for the rejection. 350 3. The initiator completes the ISAKMP exchange and sets the commit bit 351 within the ISAKMP header. This informs the responder that it must not 352 use the newly created security association until the initiator sends 353 an informational exchange carrying the notify payload indicating the 354 security association may be used. 356 4. The responder completes the ISAKMP exchange and also sets the 357 commit bit within the ISAKMP header sent to the initiator. This 358 prevents use of the security association until after the responder has 359 transmitted the CKRB. 361 5. The initiator prepares the notify payload containing the CKRBs. One 362 CKRB contains the initiator to responder key and the other CKRB contains 363 the responder to initiator key. The initiator sends both CKRBs even if 364 the responder is also performing key recovery. The notify message 365 value indicates that the initiator is ready to use the security 366 association. 368 The initiator sets the encryption bit/flag to 0, indicating that the 369 payload is not encrypted, and sends this notify payload to the 370 responder. The message will be protected by the ISAKMP authentication 371 mechanism but it will not be encrypted. 373 6. The responder sends the notify payload containing the CKRBs. One 374 CKRB contains the initiator to responder key and the other CKRB contains 375 the responder to initiator key. The responder sets the encryption 376 bit/flag to 0, indicating that the payload is not encrypted, and sends 377 this notify payload to the initiator. The message will be protected by 378 the ISAKMP authentication mechanism but it will not be encrypted. 380 The notify message value indicates that the security association is 381 cleared for use by the responder. Both initiator and responder are 382 able to use the security association when the initiator receives and 383 processes the notify message. 385 3.2.4 - Security Association Attributes 387 The key recovery mechanism to be used by each party is negotiated using 388 the Security Association payload, Proposal payload, Transform payload, 389 Security Association attribute field. The example in Figure 1 below shows 390 a proposal for a combined protection suite with two different protocols. 391 The first protocol is presented with two transforms supported by the 392 proposer. The second protocol is presented with a single transform. An 393 example for this proposal might be: Protocol 1 is ESP with Transform 1 as 394 3DES using key recovery as defined in the SA Attributes and Transform 2 as 395 40 bit RC4 with no key recovery AND Protocol 2 is AH with Transform 1 as 396 SHA. 398 Figure 1 shows the example values for the transform ID and key recovery 399 related fields. The attribute flag and attribute type consume 16 400 bits. The DOI value for the KRM uses basic encoding so it fits in 16 401 bits. In this example, there is no key recovery attribute associated 402 with the 40 bit RC4 transform. 404 The responder MUST select from the two transforms proposed for ESP. The 405 resulting protection suite will be either (1) 3DES (with key recovery) AND 406 SHA OR (2) 40 bit RC4 (no key recovery) AND SHA, depending on which ESP 407 transform was selected by the responder. Note this example is shown using 408 the Base Exchange. 410 1 2 3 411 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 412 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 / ! NP = Nonce ! RESERVED ! Payload Length ! 414 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 SA Pay ! Domain of Interpretation (DOI) ! 416 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 \ ! Situation ! 418 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 / ! NP = Proposal ! RESERVED ! Payload Length ! 420 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans =2 ! 422 \ ! ! ESP ! ! ! 423 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 \ ! SPI (variable) ! 425 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 / ! NP = Transform! RESERVED ! Payload Length ! 427 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 429 \ ! ! 3DES ! ! 430 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | ! SA Attributes ! 432 | !A! Attribute Type ! AF=1 Attribute Value ! 433 | !F! Initiator Key Recovery ! DOI value of KRM ! 434 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 \ !A! Attribute Type ! AF=1 Attribute Value ! 436 \!F! Responder Key Recovery ! DOI value of KRM ! 437 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 / ! NP = 0 ! RESERVED ! Payload Length ! 439 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 441 \ ! ! RC4 40 ! ! 442 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 \ ! SA Attributes ! 444 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 / ! NP = 0 ! RESERVED ! Payload Length ! 446 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 448 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 \ ! SPI (variable) ! 450 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 / ! NP = 0 ! RESERVED ! Payload Length ! 452 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 454 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 \ ! SA Attributes ! 456 \+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 1. Example payload containing key recovery attributes. 460 The protocol allows key recovery attributes to be associated with AH 461 (proposal 1, protocol 2 in the example above). This could be used to allow 462 an intermediate device such as a firewall to authenticate packets without 463 decrypting them. If an organization uses this feature, the CKRB intended 464 for the firewall SHOULD be protected using a mechanism which prevents 465 unwanted access by entities outside the organization. 467 3.2.5 - Security Protocol. 469 The use of the Key Recovery Header (KRH) protocol is negotiated in the 470 same manner as other protocols (e.g., AH and ESP). Figure 2 below shows a 471 proposal for a combined protection suite with 3 different protocols. The 472 third protocol, KRH, uses a transform ID which reflects the key recovery 473 mechanism as defined in the DOI. The KRH attributes (e.g., the interval 474 between KRH transmissions) are contained within the SA attributes for the KRH 475 protocol. It is not necessary (or desirable) to send the KRH on each IPSEC 476 packet. The intervals at which the initiator and responder send KRH 477 headers is established independently. A value of 0 indicates the 478 associated entity will never send the KRH. Thus, an initiator could send 479 the KRH every hour while the responder never sends the KRH. 481 An example for this proposal might be: Protocol 1 is ESP with Transform 1 482 as 3DES, AND Protocol 2 is AH with Transform 1 as SHA AND Protocol 3 is 483 KRH with Transform 1 as Cylink and Transform 2 as Any. 485 In this example, the responder MUST accept KRH and select from the two 486 transforms proposed for KRH. The resulting protection suite will be either 487 3DES (with key recovery) AND AH SHA AND KRH with (1) the Cylink mechanism OR 488 (2) Any CKRB mechanism authorized by the policy, depending on which KRH 489 transform was selected by the responder. 491 1 2 3 492 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 493 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 / ! NP = Nonce ! RESERVED ! Payload Length ! 495 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 SA Pay ! Domain of Interpretation (DOI) ! 497 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 \ ! Situation ! 499 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 / ! NP = Proposal ! RESERVED ! Payload Length ! 501 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans =2 ! 503 \ ! ! ESP ! ! ! 504 Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 \ ! SPI (variable) ! 506 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 / ! NP = Transform! RESERVED ! Payload Length ! 508 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 510 \ ! ! 3DES ! ! 511 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 \ ! SA Attributes ! 513 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 / ! NP = Proposal ! RESERVED ! Payload Length ! 515 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1! 517 Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 \ ! SPI (variable) ! 519 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 / ! NP = Transform! RESERVED ! Payload Length ! 521 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 523 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 \ ! SA Attributes ! 525 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 / ! NP = Proposal ! RESERVED ! Payload Length ! 527 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans =2 ! 529 \ ! ! ESP ! ! ! 530 Prot 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 \ ! SPI (variable) ! 532 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 / ! NP = Transform! RESERVED ! Payload Length ! 534 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 ! 536 \ ! ! Cylink ! ! 537 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | ! SA Attributes ! 539 | !A! Attribute Type ! AF=1 Attribute value ! 540 | !F! Initiator KRH Interval ! Seconds ! 541 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 \ !A! Attribute Type ! AF=1 Attribute value ! 543 \!F! Responder KRH Interval ! Seconds ! 544 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 / ! NP = Transform! RESERVED ! Payload Length ! 546 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 ! 548 \ ! ! Any ! ! 549 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | ! SA Attributes ! 551 | !A! Attribute Type ! AF=1 Attribute value ! 552 | !F! Initiator KRH Interval ! Seconds ! 553 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 \ !A! Attribute Type ! AF=1 Attribute value ! 555 \!F! Responder KRH Interval ! Seconds ! 556 >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 2. Example payload containing a key recovery header proposal. 560 3.2.6 Transmission of the CKRBs 562 The CKRBs are transmitted in the notify payload. Each CKRB contains 1 key 563 so 2 CKRBs are transmitted. The first contains the initiator to responder 564 key and the second contains the responder to initiator key. 566 The key recovery mechanism uses the Commit Bit to prevent encrypted IPSEC 567 traffic until the CKRB pair has been transmitted. The Commit Bit is set 568 by either party intending to send a CKRB pair via the notify message 569 within an Informational Exchange. If the Commit Bit is set(1), the entity 570 which did not set MUST wait for an Informational Exchange containing a 571 Notify payload (with the CONNECTED Notify Message) from the entity which 572 set the Commit Bit. This indicates that the SA establishment was 573 successful and the receiving entity can now proceed with encrypted traffic 574 communication. 576 The CKRBs MUST be sent within the Informational Exchange and not as part 577 of a payload which is encrypted. The information exchange is normally 578 encrypted using the ISAKMP SA. The Authentication Only Bit is used to 579 send the informational exchange using authentication but not 580 encryption. This protects the CKRBs from unauthorized modification while 581 allowing the CKRBs to be observed. 583 Figure 3 shows the format of the Notification Payload containing CKRBs. 585 1 2 3 586 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 ! Next Payload ! RESERVED ! Payload Length ! 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 ! Domain of Interpretation (DOI) ! 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 ! Protocol-ID ! SPI Size ! Notify Message Type ! 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 ! ! 595 ~ Security Parameter Index (SPI) ~ 596 ! ! 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 ! Notification Data ! 599 ! Connected ! ! 600 ! Type = CKRB ! length of CKRB ! 601 ! CKRB ~ 602 ! Type = CKRB ! length of CKRB ! 603 ! CKRB ~ 604 ! ! 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 15: Notification Payload Format with CKRBs 609 3.3 Discussion 611 When one of the communicating ISAKMP entities does not accept any 612 proposals containing the KRM, the entity performing key recovery is 613 responsible for ensuring that the CKRBs are transmitted at intervals 614 required by the situation. 616 Manually keyed IPSEC security associations MUST use the Key Recovery 617 Header to pass the CKRBs. 619 Some situations may require the CKRB to be retransmitted periodically. 620 This MAY be done via the KRH or via the ISAKMP notify message. A 621 second ISAKMP phase 2 exchange MUST be performed when a notify message 622 is used to retransmit the CKRB. 624 ISAKMP is defined to be key recovery tolerant. If an ISAKMP 625 implementation receives a well formed notify containing an unknown 626 CKRB, then the receiver gracefully discards the CKRB and continues the 627 security association. This allows key recovery enabled devices to 628 interoperate with legacy devices which are key recovery unaware. 630 4. ACKNOWLEDGMENTS 632 This document was produced based on the combined efforts of the 633 protocol subcommittee of the Key Recovery Alliance. Comments on this 634 document should be sent to key-recovery@raleigh.ibm.com. 636 5. REFERENCES 638 [Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL, 639 August 1995. 641 [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, 642 NRL, August 1995. 644 [CW98] Charles Williams, Tom Markham, Key Recovery Header for IPSEC, 645 DRAFT Key Recovery Alliance Recommendation 2, April 1998 647 [DoD85] US National Computer Security Center, "Department of Defense 648 Trusted Computer System Evaluation Criteria", DoD 5200.28-STD, US 649 Department of Defense, Ft. Meade, MD., December 1985. 651 [DM97] Internet Security Association and Key Management Protocol 652 (ISAKMP), Douglas Maughan, Mark Schertler, Mark Schneider, Jeff 653 Turner, INTERNET-DRAFT draft-ietf-ipsec-isakmp-08.txt, .ps, July 26, 654 1997 656 [DP98] The Internet IP Security Domain of Interpretation for ISAKMP 657 [DP98], Derrell Piper, Network Alchemy, May 12, 1998 659 [RA95] Security Architecture for the Internet Protocol, 660 R. Atkinson, Naval Research Laboratory, Request for Comments: 1825, 661 Category: Standards Track, August 1995 663 [SG98] A Common Key Recovery Block Format: promoting Interoperability 664 between dissimilar key recovery schemes, Sarbari Gupta, Key Recovery 665 Alliance Recommendation 1, April 1998 667 6. SECURITY CONSIDERATIONS 669 This entire document discusses a means to disclose cryptographic keys in 670 a controlled manner. The session keying material is contained in a 671 common key recovery block [SG98] which itself is cryptographically 672 protected. 674 Implementors must apply good coding practices to prevent the 675 introduction of vulnerabilities into the common key recovery block 676 processing. 678 A second security concern is the potential for unauthorized access to 679 the session key after the common key recovery block has been decrypted. 680 This protection is provided by the key recovery agent which is outside 681 the scope of this protocol. 683 The security issues associated with key recovery may be explored using 684 this experimental protocol in the context of a larger key recovery 685 system. 687 7. AUTHOR INFORMATION 689 Tom Markham 690 Secure Computing Corp 691 2675 Long Lake Road 692 Roseville, MN 55113 USA 694 Phone: 651.628.2754, Fax: 651.628.2701 695 EMail: tom_markham@securecomputing.com 697 8. APPENDIX A: Proposed DOI Values 699 This appendix is temporary. It will be removed and placed in a separate 700 DOI document if/when the key recovery documents progress through the 701 standards process. 703 The addition of key recovery to ISAKMP requires the extension of the 704 existing Internet IP Security Domain of Interpretation for ISAKMP 705 [DP98]. The following types of extensions are required. 707 - Protocol ID 708 - SA Attributes 709 - Transforms 711 An identifiers for the Type = CKRB used within the Notify must also be 712 defined. 714 A1. Protocol ID - IPSEC Security Protocol Identifier 716 The following table lists the values for the Security Protocol 717 Identifiers referenced in an ISAKMP Proposal Payload for the IPSEC 718 DOI. 720 Protocol ID Value 721 ----------- ----- 722 RESERVED 0 723 PROTO_ISAKMP 1 724 PROTO_IPSEC_AH 2 725 PROTO_IPSEC_ESP 3 726 PROTO_IPCOMP 4 727 PROTO_KRH 5 729 PROTO_IPSEC_KRH 731 The PROTO_IPSEC_KRH type specifies IP Key Recovery Header containing a 732 pair of CKRBs. 734 A2. SA Attributes 736 The SA Attributes will be extended to include the following. 738 Attribute Types 740 class value type 741 ------------------------------------------------- 743 SA Initiator Key Recovery TBD B 744 SA Responder Key Recovery TBD B 745 SA Initiator KRH Interval TBD B 746 SA Responder KRH Interval TBD B 748 Initiator Key Recovery indicates that the initiator will perform key 749 recovery. The value associated with this attribute specifies the CKRB 750 Transform Identifier which applies to the CKRB to be transmitted by the 751 initiator. 753 Responder Key Recovery indicates that the responder will perform key 754 recovery. The value associated with this attribute specifies the CKRB 755 Transform Identifier which applies to the CKRB to be transmitted by the 756 responder. 758 Initiator KRH Interval indicates the maximum interval between KRHs sent by 759 the initiator. 761 Responder KRH Interval indicates the maximum interval between KRHs sent by 762 the responder. 764 A3. Transforms - IPSEC CKRB Transform Identifier 766 The CKRB specification specifies a common wrapper for multiple key 767 recovery technologies each using unique transforms. 769 Transform ID Value 770 ----------- ----- 771 None 0 772 Any 1 773 Bull-P 2 774 Bull-G 3 775 Cylink 4 776 IBM 5 777 NETA 6 778 Novell 7 780 None: No key recovery is to be performed. 782 Any: Any key recovery mechanism recognized by the applicable policy is 783 acceptable. 785 Bull-P: The Bull transform using the ISAKMP protocol integrity mechanism. 787 Bull-G: The Bull transform using the split key generation mechanism. 789 Cylink: The Cylink CyKey mechanism together with the ISAKMP protocol 790 integrity mechanism. 792 IBM: The IBM mechanism together with the ISAKMP protocol 793 integrity mechanism. 795 NETA: The Network Associates (formerly TIS) mechanism together with the ISAKMP protocol 796 integrity mechanism. 798 Novell: The Novell mechanism together with the ISAKMP protocol 799 integrity mechanism. 801 9. FULL COPYRIGHT STATEMENT 803 "Copyright (C) The Internet Society (date). All Rights Reserved. 805 This document and translations of it may be copied and furnished 806 to others, and derivative works that comment on or otherwise 807 explain it or assist in its implmentation may be prepared, copied, 808 published and distributed, in whole or in part, without 809 restriction of any kind, provided that the above copyright notice 810 and this paragraph are included on all such copies and derivative 811 works. However, this document itself may not be modified in any 812 way, such as by removing the copyright notice or references to the 813 Internet Society or other Internet organizations, except as needed 814 for the purpose of developing Internet standards in which case the 815 procedures for copyrights defined in the Internet Standards 816 process must be followed, or as required to translate it into 817 languages other than English. 819 The limited permissions granted above are perpetual and will not 820 be revoked by the Internet Society or its successors or assigns. 822 This document and the information contained herein is provided on 823 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 824 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 825 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 826 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 827 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 829 INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT