本文主要是介绍IKE~多预共享密钥问题~解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
原文链接：Configuring more than one Main-Mode Pre-Shared Key (PSK) *dialup* IPSec phase1
可能需要梯子来翻过高墙。文章内容如下：
Technical Note :
Configuring more than one Main-Mode Pre-Shared Key (PSK) *dialup* IPSec phase1 on a Fortigate
Description
This article explains a limitation inherent to IKE when trying to configure multiple IPSec phase1 in Pre-Shared Key (PSK) mode.
If you configure more than one *dialup* phase1 in Main Mode PSK on the same FortiGate port (IP), then the same phase1 will always be matched by ALL dialers. The error will show up in the third Main Mode round (authentication) as per the example below :
2009-11-04 16:00:00 device_id=FGTxxx log_id=0101023003 type=event subtype=ipsec pri=error loc_ip=aa.bb.cc.dd loc_port=500 rem_ip=ee.ff.gg.hh rem_port=500 out_if="wan1" vpn_tunnel="branchOffice" cookies=asd2345sdf4sdf345 action=negotiate status=negotiate_error msg="Negotiate SA Error: probable pre-shared secret mismatch"
When multiple *dialup* Main Mode PSK phase1 exist, IKE has no way to know which phase1 must be matched upon receipt of the first main mode packet :
- the source IP (dialer's IP) cannot be used as a distinguisher (any source IP is allowed for dialup phase1)
- the destination IP (FGT's IP) cannot be used as a distinguisher (we have assumed that all dialup phase1 were bound to the same FGT IP)
- there isn't any payload in the first Main Mode packet which would allow to select a specific phase1
Consequently, the first phase1 in IKE internal list is always matched.
This is not a FortiOS limitation
The PSK itself is part of the phase1 root key (SKEYID) calculation.
This root key is then derived into two keys (SKEYID_e, SKEYID_a) which are used for the phase1 encryption and authentication.
Phase1 keys are therefore dependent on the PSK.
When the phase1 initiator sends the MI3 message (fifth Main Mode message) it is protected with its locally calculated SKEYID_e/SKEYID_a. If the phase1 which was chosen by the responder is not the correct one, then SKEYID_e and SKEYID_a on the responder are different from those on the initiator therefore leading to a failure ('probable PSK mismatch' in the 'debug ike') because the responder is unable to decipher the initiator's packet.
Scope
All FortiOS
Solution
To work around this Main Mode PSK limitation for multiple dialup connections :
- use aggressive mode with ID (ID is sent in clear text in the first Aggressive Mode message and can therefore be used by the responder to select the correct phase1)
- use Main Mode with RSASIG
Main Mode RSASIG doesn't suffer this limitation and still offers ID protection :
Upon receipt of the first Main Mode message, the IKE responder picks up the first dialup Main Mode RSASIG phase1 in its list. If it is not the correct phase1, it is not an issue.
When MI3 message will reach the IKE responder, it will be able to authenticate and to decipher it because SKEYID_a/e keys don't depend on the phase1 specification (the root SKEYID is based on payloads that were exchanged between each peer (nonces) and on the Diffie-Hellman private shared key that was locally computed by each peer).
Once the MI3 message is decrypted, the IKE responder finally knows the ID of the initiator (which by default is the DN of the initiator certificate) and can therefore "fallback" to the correct phase1 if needed.
这篇关于IKE~多预共享密钥问题~解决方案的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
