原文链接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_idFGTxxx log_id0101023003 typeevent subtypeipsec prierror loc_ipaa.bb.cc.dd loc_port500 rem_ipee.ff.gg.hh rem_port500 out_if"wan1" vpn_tunnel"branchOffice" COOKIEsasd2345sdf4sdf345 actionnegotiate statusnegotiate_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 (dialers IP) cannot be used as a distinguisher (any source IP is allowed for dialup phase1)
- the destination IP (FGTs IP) cannot be used as a distinguisher (we have assumed that all dialup phase1 were bound to the same FGT IP)
- there isnt 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 limitationThe 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 initiators 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 doesnt 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 dont 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.