[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
IP Security Protocol Working Group (IPSEC)                    T. Kivinen
INTERNET-DRAFT                               SSH Communications Security
draft-ietf-ipsec-ike-ext-meth-04.txt                    22 November 2000
Expires: 22 May 2001


                     ISAKMP & IKE Extension 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 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 practice of extensions handling in ISAKMP [RFC 2408]
and IKE [RFC 2409], so that a future version can be made without break-
ing the old existing versions.














T. Kivinen                                                      [page 1]


INTERNET-DRAFT                                          22 November 2000

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  . . . . . . . . . . . . . . . . . .  6
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  . . . . . . . . 10
13.  Reserved Fields  . . . . . . . . . . . . . . . . . . . . . . . . 10
14.  Identity Type  . . . . . . . . . . . . . . . . . . . . . . . . . 10
15.  Certificate Encoding   . . . . . . . . . . . . . . . . . . . . . 11
16.  Notify Message Type  . . . . . . . . . . . . . . . . . . . . . . 11
17.  Domain of Interpretation   . . . . . . . . . . . . . . . . . . . 12
18.  Security Considerations  . . . . . . . . . . . . . . . . . . . . 12
19.  References   . . . . . . . . . . . . . . . . . . . . . . . . . . 13
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 the [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                                          22 November 2000

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 resend the notification if the other end
resends its own ISAKMP datagram (in case the error notification was
lost). This resending SHOULD also be limited to a reasonable level.

5.  Order of Checking

The order of checks performed for an ISAKMP datagram SHOULD be the
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 IKE defined in
RFC 2409, major and minor version numbers are not authenticated. Thus,
when they are later changed to be authenticated, there might be the
possibility of a version rollback attack where the attacker forces
negotiating parties to fall back to the RFC 2409 version of IKE.

The major version number is changed 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.

The minor version number is changed when new payloads are defined or
other minor changes in the protocol take place. The older versions can


T. Kivinen                                                      [page 3]


INTERNET-DRAFT                                          22 November 2000

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 a host started the negotiation using version number
1.1, it MUST use that during the whole negotiation. Separate
negotiations MAY have different version numbers, i.e. a newer version
may restart negotiation, and start using an older version number. Both
ends use their own version number, so it is completely legal for one end
to start with 1.1 and for the other end to respond with 1.0.

Phase 1 and phase 2 negotiations are separate negotiations. So, a phase
1 negotiation that creates ISAKMP SA may use version X, and a 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 the same. Because of this phenomenon, incrementing the minor
version number SHOULD be avoided if it is not absolutely necessary.

An 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 a
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                                          22 November 2000

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 the same version if necessary.

The new version MAY always start with the latest version number and fall
back to the previous version separately each time, 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 a 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  a new certificate encoding type is added (see section ``Certificate
   Encoding'')

o  a new identity type is defined (see section ``Identity Type'')

o  new phase 1 transform identifiers are defined (see section ``Phase 1
   Transform Identifier'')

The minor number MUST NOT be updated if

o  a new domain of interpretation is defined (see section ``Domain of
   Interpretation'')



T. Kivinen                                                      [page 5]


INTERNET-DRAFT                                          22 November 2000

7.  Phase 1 Transform Identifier

Phase 1 SA payload contains a transform identifier that specifies the
key exchange method used. It can be used to negotiate the key exchange
method and version. This is different from the minor version number in
the manner that the other end MUST send back exactly the same transform
ID (i.e. it MUST select one of those values offered). It cannot modify
the SA payload which contains the transform identifier.

The selected exchange type may limit the possibility to negotiate
different key exchange methods, because the 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.  If old
existing key exchange specific exchange types are modified, then the
phase 1 transform identifier SHOULD be updated.

A new version MAY always start with the new exchange type and fall back
to a previous, more standard exchange type separately each time, 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.


T. Kivinen                                                      [page 6]


INTERNET-DRAFT                                          22 November 2000

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

o  MAY fail the negotiation. In that case it SHOULD send the INVALID-
   FLAGS notification back.

If a new version notices (from the version numbers) that the other end
is using an old version, 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.

Note that RFC 2409 does not protect vendor ID payloads from tampering,
so implementations should not enable anything based on vendor IDs if
that feature has security implications.

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


T. Kivinen                                                      [page 7]


INTERNET-DRAFT                                          22 November 2000

Every time the minor version number or the phase 1 transform identifier
is updated, all the implementations MUST understand all the new
mandatory payloads. 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.

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 (both ISAKMP major/minor version numbers
and phase 1 transform ID) are the same, it MUST fail the negotiation,
and it SHOULD send INVALID-PAYLOAD-TYPE notification back.

If the implementation receives an unknown payload type from the RESERVED
range, and the minor version number (or the phase 1 transform ID) of the
other end 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 the other end understands (this can
be detected by checking the minor version number), and 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 would allow 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 about how an old version should handle the 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. These payloads are not authenticated in the
RFC 2409 version of the IKE.


T. Kivinen                                                      [page 8]


INTERNET-DRAFT                                          22 November 2000

The vendor ID has two uses. The first one is that by sending a vendor ID
payload along the SA payload, the initiator specifies whose private-use
values it is using (it SHOULD only send only one vendor ID payload, or
at least all the vendor ID payloads 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(s). When the responder receives the
vendor ID payload(s) along with 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
ends have sent and received familiar vendor IDs.

Implementations MUST NOT fail a negotiation because of the presence of
the vendor ID payload(s), 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 the 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 VALUES, the phase 1 transform identifier MAY
be updated.



T. Kivinen                                                      [page 9]


INTERNET-DRAFT                                          22 November 2000

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

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 the 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 a RESERVED field.

If an old implementation receives a packet that contains a non-zero
RESERVED field, and the minor 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.


T. Kivinen                                                     [page 10]


INTERNET-DRAFT                                          22 November 2000

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 separately each time, or it
MAY cache this information for some time, or it MAY manually configure
the identity type to be used.

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



T. Kivinen                                                     [page 11]


INTERNET-DRAFT                                          22 November 2000

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 sending 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 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 a new version of DOI is incompatible
with the previous version, a new DOI number MUST be allocated. In the
normal case, there is no need to have a version number in the DOI, and
additions to it may be done without updating the 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 a
need to update the DOI number.

18.  Security Considerations

This document describes how to use the extension mechanisms defined in
ISAKMP [RFC 2408] and IKE [RFC 2409]. Because some of those extensions
might have security implications, it is required that when new
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 ISAKMP [RFC 2408] and IKE [RFC 2409]
protocol, because the version number, exchange type, and flags fields
are not authenticated in the RFC 2409 version of IKE protocol. The
[REVISED-HASH] describes a way to fix this problem by updating the phase
1 transform id number.

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 a
previous version by changing the version numbers inside the datagrams.


T. Kivinen                                                     [page 12]


INTERNET-DRAFT                                          22 November 2000

Also the vendor ID payloads, notifications etc. inside the phase 1
packets are not authenticated in the RFC 2409 version of IKE. This means
that implementations SHOULD NOT enable any security critical extensions
based on those unathenticated payloads.

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

[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

[REVISED-HASH] Kivinen T., "Fixing IKE Phase 1 & 2 Authentication
HASHs", November 2000

20.  Authors' Addresses

    Tero Kivinen
    SSH Communications Security Corp
    Fredrikinkatu 42
    FIN-00100 HELSINKI
    Finland
    E-mail: kivinen@ssh.fi


















T. Kivinen                                                     [page 13]