Re: [FW1] VPN FW1->PIX, IKE Phase1 Stage2 Problem

[CryptoTech <cryptotech@FW1-NOSPAMgmx.de>]

Martin,
The cookie time is relative to the time of initialization.  That is, its purpose is
to ensure that the response packets, and indeed the entire communication is realtime
and not a playback hack.  What I have found is most likely in a pix connection
scenario is a 'no proposal chosen' due to differences in the IKE rekey interval.  If
you can check this on the cisco, you will most likely need to configure check point
to agree.  Unfortunately, Cisco chose not to make this field negotiable, as the
standard recommends.

Cisco's default key renegotiation time should be in their documentation.  Also, on
the encrypt rule, please recheck that the rule is set to use des and md5 with NO
perfect forward secrecy.

In a worst case scenario, maybe you could provide me with an IKE debug for the
negotiation.  That would most certainly clarify the details of the problem.

CryptoTech

Martin WF Hui wrote:

> Hi,
>
> Please kindly tell me where i can check the cookie time.
>
> Thanks,
>
> Regards,
>
> martin
>
> -----Original Message-----
> From: owner-fw-1-mailinglist@lists.us.checkpoint.com
> [mailto:owner-fw-1-mailinglist@lists.us.checkpoint.com]On Behalf Of
> CryptoTech
> Sent: Tuesday, 20 February 2001 12:34
> To: Cedric
> Cc: fw-1-mailinglist@lists.us.checkpoint.com
> Subject: Re: [FW1] VPN FW1->PIX, IKE Phase1 Stage2 Problem
>
> Cedric,
> IKE consists of two official phases,
> Phase one is a three or six packet handshake that negotiates 4 keys skey_id,
> skey_id_r, skeyid_a, and skeyid_e.
>
> In phase one stage one, assuming aggressive mode (you did not specify, but
> unless
> you disabled it on fw1 it is probably what you are using.)
> Station A sends a proposal, as well as a dh key, along with a time sensitive
> cookie
> to the remote host.
>         The proposal contains suggestions for the transform to be used in
> subsequent
> ike negotiations, ie 3des/sha1,des/md5,etc
>
> Station B responds to A with a dh key, the originating cookie, along with a
> new
> cookie initiated by station b.  The transform reponse is encrypted using a
> derivative of the dh key exchange producing the 4 keys mentioned earlier.
> Skey_id
> is the root key for subsequent ike negotiation, skeyid_r  is a root key to
> be used
> for SA negotiations (phase 2), skeyid_a for header authentication, and
> skeyid_e for
> the actual ike packet encryption.
>
> Station A will then send an ACK packet using both cookies and encrypting the
> ack
> using the negotiated skeyid.
>
> Some places to look:  check out the encrypt rule on the firewall to make
> sure that
> the actual rule properties lock you into des (if that is your transform of
> choice.)
> Also, you may consider forcing the use of Main mode, as I have heard of
> problems
> with the cookie time format between check point and cisco.
>
> This one sounds intriguing,
> Let me know if I can be of further help,
> CryptoTech
>
> Cedric wrote:
>
> > Hello
> >
> >      We have a problem with setting up a VPN between FW1 (4.1 SP3 on
> >      Solaris) and a Cisco PIX firewall.
> >
> >      We see such entries in the logs
> >      "IKE Log: Sent Notification: no proposal chosen <phase1 stage2>
> >       Negotiation Id: 6t3zd51f68z41a5f-cba186ade992a71f"
> >
> >      I can see two related mails in the archives, one suggest to add
> >      "3DES" in the objects for both entries (we use DES), wthis
> >      completely screwed up the VPN (which might indicate a problem)
> >           We didn't "send" such messages anymore, but the remote
> >           host did (that's what the logs say)
> >
> >      Anyone know what this "phase1 stage2" actually is ?
> >      How can I solve this problem ?
> >      We have idea how the PIX is set up, but it has been set up
> >      according the CKP pdf documents.
> >
> >      Thanks in advance for any pointer.
> >
> >
> ============================================================================
> ====
> >      To unsubscribe from this mailing list, please see the instructions at
> >                http://www.checkpoint.com/services/mailing.html
> >
> ============================================================================
> ====
>
> ============================================================================
> ====
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ============================================================================
> ====
>
> ================================================================================
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ================================================================================



================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================