[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments about draft-ietf-ipsec-ike-01.txt
Valery Smyslov writes:
> On 16 Jun 99 at 1:06, Tero Kivinen wrote:
>
> [...]
> > I would really like to see two new kind of notifications here:
> >
> > Initiator Responder
> > ----------- -----------
> > HDR, SIG, [CERTs], Ni, N/D -->
> >
> > Where SIG (MUST be first payload) is signature of the HASH of the rest
> > of the payload. This would allow sending delete and error notification
> > payloads to the responder even when we do not have ISAKMP SA up yet
> > (for example sending error message of phase 1 (NO-PROPOSAL-CHOSEN)).
> >
> > In this case the SIG should also define the HASH algorithm to use, so
> > we should either use signature format that contains it or define it
> > somewhere else.
> What about the situation when Responder doesn't support signatures
> at all (i.e. performs only preshared key authentication) or supports
> different signature algorithm from that you've used to sign this
> message? In your example (sending NO-PROPOSAL-CHOSEN in phase 1) it
> will often be the case, making such notification almost useless.
> Also, such notification increases IKE vulnerability to DoS attack.
Then the responder ignores the SIG payload and it can still read the
clear text notification or delete, and act accordinly. Its policy then
dictates wheter it will trust the unauthenticated notification or
delete or not.
> > > The acknowledged Informational exchange is open to replay attacks.
> > There should also be comment here, that main mode (identity
> > protection) is open to man in the middle attack, that will reveal
> > initiators identity.
> As far as I understand, it is true for signature authentication
> methods only and isn't true for the other methods.
Yes, you are correct.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups:
References: