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

Comment on the ISAKMP/Oakley resolution draft



I have a concern regarding the latest version of the ISAKMP/Oakley
resolution draft (draft-ietf-ipsec-isakmp-oakley-03.txt).

The previous version of the draft (-02) allowed a mode of operation
which is no longer possible under the new draft.  When using pre-
shared keys for authentication (in section 5.3), one can now use
Oakley Main Mode only if the pre-shared keys are identified by the
IP addresses of the peers.  One cannot use keys associated with
some other identifier supplied by the initiator (denoted as IDii
in the draft), because that payload is encrypted with SKEYID_e,
which is derived in part from the pre-shared key in question (as
described at the beginning of section 5 - the pre-shared key is
used to derive SKEYID, which in turn is used to derive SKEYID_e).
The -02 version of the draft did allow Main Mode to be used for
any initiator identifier, because SKEYID was derived in a different
manner which did not include the pre-shared key.

While the -03 draft does state that one can use Oakley Aggressive
Mode instead for pre-shared keys, Agressive Mode does not provide
identity protection (i.e., encryption of IDii) as Main Mode does.

The root cause of the problem seems to be that the -03 draft
introduces a new common algorithm for deriving HASH_I and HASH_R
which uses SKEYID (beginning of section 5).  In the -02 draft,
HASH_I and HASH_R were derived differently, depending on which
authentication method (signatures, public keys, or pre-shared keys)
was used.  When using pre-shared keys, the key clearly must be used
to derive the hash in order to authenticate the peers to one another.
In order to allow for this, the use of the pre-shared key was moved
into the derivation for SKEYID.  However, doing so introduces a
dependency on the pre-shared key for SKEYID_a and SKEYID_e, which
did not exist in the -02 draft.

While I certainly believe that having common algorithms across
different authentication methods wherever possible is a Good Thing
in terms of reducing complexity, I do not feel that that justifies
eliminating a useful mode of operation which was previously allowed.
That being said, I do believe there exists a method by which the
new common HASH_I and HASH_R derivation can remain.  Just as HASH_I
and HASH_R require additional processing to derive SIG_I and SIG_R
when using signatures for authentication (section 5.1), one could
require an additional step which combines HASH_I and the key into
a HASH_I1 (likewise for HASH_R and HASH_R1).  This would allow
the pre-shared key to be removed from the derivation of SKEYID
without losing authentication capability.

Of course, I am open to other possible solutions to this problem.
My goal here is to allow for a useful mode of operation (pre-shared
keys identified by IDii with identity protection provided by Oakley
Main Mode) to continue as it did in the prior version of the draft.

-Shawn Mamros
E-mail to: smamros@newoak.com