[Vpn-help] Issues with ForiGate XAuth

[Matthew Grooms]

All,

	Noach was kind enough to test Shrew Soft VPN Client with his ForiGate 
Firewlal/VPN Appliance. I looked into some problems that occurred with 
XAuth enabled and here are my findings. I wanted to forward this to the 
list in case anyone else was evaluating the use of a FortiGate with the 
VPN Client.

Thanks,

-Matthew

-------- Original Message --------

Noach,

	I am sorry to say that the ForiGate is severely flawed in its XAuth 
implementation. It supports it ( sort of ) but not as the RFC says it 
should. Here is a detailed explanation that you can send to your vendors 
tech support people ...

 From the ike-xauth-02 draft ...

7.2 Notification via Authentication Method Types

    The following method is used to negotiate the use of XAUTH via the
    SA payload.  New authentication methods are defined which allow the
    edge device to choose an authentication method which mandates XAUTH.
    This allows the edge device to notify the remote device that an
    XAUTH exchange will follow the phase 1 exchange.  Edge devices which
    conform to this document MUST support this method.

    The following values relate to the ISAKMP authentication method
    attribute used in proposals.  They optionally allow an XAUTH
    implementation to propose use of extended authentication after the
    initial phase 1 authentication.  Values are taken from the private
    use range defined in [IKE] and should be used among mutually
    consenting parties.  To ensure interoperability and avoid
    collisions, a Vendor ID is provided in the "Vendor ID" section of
    this document.

     Method                                            Value
    ------------------------------                     -----
     XAUTHInitPreShared                                65001
     XAUTHRespPreShared                                65002
     XAUTHInitDSS                                      65003
     XAUTHRespDSS                                      65004
     XAUTHInitRSA                                      65005
     XAUTHRespRSA                                      65006
     XAUTHInitRSAEncryption                            65007
     XAUTHRespRSAEncryption                            65008
     XAUTHInitRSARevisedEncryption                     65009
     XAUTHRespRSARevisedEncryption                     65010

... end of excerpt.

	For the test, the FortiGate was configured with "PreSharedKey", XAuth 
"Enabled as Server" with "PAP" enabled. This means that an Initiator 
should propose XAUTHInitPreShared to the FortiGate in an SA payload. But 
when this is performed, the FortiGate responds with a Informational 
message containing a NO-PROPOSAL-CHOSEN notification. In other words, 
the Fortigate doesn't understand the new private methods outlined in the 
ike-xauth-02 draft. They shouldn't claim to support XAuth if they don't 
follow the standard.

	Now I did say that the device sort-of has support XAuth. What I mean is 
that when a peer proposes a standard "pre-shared key" method when the 
FortiGate has XAuth "Enabled as Server" selected, it will challenge the 
peer with an XAuth request following phase1 completion. The standard 
"pre-shared key" method is defined in in rfc2409 ...

- Authentication Method
       pre-shared key                      1
       DSS signatures                      2
       RSA signatures                      3
       Encryption with RSA                 4
       Revised encryption with RSA         5

... and its support is mandatory for an IKE capable device. The issue is 
that "pre-shared key" doesn't mean "XAUTHInitPreShared". Thats why they 
defined new private methods. Two peers need to be able to agree on the 
method during SA negotiations for XAuth to work properly.

	The other problem ( mentioned in the XAuth snippet above ) is that the 
Fortigate doesn't produce a Vendor ID that notifies the client that 
XAuth is possible. It doesn't produce a Vendor ID for NAT-T either so I 
am not terribly surprised.

	The bottom line is that the device is not RFC compliant. If they claim 
to have support for a standard, they should support it completely. Only 
implementing half a standard is a good way to not be compatible with 
other implementations that do take the standard seriously.

-Matthew