[Openswan dev] CheckPoint SecureClient Hybrid mode authentication

[Chris Poon]

This mostly came from reverse engineering how a CheckPoint SecureClient
interacts with a CheckPoint NG VPN using Hybrid mode. As far as I have looked,
it seems like at least up till FP3 it's still the only way to do 3rd party
authentication (besides Public key and shared secret that is)

Quoting Michael Richardson <mcr at xelerance.com>:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> Chris, thank you for the patches.
> 
> It looks to me like CPSP mode is just pre-XAUTH checkpoint stuff?
> CheckPoint Hybrid mode more-or-less became XAUTH after some rototiling.
> 
> Does CP not support XAUTH mode?
> 
I haven't looked at R55, but if it does, I might have to lobby the security
guys to upgrade. Although I'm pretty convinced that the latest release still
used pre-XAUTH way of user authentication (all the authentication types and
messages are non-standard and even the latest SecureClient R56 will work with
FP3 firewall so I can't imagine CheckPoint would have changed the way it
authenticates)

> While the patches are relatively simple, I wonder if they are really
> worth including.  Is this the only mode that the Checkpoint can be
> configured? Doesn't CP support XAUTH on their clients as well?  
> 
At least not for SecureClient (the CheckPoint VPN client). It seems to default
to Hybrid mode if certificates aren't used. I know we went with Hybrid mode
because we use SecurID for authentication. I can conirm with my colleague
about the latest SecureClient whether it has such options

> In particular, I would like to have server-side patches, and a test case
> as well. That would make it easy to incorporate into openswan.
> 
I haven't tried writing any code that allows Openswan to work with a
SecureClient, mostly because there are some proprietary exchanges ahead of
time to setup the topology on the client. I've tried hacking the userC.C on
the client side (the topology file on SecureClient) to work with Openswan to
no avail - it always break on some weird things that I don't yet have time
to look at.

> Why is the id.c patch necessary? 
> One can already specify specify user at fqdn in the ID type. And setting
> the id->name.len = 0 can not be correct. It should be set to the length
> of the string.
>
As usual, CheckPoint does things its own way and send the User ID without @,
if it is sent outside of the XAUTH sequence. Basically, SecureClient will send
a type of ID_USER_FQDN, but null data (possibly RFC breaking). I can't think
of any other way that can force a null ID_USER_FQDN, and without that, the
VPN server won't bother with XAUTH at all. I know that sending an ID with @
will not work - and to replicate the key exchange between CheckPoint VPN and
SecureClient, I just wrote the code to send a null ID of type ID_USER_FQDN
just like the SecureClient does to get me through to the meat of the exchange.