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

Re: Encryption in aggressive mode (IKE draft)



  IKE is using ISAKMP as a framework and a language in which
to define exchanges. Some things are not exactly identical
between the two. Aggressive mode is one of those things.
The Informational Exchange is another. Look closer and you
might find others. This is not a problem.

  By the way, suggestions to change either
draft-ietf-ipsec-isakmp-oakley-08.txt or
draft-ietf-ipsec-isakmp-10.txt are about 6 months late.

  Dan.

On Tue, 18 Aug 1998 09:56:43 EDT you wrote
> Hi Hugo,
> 
> Thanks for clarifications on this matter.
> I agree with the reasons you wrote about.
> However, this mode is not exactly the mode
> described in "draft-ietf-ipsec-isakmp-10".
> Those reasons would be successfully applied to
> "draft-ietf-ipsec-isakmp-10" draft, don't you agree?
> Should it not be a new aggressive mode ("revised" )
> in "draft-ietf-ipsec-isakmp-oakley-08" draft?
> If not, I suggest, aggressive mode in "draft-ietf-ipsec-isakmp-10"
> must have no encryption as well as "his brother" :-)
> in "draft-ietf-ipsec-isakmp-oakley-08".
> 
> Thanks,
> Yuri
> 
> 
> Hugo Krawczyk wrote:
> 
> > 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.
> > >
> 
> 
> 


References: