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

Re: Encryption in aggressive mode (IKE draft)




Here there are some clarifications regarding the question in the
attached note (about encrypting/not encrypting the third message
in aggressive mode)

There is no cryptographic functionality to the encryption of the third
message in aggressive mode. Furthermore, under the encryption modes,
there is  some performance advantage if you do not encrypt that message.
A short explanation: 

Case I: signature mode.
In the case of signature mode the encryption of that message
in the non-agressive version serves to hide the signatures
and identities as required for providing anonymity of the end points
from eavesddroppers. However in aggressive mode of the signature
mode anonymity is not provided anyway (identities are sent in the clear
in the first message) so the encryption of that message can be safely
avoided.

Case II: encryption mode.
In encryption mode anonymity (or identity protection) is provided ALSO in
aggressive mode. However, the third message does not need to be 
encrypted for this purpose since it does not carry any identity
information.
The advantage of NOT encrypting the third message is that it allows
the parties to carry the computation of the DH key (g^xy) after
the exchange is over. Indeed, the DH key is needed only to derive the
SKEYID_* keys but those are not used during the phase I exchange.

Hugo

On Mon, 17 Aug 1998, Yuri Poeluev wrote:

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