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

Re: Encryption in aggressive mode (IKE draft)



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





Follow-Ups: References: