Re: Phase 1 Re-keying Implementation Identification

[Dan Harkins <[e-mail]>]

<commercial advertisement>
  Note that this is the technique used in CRACK. So CRACK will also
authenticate all optional payloads as well as the outer ISAKMP header.
</commercial advertisement>

  If the attacker changes the responder's selection the exchange will
fall apart due to the different sides having different attributes of
the negotiated SA. Either the hash will be different, or the encryption
algorithm, or the D-H public value, etc. but the exchange should fall
apart in this case.

  Dan.

On Wed, 24 Nov 1999 02:42:24 +0200 you wrote
> Valery Smyslov writes:
> > > The good thing about the SA payloads are that they are authenticated,
> > > so attacker cannot remove the features, as they can when you are using
> > > the vendor id payloads.
> > But attacker can always change responder's selection, because SAr is 
> > not explicitly authenticated in IKE.
> 
> True. I forgot that one. I just submitted a draft that will also that
> problem (it will also fix the original problem that vendor id payloads
> are not authenticated).
> 
> Here is a copy of that draft:
> ----------------------------------------------------------------------
> IP Security Protocol Working Group (IPSEC)                    T. Kivinen
> INTERNET-DRAFT                               SSH Communications Security
> draft-ietf-ipsec-ike-hash-revised-00.txt                23 November 1999
> Expires: 23 May 2000
[snip]