IP Security Protocol Working Group (IPSEC) T. Kivinen INTERNET-DRAFT SSH Communications Security draft-ietf-ipsec-ike-ext-meth-02.txt 5 August 1999 Expires: 5 February 2000 ISAKMP & IKE Extensions Methods Status of This memo This document is a submission to the IETF IP Security Protocol (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@lists.tislabs.com) or to the editor. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes the multiple extension methods of the ISAKMP [RFC-2408] and IKE [RFC-2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best common practice of the extensions handling in ISAKMP [RFC-2408] and IKE [RFC-2409]. T. Kivinen [page 1]
INTERNET-DRAFT 5 August 1999 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Specification of Requirements . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Sending Error Notifications . . . . . . . . . . . . . . . . . . 3 5. Order of Checking . . . . . . . . . . . . . . . . . . . . . . . 3 6. ISAKMP Major and Minor Version Numbers . . . . . . . . . . . . . 3 6.1. ISAKMP Major Version Number . . . . . . . . . . . . . . . . 4 6.2. ISAKMP Minor Version number . . . . . . . . . . . . . . . . 4 7. Phase 1 Transform Identifier . . . . . . . . . . . . . . . . . . 5 8. Exchange type . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Flags Inside the Generic Packet Header . . . . . . . . . . . . . 6 10. Payload Types . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . . . . 8 12. Data Attribute Types and Values . . . . . . . . . . . . . . . . 9 12.1. Data Attributes, Protocol and Transform IDs . . . . . . . . 9 13. Reserved Fields . . . . . . . . . . . . . . . . . . . . . . . . 9 14. Identity Type . . . . . . . . . . . . . . . . . . . . . . . . . 10 15. Certificate Encoding . . . . . . . . . . . . . . . . . . . . . 10 16. Notify Message Type . . . . . . . . . . . . . . . . . . . . . . 11 17. Domain of Interpretation . . . . . . . . . . . . . . . . . . . 12 18. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 20. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The ISAKMP [RFC-2408] and IKE [RFC-2409] protocols can be extended in various ways. It is not clearly defined in the current document set how to use the extension mechanisms. Also, the current document set does not clearly define what a conforming implementation should do if it receives an extension that it does not understand. This document describes how to provide backwards compatibility with the old versions. The reader is assumed to be familiar with most of the terms and concepts described in the ISAKMP [RFC-2408] and IKE [RFC-2409] documents. 2. Specification of Requirements This document shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED, "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC-2119] document. 3. Terminology This document uses the terms "new version" and "old version" to identify the two different protocol versions. The new version is the version that supports the new extension, and the old version is a version that does T. Kivinen [page 2]
INTERNET-DRAFT 5 August 1999 not support it. The terms should always be interpreted only in the current context. 4. Sending Error Notifications If the other end does not send error notifications, it is very hard to create usable extensions to the protocol. In that case the only way to detect whether the other end supports the extension is to see if the negotiation times out. This may cause unnecessary delays in the negotiation process. Because of that, all implementations SHOULD send notifications back when they reject any extensions or new features. Implementations MAY limit the number of notifications sent out. A suitable limit could be something like one notification per second per host. Implementations SHOULD still continue sending notifications back when the other end resends its own ISAKMP datagram (in case the error notification was lost). 5. Order of Checking The order of checks performed for ISAKMP datagram SHOULD be following: o Major version number o Minor version number o Exchange type o Flags in the generic header o Payload types o Reserved field in the generic payload headers o Payload specific checks. 6. ISAKMP Major and Minor Version Numbers All ISAKMP datagrams contain version numbers, which describe the major and minor version numbers of the sending party. In the first IKE version, which have transform identifier KEY_IKE (1), major and minor version numbers are not authenticated. Thus when they are later changed to be authenticated, there always exists the possibility of a version rollback attack where the attacker forces negotiating parties to fall back to the first version of IKE. This can be prevented by disabling the version fall back. Major version number changes when major changes are done to the protocol, i.e there are changes in the generic packet encoding routines. This means that the older versions cannot understand the newer packet format at all. Minor version number changes when new payloads are defined or other T. Kivinen [page 3]
INTERNET-DRAFT 5 August 1999 minor changes in the protocol take place. The older versions can still process the generic packet structure, but there might be small variations in the fields inside the payloads. Each party MUST NOT change the version number it is sending during one negotiation, i.e if negotiation was started using version number 1.1, it MUST be used during the whole negotiation. Separate negotiations MAY have different version numbers, i.e newer version may restart negotiation, and start using older version number. Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 negotiation that creates ISAKMP SA may use version X, and phase 2 negotiation done over that ISAKMP SA may use version Y. Because the minor version number is encoded into a 4-bit field (0-15), a minor version number roll-over might occur. This means that the major version number must be incremented even if the packet structure is still actually same. Because of this phenomenon, incrementing the minor version number SHOULD be avoided if it is not absolutely necessary. Implementation supporting minor version X MUST support all features up to that level (it MUST at least be able to ignore the non-critical extensions, and detect critical extensions and abort the negotiation in that case). In addition to major and minor version numbers there is a phase 1 transform identifier inside the SA payload, which identifies the key exchange method (e.g IKE) version number. 6.1. ISAKMP Major Version Number If an old version receives a datagram with a major version number larger than its own, it SHOULD send the INVALID-MAJOR-VERSION notification back. It MUST put its own version number inside the notification datagram. This gives the other end the opportunity to obtain the version number supported by the sender of the notification. The received ISAKMP datagram MUST then be discarded (the old version cannot parse anything else in the datagram because the generic packet structure has changed). Note that in most cases this notification sent by the remote host is not authenticated, so it can also lead to the version rollback attack. A new version receiving the INVALID-MAJOR-VERSION notification MAY fall back to the older version. If falling back to the older version has security implications then the new version SHOULD NOT fall back to previous version but instead fail the negotiation with a clear error message. 6.2. ISAKMP Minor Version number If an old version receives a datagram with a minor version newer than its own, it T. Kivinen [page 4]
INTERNET-DRAFT 5 August 1999 o SHOULD continue processing the datagram, or it o MAY discard the ISAKMP datagram. In that case it SHOULD send the INVALID-MINOR-VERSION notification back. In any case the old version MUST use its own local minor version number when sending packets back, so that a new version can get the older version number and fall back to same version if necessary. The new version MAY always start with the latest version number and fall back to the previous version every time separately, or it MAY cache this information for some time, or the version number used may be configured manually. The minor number MUST be updated if o new flags are added (see section ``Flags Inside the Generic Packet Header'') o new use of a RESERVED field is defined (see section ``Reserved Fields'') The minor number MAY be updated if o new general purpose payload types are added (see section ``Payload Types'') The minor number SHOULD NOT be updated if o new exchange types are added (see section ``Exchange type'') o new payload types that can only be used in specific exchange etc are added (see section ``Payload Types'') o new IANA registered data attribute types are defined (see section ``Data Attribute Types and Values'') o new IANA registered data attribute values are defined (see section ``Data Attribute Types and Values'') o new certificate encoding type is added (see section ``Certificate Encoding'') o new identity type is defined (see section ``Identity Type'') The minor number MUST NOT be updated if o new domain of interpretation is defined (see section ``Domain of Interpretation'') 7. Phase 1 Transform Identifier Phase 1 SA payload contains a transform identifier that currently T. Kivinen [page 5]
INTERNET-DRAFT 5 August 1999 specifies the key exchange method used. It can be used to negotiate the key exchange method and its version. Selected exchange type may limit the possibility to negotiate different key exchange methods, because key exchange type might affect the format of the first packet (for example the IKE aggressive mode). 8. Exchange type An exchange type defines a generic packet exchange between two negotiating parties. It defines the number of datagrams in the exchange, the generic meaning of the packets (i.e. in main mode the first two datagrams exchange SA payloads, the next two datagrams are used for the key exchange, and the final two datagrams are used to exchange identities and to authenticate the exchange). If an implementor wants to add new datagrams to the existing exchanges, then the implementor MUST create a new exchange and allocate a new exchange type for it. If an implementation receives a datagram that contains an exchange type it does not understand it SHOULD send back the INVALID-EXCHANGE-TYPE notification. Also it MUST ignore the ISAKMP datagram. If an implementation receives the INVALID-EXCHANGE-TYPE notification it MAY fall back to a more standard exchange (for example, from the aggressive mode to the main mode). When new ISAKMP exchange types are added, the minor version number SHOULD NOT be updated. When new key exchange specific exchange types are added, the phase 1 transform identifier SHOULD NOT be updated. A new version MAY always start with the new exchange type and fall back to a previous, more standard exchange type every time separately, or it MAY cache this information for some time, or the exchange type used may be configured manually. 9. Flags Inside the Generic Packet Header Flags are a part of the generic ISAKMP packet structure. Currently, three flags are defined (encryption, commit bit, authentication only bit). When new flags are defined the minor version number MUST be updated. When a new flag is added, the specification MUST indicate if this flag has any security implications and whether a new version should fail the negotiation if the other end is using an old version. If the old version receives a datagram with a newer minor version number, and some unknown flags are set it o SHOULD continue the exchange and ignore the new flags, or it T. Kivinen [page 6]
INTERNET-DRAFT 5 August 1999 o MAY fail the negotiation. In that case it SHOULD send the INVALID- FLAGS notification back. If a new version notices that the other end is using an old version (from the version numbers) it MUST fail the negotiation if it tried to set a flag that has security implications. If the flag it set does not have security implications it MAY continue the exchange. 10. Payload Types Each payload inside a datagram contains a type field in the generic payload header. The payload type describes the internal structure of the payload. Unknown payloads can be ignored because the generic payload header contains the length of the payload data. Payload types in the special private range are to be used for mutually consenting implementations only. Implementations MUST NOT send payloads of a private type unless the both parties have both sent and received a familiar vendor ID payload. After this exchange of the vendor ID payloads during the phase 1, implementations MAY immediately start sending private payloads. When new payload types are defined (other than private-use payloads), and a new version can detect from somewhere else than from version numbers that the other end understands or does not understand the new payload types, then the minor version number SHOULD NOT be updated. If there is no way to detect if the other end understands the newly defined payload types then the either the minor version number of the ISAKMP packet or the phase 1 transform identifier SHOULD be updated. If the new payloads is inside the key exchange method specific exchange then it is enough to only update the phase 1 transform identifier. For example if the newly defined payload type can only be used in a certain new exchange type (like the proposed attribute payload inside the transactional exchange) then an old version will fail the negotiation because of the new exchange type, and a new version can detect that. There is no need to update the version number in that case. This allows for creating optional features in the ISAKMP protocol in such a manner that the implementors do not need to implement them all. Every time the minor version number or the phase 1 transform identifier is updated all the implementations MUST understand all the new mandatory payloads. Note that there is a risk of "mix and match" in this approach. In the case of a new generic payload that can be used in several exchanges etc, the minor version number or the phase 1 transform identifier MAY be updated. When a new payload type is added, the corresponding specification MUST indicate if the new payload has any security implications and whether a new version should fail the negotiation if the other end is using an old version. The specification MUST also indicate whether it is mandatory to implement the new feature or not. T. Kivinen [page 7]
INTERNET-DRAFT 5 August 1999 If the implementation receives an unknown private payload type it o SHOULD ignore the payload and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- PAYLOAD-TYPE notification back. If the implementation receives an unknown payload type from the RESERVED range and the version numbers are same, it MUST fail the negotiation, and it SHOULD send INVALID-PAYLOAD-TYPE notification back. If the implementation receives unknown payload type from the RESERVED range, and the other ends minor version number is newer, it o SHOULD ignore the payload and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- PAYLOAD-TYPE notification back. If the new version has sent out a payload of a type that is defined in a newer version of the protocol than an other end understands (this can be detected by checking the minor version number or the phase 1 transform identifier), and such that the payload has security implications then it MUST fail the negotiation. There may be a need to add a criticality flag in the generic payload header in the next version of ISAKMP [RFC-2408]. This allows an old version to detect immediately whether it can safely ignore the payload or whether it MUST fail the negotiation (in that case it SHOULD send an error notification). This criticality flag could be added to the reserved field of the generic payload header (there are 8 reserved bits inside the generic payload header). See section ``Reserved Fields'' for more information what old version would handle that criticality flag. 11. Vendor ID Payload The vendor ID payload is a payload that can be included anywhere in the phase 1 negotiation. It gives the other end a possibility to recognize the remote implementation. Vendor ID has two uses. The first one is that by sending a vendor ID payload the initiator specifies whose private-use values it has ability to use (it SHOULD only send only one vendor ID, or at least all the vendor ID payloads MUST have same owner, i.e they MUST NOT have overlapping private numbers defining different things). When initiator wants to use some private-use values in the exchange, it just adds its own vendor ID payload. When the responder receives that vendor ID payload along with the for example the SA payload it can find out whose private-use values are inside the SA payload by checking the vendor ID payload. The second use is to allow for vendor specific extensions, after both T. Kivinen [page 8]
INTERNET-DRAFT 5 August 1999 ends have sent and received familiar vendor IDs. Implementations MUST NOT fail a negotiation because of the presence of the vendor ID payload, i.e. they MUST be able to ignore it. If familiar vendor ID payloads have been exchanged (both sent and received) then implementations MAY do anything, including using private extensions, private payloads, new identity types, running nethack over the ISAKMP SA, etc. 12. Data Attribute Types and Values SA payloads and some other payloads in the ISAKMP contain data attributes. Data attribute consists of an attribute type and a value. The data attribute type and value number spaces are divided into two parts: The IANA range and the private-use range. The phase 1 data attribute types and values are defined in the IKE document and ISAKMP documents. This part should probably be separated from those documents to separate IKE DOI. The Phase 2 data attributes are defined in the DOI [RFC-2407] document. The private-use data attribute TYPES can be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values the sender is using. When adding new IANA registered data attribute TYPES the minor version number of the protocol SHOULD NOT be updated. When adding new IANA registered data attribute TYPES the phase 1 transform identifier MAY be updated. The private-use data attribute VALUES can also be used anywhere, and when they are used the sender SHOULD send vendor ID payload(s) specifying whose private-use values sender is using. When adding new IANA registered data attribute VALUES the minor version number of the protocol SHOULD NOT be updated. When adding new IANA registered data attribute VALUE the phase 1 transform identifier MAY be updated. 12.1. Data Attributes, Protocol and Transform IDs The proposal or transform payload MUST NOT be selected by the responder if it contains unknown protocol IDs, transform IDs, data attribute types, or data attribute values. This means that an initiator SHOULD always include a proposal without any private-use types or values so that if the other end does not understand them then it may select the transform or proposal without private-use types or values. 13. Reserved Fields T. Kivinen [page 9]
INTERNET-DRAFT 5 August 1999 Lots of payloads in the ISAKMP contain RESERVED fields that are defined to be zero and whose contents MUST be checked. This makes extension of the payloads very difficult to implement. Changing this so that their contents MUST be checked only if the version numbers are same makes it much easier to introduce backwards compatible extensions to the protocol in the future. When a new use of a RESERVED field is defined the minor version number MUST be updated. When a new use of a RESERVED field is defined, the corresponding specification MUST indicate if this new use of the RESERVED field has any security implications and whether a new version should fail the negotiation if the other end is using an old version and the new version tried to use this new usage for RESERVED field. If an old implementation receives a packet that contains a non-zero RESERVED field, and the version number of the other end is newer than the local one then it o SHOULD ignore the contents of the RESERVED field and continue, or it o MAY ignore the ISAKMP datagram. In that case it SHOULD send the INVALID-RESERVED-FIELD notification back. If the new version notices that the other end is using the old version it MUST fail the negotiation if it tried to use the RESERVED field in such a way that has security implications. If the new defined use of the RESERVED field does not have security implications it MAY continue the exchange. 14. Identity Type The identity type is used to specify the interpretation of the identity payload contents. The identity type is specified in the DOI document, but the generic structure is defined in the ISAKMP document. This generic structure contains this identity type value. When a new identity type is specified the minor version number or the phase 1 transform identifier SHOULD NOT be incremented. If an old version receives an unknown identity type, it MUST fail the negotiation, and it SHOULD send the INVALID-ID-INFORMATION notification back. A new version MAY always start with the new identity type and fall back to a previous more standard identity type every time separately, or it MAY cache this information for some time, or it MAY configure the identity type to be used manually. 15. Certificate Encoding Certificate encoding is used to specify the interpretation of the T. Kivinen [page 10]
INTERNET-DRAFT 5 August 1999 certificate payload contents. When a new certificate encoding type is added the minor version number or the phase 1 transform identifier SHOULD NOT be incremented. If an old version receives an unknown certificate encoding type, it o SHOULD just ignore the payload, and continue, or it o MAY fail the negotiation. In that case it SHOULD send the INVALID- CERT-ENCODING notification back. 16. Notify Message Type Messages containing notify payload are sent to either notify an error situation or to give out status information. Each notify payload contain a notify message type, which describes the message type. The notify message types are divided in the several separate ranges: 1 - 8191 ISAKMP error code range 8192 - 16383 Private use error code range 16384 - 24575 ISAKMP status code range 24576 - 32767 DOI status code range 32768 - 40959 Private use status code range If an unknown error (1 <= code <= 16383) notification type is received the receiver MUST treat it as a fatal error and abort the negotiation. If an unknown status (16384 <= code <= 40959) notification type is received the receiver MUST ignore the notification payload. For example, a new keep-alive protocol for the ISAKMP SA may be defined by just defining that both ends must send a new STILL-CONNECTED notification every 60 seconds. If the other end never sees those notifications, it just assumes that the other end does not support this feature, and ceases to send any further keep-alive packets. If that new STILL-CONNECTED status code is selected from the status code range, then old implementations will just ignore them. When using notifications, implementations must take care of what to do with the notifications which are not authenticated (i.e those received before the ISAKMP SA is ready). If there is no ISAKMP SA established with the remote host, then most of the notifications may still be T. Kivinen [page 11]
INTERNET-DRAFT 5 August 1999 trusted in order to avoid lengthy timeouts in error situations. If there is a ISAKMP SA established, then unauthenticated notifications SHOULD be ignored. 17. Domain of Interpretation Each SA payload (and some others like, notify, and delete payloads) specifies the domain of interpretation for the exchange. There is no version numbers in the DOI, so if new version of DOI is incompatible with the previous version a new DOI number MUST be allocated. In normal case there is no need to have version number in the DOI, and additions to it may be done without updating DOI number. If an unknown domain of interpretation is received the responder MUST discard the ISAKMP datagram and it SHOULD send the DOI-NOT-SUPPORTED notification back. This usually also means that the negotiation is aborted. When a new domain of interpretation is defined the minor version number MUST NOT be incremented. If ISAKMP DOI is modified there might be need to update the version numbers. 18. Security Considerations This document describes how to use the extension mechanisms to [RFC-2408] and IKE [RFC-2409]. Because some of those extensions might have security implications it is required that when those extensions are defined it is also explained what security implications they have and what the implementations supporting them should do if the other end does not support the extensions. One security problem comes from the [RFC-2408] and IKE [RFC-2409] protocol, because the version number, exchange type, and flags fields are not authenticated in the first version of IKE protocol. If a real security problem is later found from that version of protocol the implementors MUST make sure that they never fall back to any previous version because the attacker can force falling back to previous version by changing the version numbers inside the datagrams. Another security problem comes from the fact that there is no way to send authenticated notifications before the phase 1 (ISAKMP) SA is finished. This means that most of the error notifications about the Phase 1 exchange are sent without any kind of protection. 19. References [RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", November 1998. [RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)", November 1998 T. Kivinen [page 12]
INTERNET-DRAFT 5 August 1999 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", March 1997 [RFC-2407] Piper D., "The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 20. Authors' Addresses Tero Kivinen SSH Communications Security Ltd. Tekniikantie 12 FIN-02150 ESPOO Finland E-mail: kivinen@ssh.fi T. Kivinen [page 13]
