idnits 2.17.1 draft-ietf-ipsec-ike-ext-meth-04.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 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. ** The abstract seems to contain references ([RFC2408], [RFC2409]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (22 November 2000) is 8556 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) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) -- Possible downref: Non-RFC (?) normative reference: ref. 'REVISED-HASH' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP Security Protocol Working Group (IPSEC) T. Kivinen 2 INTERNET-DRAFT SSH Communications Security 3 draft-ietf-ipsec-ike-ext-meth-04.txt 22 November 2000 4 Expires: 22 May 2001 6 ISAKMP & IKE Extension Methods 8 Status of This memo 10 This document is a submission to the IETF IP Security Protocol 11 (IPSEC) Working Group. Comments are solicited and should be 12 addressed to the working group mailing list (ipsec@lists.tislabs.com) 13 or to the editor. 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as 27 "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes multiple extension methods of the ISAKMP [RFC 38 2408] and IKE [RFC 2409] protocols and how the older versions should 39 respond when they receive such extensions. This document mainly tries to 40 describe the best practice of extensions handling in ISAKMP [RFC 2408] 41 and IKE [RFC 2409], so that a future version can be made without break- 42 ing the old existing versions. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 48 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 49 4. Sending Error Notifications . . . . . . . . . . . . . . . . . . 3 50 5. Order of Checking . . . . . . . . . . . . . . . . . . . . . . . 3 51 6. ISAKMP Major and Minor Version Numbers . . . . . . . . . . . . . 3 52 6.1. ISAKMP Major Version Number . . . . . . . . . . . . . . . . 4 53 6.2. ISAKMP Minor Version number . . . . . . . . . . . . . . . . 4 54 7. Phase 1 Transform Identifier . . . . . . . . . . . . . . . . . . 6 55 8. Exchange type . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 9. Flags Inside the Generic Packet Header . . . . . . . . . . . . . 6 57 10. Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 11. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . 8 59 12. Data Attribute Types and Values . . . . . . . . . . . . . . . . 9 60 12.1. Data Attributes, Protocol and Transform IDs . . . . . . . . 10 61 13. Reserved Fields . . . . . . . . . . . . . . . . . . . . . . . . 10 62 14. Identity Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 15. Certificate Encoding . . . . . . . . . . . . . . . . . . . . . 11 64 16. Notify Message Type . . . . . . . . . . . . . . . . . . . . . . 11 65 17. Domain of Interpretation . . . . . . . . . . . . . . . . . . . 12 66 18. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 67 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 20. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 The ISAKMP [RFC 2408] and IKE [RFC 2409] protocols can be extended in 73 various ways. It is not clearly defined in the current document set how 74 to use the extension mechanisms. Also, the current document set does not 75 clearly define what a conforming implementation should do if it receives 76 an extension that it does not understand. 78 This document describes how to provide backwards compatibility with the 79 old versions. The reader is assumed to be familiar with most of the 80 terms and concepts described in the ISAKMP [RFC 2408] and IKE [RFC 2409] 81 documents. 83 2. Specification of Requirements 85 This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and 87 "OPTIONAL" to describe requirements. They are to be interpreted as 88 described in the [RFC 2119] document. 90 3. Terminology 92 This document uses the terms "new version" and "old version" to identify 93 the two different protocol versions. The new version is the version that 94 supports the new extension, and the old version is a version that does 95 not support it. The terms should always be interpreted only in the 96 current context. 98 4. Sending Error Notifications 100 If the other end does not send error notifications, it is very hard to 101 create usable extensions to the protocol. In that case the only way to 102 detect whether the other end supports the extension is to see if the 103 negotiation times out. This may cause unnecessary delays in the 104 negotiation process. Because of that, all implementations SHOULD send 105 notifications back when they reject any extensions or new features. 107 Implementations MAY limit the number of notifications sent out. A 108 suitable limit could be something like one notification per second per 109 host. Implementations SHOULD resend the notification if the other end 110 resends its own ISAKMP datagram (in case the error notification was 111 lost). This resending SHOULD also be limited to a reasonable level. 113 5. Order of Checking 115 The order of checks performed for an ISAKMP datagram SHOULD be the 116 following: 118 o Major version number 120 o Minor version number 122 o Exchange type 124 o Flags in the generic header 126 o Payload types 128 o Reserved field in the generic payload headers 130 o Payload specific checks. 132 6. ISAKMP Major and Minor Version Numbers 134 All ISAKMP datagrams contain version numbers which describe the major 135 and minor version numbers of the sending party. In the IKE defined in 136 RFC 2409, major and minor version numbers are not authenticated. Thus, 137 when they are later changed to be authenticated, there might be the 138 possibility of a version rollback attack where the attacker forces 139 negotiating parties to fall back to the RFC 2409 version of IKE. 141 The major version number is changed when major changes are done to the 142 protocol, i.e. there are changes in the generic packet encoding 143 routines. This means that the older versions cannot understand the newer 144 packet format at all. 146 The minor version number is changed when new payloads are defined or 147 other minor changes in the protocol take place. The older versions can 148 still process the generic packet structure, but there might be small 149 variations in the fields inside the payloads. 151 Each party MUST NOT change the version number it is sending during one 152 negotiation, i.e. if a host started the negotiation using version number 153 1.1, it MUST use that during the whole negotiation. Separate 154 negotiations MAY have different version numbers, i.e. a newer version 155 may restart negotiation, and start using an older version number. Both 156 ends use their own version number, so it is completely legal for one end 157 to start with 1.1 and for the other end to respond with 1.0. 159 Phase 1 and phase 2 negotiations are separate negotiations. So, a phase 160 1 negotiation that creates ISAKMP SA may use version X, and a phase 2 161 negotiation done over that ISAKMP SA may use version Y. 163 Because the minor version number is encoded into a 4-bit field (0-15), a 164 minor version number roll-over might occur. This means that the major 165 version number must be incremented even if the packet structure is still 166 actually the same. Because of this phenomenon, incrementing the minor 167 version number SHOULD be avoided if it is not absolutely necessary. 169 An implementation supporting minor version X MUST support all features 170 up to that level (it MUST at least be able to ignore the non-critical 171 extensions, and detect critical extensions and abort the negotiation in 172 that case). 174 In addition to major and minor version numbers, there is a phase 1 175 transform identifier inside the SA payload, which identifies the key 176 exchange method (e.g IKE) version number. 178 6.1. ISAKMP Major Version Number 180 If an old version receives a datagram with a major version number larger 181 than its own, it SHOULD send the INVALID-MAJOR-VERSION notification 182 back. It MUST put its own version number inside the notification 183 datagram. This gives the other end the opportunity to obtain the version 184 number supported by the sender of the notification. The received ISAKMP 185 datagram MUST then be discarded (the old version cannot parse anything 186 else in the datagram because the generic packet structure has changed). 188 Note that in most cases, this notification sent by the remote host is 189 not authenticated, so it can also lead to the version rollback attack. 191 A new version receiving the INVALID-MAJOR-VERSION notification MAY fall 192 back to the older version. If falling back to the older version has 193 security implications, then the new version SHOULD NOT fall back to a 194 previous version but instead fail the negotiation with a clear error 195 message. 197 6.2. ISAKMP Minor Version number 199 If an old version receives a datagram with a minor version newer than 200 its own, it 201 o SHOULD continue processing the datagram, or it 203 o MAY discard the ISAKMP datagram. In that case it SHOULD send the 204 INVALID-MINOR-VERSION notification back. 206 In any case the old version MUST use its own local minor version number 207 when sending packets back, so that a new version can get the older 208 version number and fall back to the same version if necessary. 210 The new version MAY always start with the latest version number and fall 211 back to the previous version separately each time, or it MAY cache this 212 information for some time, or the version number used may be configured 213 manually. 215 The minor number MUST be updated if 217 o new flags are added (see section ``Flags Inside the Generic Packet 218 Header'') 220 o new use of a RESERVED field is defined (see section ``Reserved 221 Fields'') 223 The minor number MAY be updated if 225 o new general purpose payload types are added (see section ``Payload 226 Types'') 228 The minor number SHOULD NOT be updated if 230 o new exchange types are added (see section ``Exchange type'') 232 o new payload types that can only be used in a specific exchange, etc. 233 are added (see section ``Payload Types'') 235 o new IANA registered data attribute types are defined (see section 236 ``Data Attribute Types and Values'') 238 o new IANA registered data attribute values are defined (see section 239 ``Data Attribute Types and Values'') 241 o a new certificate encoding type is added (see section ``Certificate 242 Encoding'') 244 o a new identity type is defined (see section ``Identity Type'') 246 o new phase 1 transform identifiers are defined (see section ``Phase 1 247 Transform Identifier'') 249 The minor number MUST NOT be updated if 251 o a new domain of interpretation is defined (see section ``Domain of 252 Interpretation'') 254 7. Phase 1 Transform Identifier 256 Phase 1 SA payload contains a transform identifier that specifies the 257 key exchange method used. It can be used to negotiate the key exchange 258 method and version. This is different from the minor version number in 259 the manner that the other end MUST send back exactly the same transform 260 ID (i.e. it MUST select one of those values offered). It cannot modify 261 the SA payload which contains the transform identifier. 263 The selected exchange type may limit the possibility to negotiate 264 different key exchange methods, because the key exchange type might 265 affect the format of the first packet (for example the IKE aggressive 266 mode). 268 8. Exchange type 270 An exchange type defines a generic packet exchange between two 271 negotiating parties. It defines the number of datagrams in the exchange, 272 the generic meaning of the packets (i.e. in main mode the first two 273 datagrams exchange SA payloads, the next two datagrams are used for the 274 key exchange, and the final two datagrams are used to exchange 275 identities and to authenticate the exchange). 277 If an implementor wants to add new datagrams to the existing exchanges, 278 then the implementor MUST create a new exchange and allocate a new 279 exchange type for it. 281 If an implementation receives a datagram that contains an exchange type 282 it does not understand, it SHOULD send back the INVALID-EXCHANGE-TYPE 283 notification. Also it MUST ignore the ISAKMP datagram. 285 If an implementation receives the INVALID-EXCHANGE-TYPE notification, it 286 MAY fall back to a more standard exchange (for example, from the 287 aggressive mode to the main mode). 289 When new ISAKMP exchange types are added, the minor version number 290 SHOULD NOT be updated. When new key exchange specific exchange types are 291 added, the phase 1 transform identifier SHOULD NOT be updated. If old 292 existing key exchange specific exchange types are modified, then the 293 phase 1 transform identifier SHOULD be updated. 295 A new version MAY always start with the new exchange type and fall back 296 to a previous, more standard exchange type separately each time, or it 297 MAY cache this information for some time, or the exchange type used may 298 be configured manually. 300 9. Flags Inside the Generic Packet Header 302 Flags are a part of the generic ISAKMP packet structure. Currently, 303 three flags are defined (encryption, commit bit, authentication only 304 bit). 306 When new flags are defined, the minor version number MUST be updated. 308 When a new flag is added, the specification MUST indicate if this flag 309 has any security implications and whether a new version should fail the 310 negotiation if the other end is using an old version. 312 If the old version receives a datagram with a newer minor version 313 number, and some unknown flags are set, it 315 o SHOULD continue the exchange and ignore the new flags, or it 317 o MAY fail the negotiation. In that case it SHOULD send the INVALID- 318 FLAGS notification back. 320 If a new version notices (from the version numbers) that the other end 321 is using an old version, it MUST fail the negotiation if it tried to set 322 a flag that has security implications. If the flag it set does not have 323 security implications, it MAY continue the exchange. 325 10. Payload Types 327 Each payload inside a datagram contains a type field in the generic 328 payload header. The payload type describes the internal structure of the 329 payload. Unknown payloads can be ignored because the generic payload 330 header contains the length of the payload data. 332 Payload types in the special private range are to be used for mutually 333 consenting implementations only. Implementations MUST NOT send payloads 334 of a private type unless the both parties have both sent and received a 335 familiar vendor ID payload. After this exchange of the vendor ID 336 payloads during the phase 1, implementations MAY immediately start 337 sending private payloads. 339 Note that RFC 2409 does not protect vendor ID payloads from tampering, 340 so implementations should not enable anything based on vendor IDs if 341 that feature has security implications. 343 When new payload types are defined (other than private-use payloads), 344 and a new version can detect from somewhere else than from version 345 numbers that the other end understands or does not understand the new 346 payload types, then the minor version number SHOULD NOT be updated. If 347 there is no way to detect if the other end understands the newly defined 348 payload types, then the either the minor version number of the ISAKMP 349 packet or the phase 1 transform identifier SHOULD be updated. If the new 350 payloads are inside the key exchange method specific exchange, then it 351 is enough to only update the phase 1 transform identifier. 353 For example, if the newly defined payload type can only be used in a 354 certain new exchange type (like attribute payload inside the 355 transactional exchange), then an old version will fail the negotiation 356 because of the new exchange type, and a new version can detect that. 357 There is no need to update the version number in that case. 359 This allows for creating optional features in the ISAKMP protocol in 360 such a manner that the implementors do not need to implement them all. 362 Every time the minor version number or the phase 1 transform identifier 363 is updated, all the implementations MUST understand all the new 364 mandatory payloads. In the case of a new generic payload that can be 365 used in several exchanges etc., the minor version number or the phase 1 366 transform identifier MAY be updated. 368 When a new payload type is added, the corresponding specification MUST 369 indicate if the new payload has any security implications and whether a 370 new version should fail the negotiation if the other end is using an old 371 version. The specification MUST also indicate whether it is mandatory to 372 implement the new feature or not. 374 If the implementation receives an unknown private payload type, it 376 o SHOULD ignore the payload and continue, or it 378 o MAY fail the negotiation. In that case it SHOULD send the INVALID- 379 PAYLOAD-TYPE notification back. 381 If the implementation receives an unknown payload type from the RESERVED 382 range and the version numbers (both ISAKMP major/minor version numbers 383 and phase 1 transform ID) are the same, it MUST fail the negotiation, 384 and it SHOULD send INVALID-PAYLOAD-TYPE notification back. 386 If the implementation receives an unknown payload type from the RESERVED 387 range, and the minor version number (or the phase 1 transform ID) of the 388 other end is newer, it 389 o SHOULD ignore the payload and continue, or it 391 o MAY fail the negotiation. In that case it SHOULD send the INVALID- 392 PAYLOAD-TYPE notification back. 394 If the new version has sent out a payload of a type that is defined in a 395 newer version of the protocol than the other end understands (this can 396 be detected by checking the minor version number), and the payload has 397 security implications then it MUST fail the negotiation. 399 There may be a need to add a criticality flag in the generic payload 400 header in the next version of ISAKMP [RFC 2408]. This would allow an old 401 version to detect immediately whether it can safely ignore the payload 402 or whether it MUST fail the negotiation (in that case it SHOULD send an 403 error notification). This criticality flag could be added to the 404 reserved field of the generic payload header (there are 8 reserved bits 405 inside the generic payload header). See section ``Reserved Fields'' for 406 more information about how an old version should handle the criticality 407 flag. 409 11. Vendor ID Payload 411 The vendor ID payload is a payload that can be included anywhere in the 412 phase 1 negotiation. It gives the other end a possibility to recognize 413 the remote implementation. These payloads are not authenticated in the 414 RFC 2409 version of the IKE. 416 The vendor ID has two uses. The first one is that by sending a vendor ID 417 payload along the SA payload, the initiator specifies whose private-use 418 values it is using (it SHOULD only send only one vendor ID payload, or 419 at least all the vendor ID payloads MUST NOT have overlapping private 420 numbers defining different things). 422 When initiator wants to use some private-use values in the exchange, it 423 just adds its own vendor ID payload(s). When the responder receives the 424 vendor ID payload(s) along with for example the SA payload, it can find 425 out whose private-use values are inside the SA payload by checking the 426 vendor ID payload. 428 The second use is to allow for vendor specific extensions, after both 429 ends have sent and received familiar vendor IDs. 431 Implementations MUST NOT fail a negotiation because of the presence of 432 the vendor ID payload(s), i.e. they MUST be able to ignore it. 434 If familiar vendor ID payloads have been exchanged (both sent and 435 received) then implementations MAY do anything, including using private 436 extensions, private payloads, new identity types, running nethack over 437 the ISAKMP SA, etc. 439 12. Data Attribute Types and Values 441 SA payloads and some other payloads in the ISAKMP contain data 442 attributes. Data attribute consists of an attribute type and a value. 443 The data attribute type and value number spaces are divided into two 444 parts: The IANA range and the private-use range. 446 The phase 1 data attribute types and values are defined in the IKE 447 document and ISAKMP documents. This part should probably be separated 448 from those documents to separate IKE DOI. The Phase 2 data attributes 449 are defined in the DOI [RFC 2407] document. 451 The private-use data attribute TYPES can be used anywhere, and when they 452 are used, the sender SHOULD send vendor ID payload(s) specifying whose 453 private-use values the sender is using. 455 When adding new IANA registered data attribute TYPES, the minor version 456 number of the protocol SHOULD NOT be updated. When adding new IANA 457 registered data attribute TYPES, the phase 1 transform identifier MAY be 458 updated. 460 The private-use data attribute VALUES can also be used anywhere, and 461 when they are used, the sender SHOULD send vendor ID payload(s) 462 specifying whose private-use values the sender is using. 464 When adding new IANA registered data attribute VALUES, the minor version 465 number of the protocol SHOULD NOT be updated. When adding new IANA 466 registered data attribute VALUES, the phase 1 transform identifier MAY 467 be updated. 469 12.1. Data Attributes, Protocol and Transform IDs 471 The proposal or transform payload MUST NOT be selected by the responder 472 if it contains unknown protocol IDs, transform IDs, data attribute 473 types, or data attribute values. 475 This means that an initiator SHOULD always include a proposal without 476 any private-use types or values so that if the other end does not 477 understand them, then it may select the transform or proposal without 478 private-use types or values. 480 13. Reserved Fields 482 Lots of payloads in the ISAKMP contain RESERVED fields that are defined 483 to be zero and whose contents MUST be checked. This makes extension of 484 the payloads very difficult to implement. Changing this so that their 485 contents MUST be checked only if the version numbers are the same makes 486 it much easier to introduce backwards compatible extensions to the 487 protocol in the future. 489 When a new use of a RESERVED field is defined, the minor version number 490 MUST be updated. 492 When a new use of a RESERVED field is defined, the corresponding 493 specification MUST indicate if this new use of the RESERVED field has 494 any security implications and whether a new version should fail the 495 negotiation if the other end is using an old version and the new version 496 tried to use this new usage for a RESERVED field. 498 If an old implementation receives a packet that contains a non-zero 499 RESERVED field, and the minor version number of the other end is newer 500 than the local one, then it 502 o SHOULD ignore the contents of the RESERVED field and continue, or it 504 o MAY ignore the ISAKMP datagram. In that case it SHOULD send the 505 INVALID-RESERVED-FIELD notification back. 507 If the new version notices that the other end is using the old version, 508 it MUST fail the negotiation if it tried to use the RESERVED field in 509 such a way that has security implications. If the new defined use of the 510 RESERVED field does not have security implications, it MAY continue the 511 exchange. 513 14. Identity Type 515 The identity type is used to specify the interpretation of the identity 516 payload contents. The identity type is specified in the DOI document, 517 but the generic structure is defined in the ISAKMP document. This 518 generic structure contains this identity type value. 520 When a new identity type is specified, the minor version number or the 521 phase 1 transform identifier SHOULD NOT be incremented. 523 If an old version receives an unknown identity type, it MUST fail the 524 negotiation, and it SHOULD send the INVALID-ID-INFORMATION notification 525 back. 527 A new version MAY always start with the new identity type and fall back 528 to a previous more standard identity type separately each time, or it 529 MAY cache this information for some time, or it MAY manually configure 530 the identity type to be used. 532 15. Certificate Encoding 534 Certificate encoding is used to specify the interpretation of the 535 certificate payload contents. 537 When a new certificate encoding type is added, the minor version number 538 or the phase 1 transform identifier SHOULD NOT be incremented. 540 If an old version receives an unknown certificate encoding type, it 542 o SHOULD just ignore the payload and continue, or it 544 o MAY fail the negotiation. In that case it SHOULD send the INVALID- 545 CERT-ENCODING notification back. 547 16. Notify Message Type 549 Messages containing notify payload are sent to either notify an error 550 situation or to give out status information. Each notify payloads 551 contain a notify message type which describes the message type. 553 The notify message types are divided in the several separate ranges: 555 1 - 8191 556 ISAKMP error code range 558 8192 - 16383 559 Private use error code range 561 16384 - 24575 562 ISAKMP status code range 564 24576 - 32767 565 DOI status code range 567 32768 - 40959 568 Private use status code range 570 If an unknown error (1 <= code <= 16383) notification type is received, 571 the receiver MUST treat it as a fatal error and abort the negotiation. 573 If an unknown status (16384 <= code <= 40959) notification type is 574 received, the receiver MUST ignore the notification payload. 576 For example, a new keep-alive protocol for the ISAKMP SA may be defined 577 by just defining that both ends must send a new STILL-CONNECTED 578 notification every 60 seconds. If the other end never sees those 579 notifications, it just assumes that the other end does not support this 580 feature, and ceases sending any further keep-alive packets. If that new 581 STILL-CONNECTED status code is selected from the status code range, then 582 old implementations will just ignore them. 584 When using notifications, implementations must take care of what to do 585 with the notifications which are not authenticated (i.e. those received 586 before the ISAKMP SA is ready). If there is no ISAKMP SA established 587 with the remote host, then most of the notifications may still be 588 trusted in order to avoid lengthy timeouts in error situations. If there 589 is a ISAKMP SA established, then unauthenticated notifications SHOULD be 590 ignored. 592 17. Domain of Interpretation 594 Each SA payload (and some others like notify and delete payloads) 595 specifies the domain of interpretation for the exchange. There is no 596 version numbers in the DOI, so if a new version of DOI is incompatible 597 with the previous version, a new DOI number MUST be allocated. In the 598 normal case, there is no need to have a version number in the DOI, and 599 additions to it may be done without updating the DOI number. 601 If an unknown domain of interpretation is received, the responder MUST 602 discard the ISAKMP datagram and it SHOULD send the DOI-NOT-SUPPORTED 603 notification back. This usually also means that the negotiation is 604 aborted. 606 When a new domain of interpretation is defined, the minor version number 607 MUST NOT be incremented. If ISAKMP DOI is modified, there might be a 608 need to update the DOI number. 610 18. Security Considerations 612 This document describes how to use the extension mechanisms defined in 613 ISAKMP [RFC 2408] and IKE [RFC 2409]. Because some of those extensions 614 might have security implications, it is required that when new 615 extensions are defined, it is also explained what security implications 616 they have and what the implementations supporting them should do if the 617 other end does not support the extensions. 619 One security problem comes from the ISAKMP [RFC 2408] and IKE [RFC 2409] 620 protocol, because the version number, exchange type, and flags fields 621 are not authenticated in the RFC 2409 version of IKE protocol. The 622 [REVISED-HASH] describes a way to fix this problem by updating the phase 623 1 transform id number. 625 If a real security problem is later found from that version of protocol, 626 the implementors MUST make sure that they never fall back to any 627 previous version because the attacker can force falling back to a 628 previous version by changing the version numbers inside the datagrams. 630 Also the vendor ID payloads, notifications etc. inside the phase 1 631 packets are not authenticated in the RFC 2409 version of IKE. This means 632 that implementations SHOULD NOT enable any security critical extensions 633 based on those unathenticated payloads. 635 Another security problem comes from the fact that there is no way to 636 send authenticated notifications before the phase 1 (ISAKMP) SA is 637 finished. This means that most of the error notifications about the 638 Phase 1 exchange are sent without any kind of protection. 640 19. References 642 [RFC 2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet 643 Security Association and Key Management Protocol (ISAKMP)", November 644 1998. 646 [RFC 2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", 647 November 1998 649 [RFC 2119] Bradner, S., "Key words for use in RFCs to indicate 650 Requirement Levels", March 1997 652 [RFC 2407] Piper D., "The Internet IP Security Domain of Interpretation 653 for ISAKMP", November 1998 655 [REVISED-HASH] Kivinen T., "Fixing IKE Phase 1 & 2 Authentication 656 HASHs", November 2000 658 20. Authors' Addresses 660 Tero Kivinen 661 SSH Communications Security Corp 662 Fredrikinkatu 42 663 FIN-00100 HELSINKI 664 Finland 665 E-mail: kivinen@ssh.fi