IKEV2: Issue #1: Legacy Authentication

["Theodore Ts'o" <tytso@mit.edu>]

There has been no objection to the proposal sent by Ted on January
30th that the mechanism of the secure legacy authentication based on
the message sent by Derrell Piper on January 23rd, with some
modifications agreed to by Charlie and Hugo to address some
certificational weakness to the underlying cryptographic exchange.

One remaining open point, which was raised by Hugo, is whether or not
the identity of the initiator should be included in message 3 or not.
If it is included there, then an active attacker who pretends to be
the gateway can learn the claimed identity of the initiator.  If it not
included, however, then for some (most?) legacy authentication
systems, an extra round-trip will be necessary so that the responder
can send its certificate to the initiator and prove its identity
before initiator sends it identity down the D-H tunnel.

As Charlie observed, in the "normal" (non-legacy) IKE exchange, we
have already decided that when trading off between exposing the
identity of the initiator to an active attack, and exposing the
identity of the responder to an active attack, it was more important
to protect the identity of responder.  The reasoning behind this is
two-fold.  First of all, IKE is a peer-to-peer protocol where either
side can initiate, and secondly, an active attack against the
responder to determine its identity merely required initiating a
connection to it ("the polling attack"), whereas an active attack
against the initiator required impersonating the responder's IP
address, which is presumably more difficult.  (Please see Radia
Perlman's message of November 26, 2002 for a more detailed explanation
of this reasoning.)

In the case of legacy authentication, which tends to decidedly
assymetric, it has been argued that perhaps it is worthwhile to
protect the identity of the initiator.  Unfortunately, making IDi
optional in message three significantly complicates the protocol.  One
way of simplifying this would be to require that in the case of legacy
authentication, that IDi must always be omitted in message 3, and that
an extra round trip is added where IDi is sent message 5, and the EAP
exchange does not begin until message 6.  (This avoids needing to
specify on a per authentication mechanism whether or not the IDi needs
to be sent --- especially since in nearly all cases it will be
required anyway.)

In the recent round of discussion, no one besides Hugo has expressed a
desire for providing protection of the initiator's identity against
active attacks in the case of legacy authentication.  Therefore, in
the absence of such support, the current language in ikev2-04, which
requires IDi in message 3, shall stand.  If there are people who
believe that this should be made optional (trading off additional
complexity plus the extra round trip at setup time), please make your
preferences known.

					Barbara Fraser
					Ted Ts'o
					IPSEC working group chairs