Bug: Incorrect IKEv2 Digital Signature by FortiClient 7.4.4/7.4.5

[strongX509]

Trying to set up an IKEv2 client-certificate-based IPsec connection from a FortiClient 7.4.4 to a FortiGate VPN Gateway results in the following error in the FortiGate log when evaluating the received IKE_AUTH request:
ike V=root:0:IPSec-Client:176: certificate validation succeeded
ike V=root:0:IPSec-Client:176: signature verification failed
ike V=root:0:IPSec-Client:176: auth verify done
ike V=root:0:IPSec-Client:176: responder AUTH continuation
ike V=root:0:IPSec-Client:176: authentication failed

Parsing the received IKE_AUTH request sent by the FortiClient, we see that the AUTH payload of type Digital Signature (14) defined by RFC 7427 is missing the one octet ASN.1 length field and the following ASN.1 OID of the Algorithm Identifier. Only the raw 64 octet ECDSA 256 Bit Signature has been added:

2F     Next Payload: 47 - CP
00     C/Reserved
0048   Length: 72 Octets = 8 + 64 Octets (2*256 Bits)
0E     Auth Method: 14 - Digital Signature (RFC 7427)
000000 Reserved
       ASN.1 Length: ? (missing)
       ASN.1 Algorithm Identifier (OID): ? (missing)
419F71D30B3E1B4D5BFE153186893C1EC589BF954F4CC5A3C679480985D35B22

4715542B4422AA17F7C679BAE4C0ED2334A8C64D64BA6BBC6F333D423B866D93
 

The same failure when using an 3072 Bit RSA with SHA256 digital signature where only the raw 384 octet signature is present but the preceding ASN.1 OID is missing as well:
2F     Next Payload: 47 - CP
00     C/Reserved
0188   Length: 392 Octets = 8 + 384 Octets (3072 Bits)
0E     Auth Method: 14 - Digital Signature (RFC 7427)
000000 Reserved
       ASN.1 Length: ? (missing)
       ASN.1 Algorithm Identifier (OID): ? (missing)

65F376FF7E21AC8B5D6A61FF3B4A61C13A2F7CE12835F2E8579F1FA966D3C66C

4FBA28D07F17AD8E5D0696FAD5095533E4102A5C3A31456D38C59D7E77EFF33C
BBBA12B225FFA14C340149A09ECB7E705719726DAE11CC8FA55F2A522D51BCBB

0EB8FA4DDFFABBB567BF4C822D8F20B45B522985B711374984BC269FDF66E024
60A555237F07FAA444FB39CAB903214E5FB903D7512DBD3CD31FE233D9D92403

CE03B6F8FDEFF965F024AA0A21364CD040B44D2FA3D71240D2EE2B77E0C789AA
0AD4CEFF9BB3CEC690FEAA2FA63A12189A0263E24EB7B633F2406F2CD37E047C

C33AEF9BB3FFC87B81864C9A18059393A5139C49F504F41D0C2D7E94FA61FA06
7BC5AE52282C3C0455686278A342D77FDE1B7A9F24BADB0F5B9FDE7C8AACB25C

7ED68B005E9461C3E5580E295C89D64940C531E968E777DD85182EEFAFB1523C
117EBA9A2F74AC4BD4B7AC8DF27DB5A2163DA3B0AB9513363E69975C858879DA

56F8104EB93F02AEB105020A8506F292390D99F84C561D17D53045BD02B8A551

Is this bug going to be fixed in the next FortiClient release?

[funkylicious]

hi,

maybe it helps, https://community.fortinet.com/t5/FortiGate/Technical-Tip-Understanding-signature-verification-faile... 

[strongX509]

Today I installed the latest FortiClient Release v7.4.5 but unfortunately the IKEv2 Digital Signature bug persists as the following IKE_AUTH request parsing of the AUTH payload
for an ecdsa-with-sha256 Digital Signature shows:

2F                Next Payload: 47 - CP
00                C/Reserved
0058              Length: 88 Octets = 8 + 16 + 64 Octets (2*256 Bits)
0E                Auth Method: 14 - Digital Signature (RFC 7427)
000000            Reserved
0F                ASN.1 Length: 15 Octets
30 0D             ASN.1 Sequence: 13 Octets
   06 09          ASN.1 OID: 9 Octets
2A 86 48 86 F7 0D 01 01 0C : sha384WithRSAEncryption (wrong)
   05 00          ASN.1 NULL
9A99C92FEBE71ACC06C5CA110584EE60BB8F005400664C6C604AFB1DE2AF9B60
242860FF498AFEEED6BD6B044913BC11F1E761A1BB93B8D1A27BF93D4809F6EE

The correct ASN.1 Algorithm Identifier encoding according to RFC 7427 is:
0C                ASN.1 Length: 12 Octets
30 0A             ASN.1 Sequence: 10 Octets
   06 08          ASN.1 OID: 8 Octets
2A 86 48 CE 3D 04 03 02 : ecdsa-with-sha256

A slightly different different error occurs with an 3072 bit RSA Digital Signature.
The Algorithm Identifier could now be correct but the signature verification still fails:

2F                Next Payload: 47 - CP
00                C/Reserved
0198              Length: 408 Octets = 8 + 16 + 384 Octets (3072 Bits)
0E                Auth Method: 14 - Digital Signature (RFC 7427)
000000            Reserved
0F                ASN.1 Length: 15 Octets
30 0D             ASN.1 Sequence: 13 Octets
   06 09          ASN.1 OID: 9 Octets
2A 86 48 86 F7 0D 01 01 0C : sha384WithRSAEncryption
   05 00          ASN.1 NULL (no parameters)
3498BF31CDB5D249FCEBDAF2FF2312987EE2030D4B8E4EE9452AF51BC6299906
90FFD4D998E0DD6B531C5EE780263B2670C363D3996F84E2C71CEDE137428C23
A3D87A699527C4E47A1BE891DF402308E5BC2A54A36E6FDD725A5485E33BBFA7
45F631E700B7AB9C75257A66F01586D45525E42BB1FBCCE8D9EFEBD9F87A975D
4F9DDC680423554872238D42712B8E9F3E7245ED31BD3112FCB7E270DF72F211
B6AC38B2E04FBEF915498A6F4789FDC0AE68EC3CD56285BA48604F0B339B97F7
CEFDF549A9410293EE4331200BCE3F9BA9367C99FB3B8C6D136E707FCEC2AFB3
3F9FD5220C90DEB441D0BAAC0B4F8778675F097482BE408750230B3FCB2E3F0C
FCA129FDF8D664A0346D194AA4184483DED441F0ED50D9F1FB09A22AB0896611
7BBDAE5EBDF0AC895632E011F3BD363480F927C1209D0A18D17416DCB87DA411
4C88DBCA151A8573975030CF3EC697EC92ED49DA15897EB546F38C4AA2E7CF80
F55A2236B5F26C8A8AABACD836E966DE013FA1D723803CCB207C1F90F036E018

It might be that instead of the announced sha384WithRSAEncryption a different

RSA signature algorithm was used.

So there is still quite some bug fixing to be done:

Depending on the actual signature scheme selected by the FortiClient for a

given private key type, the correct ASN.1 Algorithm Identifier according to

RFC 7427 must be implemented.

[strongX509]

I analyzed the failed 3072 bit RSA signature in the last post by decrypting it with

the client certificate's public key:

3498BF31CDB5D249FCEBDAF2FF2312987EE2030D4B8E4EE9452AF51BC6299906
90FFD4D998E0DD6B531C5EE780263B2670C363D3996F84E2C71CEDE137428C23
A3D87A699527C4E47A1BE891DF402308E5BC2A54A36E6FDD725A5485E33BBFA7
45F631E700B7AB9C75257A66F01586D45525E42BB1FBCCE8D9EFEBD9F87A975D
4F9DDC680423554872238D42712B8E9F3E7245ED31BD3112FCB7E270DF72F211
B6AC38B2E04FBEF915498A6F4789FDC0AE68EC3CD56285BA48604F0B339B97F7
CEFDF549A9410293EE4331200BCE3F9BA9367C99FB3B8C6D136E707FCEC2AFB3
3F9FD5220C90DEB441D0BAAC0B4F8778675F097482BE408750230B3FCB2E3F0C
FCA129FDF8D664A0346D194AA4184483DED441F0ED50D9F1FB09A22AB0896611
7BBDAE5EBDF0AC895632E011F3BD363480F927C1209D0A18D17416DCB87DA411
4C88DBCA151A8573975030CF3EC697EC92ED49DA15897EB546F38C4AA2E7CF80
F55A2236B5F26C8A8AABACD836E966DE013FA1D723803CCB207C1F90F036E018

The actual data signed with the FortiClients's private key has the following

plaintext PKCS#1.5 padded form:

00 01 ff ff ff ff ff ff-ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff-ff ff ff ff ff ff ff ff

...

ff ff ff ff ff ff ff ff-ff ff ff ff 00
30 21                   ASN.1 Sequence: 33 Octets
   30 09                ASN.1 AlgorithmIdentifier: 9 Octets
      06 05             ASN.1 OID: 5 Octets
         2b 0e 03 02 1a : sha-1
      05 00             ASN.1 NULL (no parameters)
   04 14               ASN.1 OctetString: 20 Octets

3f 41 14 57 a4 e7 8f 0d 85 7b 4b fd 99 05 1c a7 6d db 2d 23

Thus the actual signature computed by the FortiClient was sha1WithRSAEncryption not  sha384WithRSAEncryption as announced in the IKEv2 Digital Signature payload.
Therefore it is clear that the signature verification on the FortiGate side is bound to fail.