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