[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Encryption in aggressive mode (IKE draft)
Hello,
I was reading ISAKMP & IKE documents,
and I have found that aggressive mode in IKE draft
is a bit different from one in ISAKMP draft.
> AGGRESSIVE EXCHANGE
>
>_#_____Initiator___Direction______Responder________________________NOTE____________________
>(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
> NONCE; IDii and Key Exchange
>
>(2) <= HDR; SA; KE;
> NONCE; IDir; AUTH
> Initiator Identity
Verified by Responder
> Key Generated
> Basic SA agreed upon
>(3) HDR*; AUTH =>
> Responder Identity
Verified by Initiator
> SA established
Note that the last message is encrypted here, except the header of
course.
Now, let's take a look at what we have in IKE draft.
Section 5.1:
> Aggressive mode with signatures in conjunction with ISAKMP is
> described as follows:
>
> Initiator Responder
> ----------- -----------
> HDR, SA, KE, Ni, IDii -->
> <-- HDR, SA, KE, Nr, IDir,
> [ CERT, ] SIG_R
> HDR, [ CERT, ] SIG_I -->
Section 5.2:
> Aggressive Mode authenticated with encryption is described as
> follows:
>
> Initiator Responder
> ----------- -----------
> HDR, SA, [ HASH(1),] KE,
> <IDii_b>Pubkey_r,
> <Ni_b>Pubkey_r -->
> HDR, SA, KE, <IDir_b>PubKey_i,
> <-- <Nr_b>PubKey_i, HASH_R
> HDR, HASH_I -->
Section 5.3:
> Aggressive Mode authenticated with the revised encryption method is
> described as follows:
>
> Initiator Responder
> ----------- -----------
> HDR, SA, [ HASH(1),]
> <Ni_b>Pubkey_r,
> <KE_b>Ke_i, <IDii_b>Ke_i
> [, <Cert-I_b>Ke_i ] -->
> HDR, SA, <Nr_b>PubKey_i,
> <KE_b>Ke_r, <IDir_b>Ke_r,
> <-- HASH_R
> HDR, HASH_I -->
Section 5.4:
> Aggressive mode with a pre-shared key is described as follows:
>
> Initiator Responder
> ----------- -----------
> HDR, SA, KE, Ni, IDii -->
> <-- HDR, SA, KE, Nr, IDir, HASH_R
> HDR, HASH_I -->
In all above cases, the last message is not encrypted, which contradicts
aggressive mode in ISAKMP draft.
For instance, instead
> HDR, HASH_I -->
we would expect
> HDR*, HASH_I -->
I propose that all payloads following the header
in the last message must be encrypted and IKE draft
must be changed accordingly.
I assume, there might be a reason for what
we have in IKE draft now. But since initiator
and responder have finished KE exchange,
we should be able to encrypt any following
message. There is no reason for waiting.
Thanks,
Yuri Poeluev
Certicom Corp.
Follow-Ups: