[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-kivinen-ike-ext-meth-00.txt



Here is a draft I promised to send to the list about the extension
mechanisms in the IKE. I would like to hear your comments about this.
----------------------------------------------------------------------
Network Working Group                                         T. Kivinen
INTERNET-DRAFT                               SSH Communications Security
draft-kivinen-ike-ext-meth-00.txt                          17 March 1999
Expires in six months


                         IKE Extensions Methods

Status of This memo

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
IKE [RFC-2409].




















T. Kivinen                                                      [page 1]

INTERNET-DRAFT                                            17 March 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.  Exchange type   . . . . . . . . . . . . . . . . . . . . . . . . .  5
8.  Flags Inside the Generic Packet Header  . . . . . . . . . . . . .  5
9.  Payload Types   . . . . . . . . . . . . . . . . . . . . . . . . .  6
10.  Vendor ID Payload  . . . . . . . . . . . . . . . . . . . . . . .  7
11.  Data Attribute Types and Values  . . . . . . . . . . . . . . . .  7
  11.1.  Data Attributes, Protocol and Transform IDs  . . . . . . . .  8
12.  Reserved Fields  . . . . . . . . . . . . . . . . . . . . . . . .  8
13.  Identity Type  . . . . . . . . . . . . . . . . . . . . . . . . .  9
14.  Certificate Encoding   . . . . . . . . . . . . . . . . . . . . .  9
15.  Notify Message Type  . . . . . . . . . . . . . . . . . . . . . .  9
16.  Domain of Interpretation   . . . . . . . . . . . . . . . . . . . 10
17.  Security Considerations  . . . . . . . . . . . . . . . . . . . . 10
18.  References   . . . . . . . . . . . . . . . . . . . . . . . . . . 10
19.  Authors' Addresses   . . . . . . . . . . . . . . . . . . . . . . 11



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
not support it. The terms should always be interpreted only in the


T. Kivinen                                                      [page 2]

INTERNET-DRAFT                                            17 March 1999
 
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.

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 packet (in case the error
notification was lost).

5.  Order of Checking

The order of checks performed for packet 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 header

o  Packet specific checks.

6.  ISAKMP Major and Minor Version Numbers

All IKE packets contain version numbers, which describe the major and
minor version numbers of the sending party. In IKE version 1.0 these
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 version 1.0. This can be prevented by disabling the version
1.0 protocol.

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
minor changes in the protocol take place. The older versions can still
process the generic packet structure, but there might be small


T. Kivinen                                                      [page 3]

INTERNET-DRAFT                                            17 March 1999
 
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 with 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 rollover 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).

6.1.  ISAKMP Major Version Number

If an old version receives a packet 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 packet.
This gives the other end the opportunity to obtain the version number
supported by the sender of the notification.  The received packet MUST
then be discarded (the old version cannot parse anything else in the
packet 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 packet with a minor version newer than its
own, it

o  SHOULD continue processing the packet, or it

o  MAY discard the packet. In that case it SHOULD send the INVALID-
   MINOR-VERSION notification back.

In any case the old version MUST respond with a packet containing the


T. Kivinen                                                      [page 4]

INTERNET-DRAFT                                            17 March 1999
 
local minor version number 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.

7.  Exchange type

An exchange type defines a generic packet exchange between two
negotiating parties. It defines the number of packets in the exchange,
the generic meaning of the packets (i.e. in main mode the first two
packets exchange SA payloads, the next two packets are used for the key
exchange, and the final two packets are used to exchange identities and
to authenticate the exchange).

If an implementor wants to add new packets 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 packet that contains an exchange type it
does not understand it SHOULD send back the INVALID-EXCHANGE-TYPE
notification. Also it MUST ignore the packet.

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 exchange types are added, the minor version number 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.

8.  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 packet 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 5]

INTERNET-DRAFT                                            17 March 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.

9.  Payload Types

Each payload inside a packet 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 SHOULD 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 minor version number SHOULD be updated.

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 IKE protocol in such a
manner that the implementors do not need to implement them all.  Every
time the minor version number is updated all the implementations MUST
understand all the new mandatory payloads. Note that there is a risk of
"mix of match" in this approach. In the case of a new generic payload
that can be used in several exchanges etc, the minor version number 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.

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-


T. Kivinen                                                      [page 6]

INTERNET-DRAFT                                            17 March 1999
 
   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
first in a newer version of the protocol than an other end understands
(this can be detected by checking the minor version number), 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 IKE [RFC-2409]. 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).

10.  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 is using (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).

The second use is to allow for vendor specific extensions, after both
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.

11.  Data Attribute Types and Values



T. Kivinen                                                      [page 7]

INTERNET-DRAFT                                            17 March 1999
 
SA payloads and some other payloads in the IKE 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. 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 number of the protocol 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 number of the protocol
SHOULD NOT be updated.

11.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.

12.  Reserved Fields

Lots of payloads in the IKE 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.

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


T. Kivinen                                                      [page 8]

INTERNET-DRAFT                                            17 March 1999
 
o  MAY ignore the message. 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.

13.  Identity Type

The identity type is used to specify the interpretation of the identity
payload contents.

When a new identity type is specified the minor version number MUST 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.

14.  Certificate Encoding

Certificate encoding is used to specify the interpretation of the
certificate payload contents.

When a new certificate encoding type is added the minor version number
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.

15.  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.

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 <= 32767) notification type is
received the receiver MUST ignore the notification payload.



T. Kivinen                                                      [page 9]

INTERNET-DRAFT                                            17 March 1999
 
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
trusted in order to avoid lengthy timeouts in error situations. If there
is a ISAKMP SA established, then unauthenticated notifications should
propably be ignored.

16.  Domain of Interpretation

A domain of interpretation describes all the phase 2 numbers to be used
in that domain of interpretation. If an unknown domain of interpretation
is received the responder MUST discard the packet 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.

17.  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 version 1.0 protocol. If a real security
problem is later found from the 1.0 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 packets.

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.

18.  References

[RFC-2408] Maughan D., Schertler M., Schneider M., Turner J., "Internet
Security Association and Key Management Protocol (ISAKMP)", November


T. Kivinen                                                     [page 10]

INTERNET-DRAFT                                            17 March 1999
 
1998.

[RFC-2409] Harkins D., Carrel D., "The Internet Key Exchange (IKE)",
November 1998

[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

19.  Authors' Addresses

    Tero Kivinen
    SSH Communications Security Ltd.
    Tekniikantie 12
    FIN-02150 ESPOO
    Finland
    E-mail: kivinen@ssh.fi



































T. Kivinen                                                     [page 11]
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/