[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encryption in aggressive mode (IKE draft)
Now that isakmp and ike are moved to proposed standards
I would suggest that any inconsistencies between those
are generally resolved in favor of IKE. The latter
is responsible for defining the details of the key exchange
protocol. The former is a protocol framework.
Hugo
On Tue, 18 Aug 1998, Yuri Poeluev 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: