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

Re: Comment on the ISAKMP/Oakley resolution draft



Shawn, Hugo and I discovered this too. One solution Hugo has
is to give the shared key an ID (like an SPI). This ID could
be sent in ID payload together with KE and NONCE. Another
possibility I could see is to augment the DOI a little bit
and send the key ID in "situation".


Pau-Chen

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


Follow-Ups: