Hi Paul I’m a bit late to the party, but thought I’d chip in if it helps..
With regards to ‘If the responder has some connections that require a PPK and
some connections that require NO PPK, then it has to flip a coin on whether or
not to send
the PPK_SUPPORT notify and if it guessed wrong’
If you follow the logic below (I sent the following to Scott back in the day)
with the GW (or responder) being configured with the PPK’s for the initiators
first, then the initiators being configured and ONLY sending the PPK supported
when it has a key for the peer you should be ok.
cheers
I would like to propose the following;
- Step 0 is "never use PPKs" (this is the existing IKE standard)
- Logic 1 is “if we are initiator only advertise PPK notify if we have a PPK
for the peer”
- Step 1 is "if we're the initiator, then use PPKs if the responder signaled
support for it"
- Step 2 is "insist on PPKs if the peer support it (in both the initiator
and the responder roles)"
So for a remote access VPN GW, you would configure the GW first and then each
client. The GW will only respond with the PPK notify if the client had included
the PPK notify. Once the client has the PPK it will include the PPK notify and
pass authentication.
Likewise for Hub and Spoke, the same principle.
The issue I would foresee is something like DMVPN or a partial/full mesh, but
my logic mitigates any issues.. the Hub has the PPK and Spoke 1 has the PPK..
The Spoke1 – Hub SA is protected by the PPK. If Spoke2 did not have a PPK and
connected to the Hub, the Spoke2 – Hub is not PPK protected, then Spoke1
connected to Spoke2, because of the logic (“if we are initiator only advertise
PPK notify if we have a PPK for the peer”) Spoke1 would not advertise the PPK
notify and hence we get over this limitation.
Now where this falls down is if there’s a shared key, so in the example above
is all spokes used a shared key and one of the spokes didn’t have it – then the
logic would fail.
On 17/08/2017, 03:16, "IPsec on behalf of Paul Wouters" <[email protected]
on behalf of [email protected]> wrote:
Hi,
Vukasin Karadzic is working on implementing draft-fluhrer-qr-ikev2
for libreswan and stumbled upon a problem. The relevant text:
When the initiator receives this reply, it checks whether the
responder included the PPK_SUPPORT notify. If the responder did not,
then the initiator MUST either proceed with the standard IKE
negotiation (without using a PPK), or abort the exchange (for
example, because the initiator has the PPK marked as mandatory). If
the responder did include the PPK_SUPPORT notify, then it selects a
PPK, along with its identifier PPK_id. Then, it computes this
modification of the standard IKE key derivation:
A responder answering an IKE_INIT containing PPK_SUPPORT needs to
reply without knowing for which connection this IKE_INIT will be.
The responder has not yet received the initiator's ID. If the responder
has some connections that require a PPK and some connections that
require NO PPK, then it has to flip a coin on whether or not to send
the PPK_SUPPORT notify and if it guessed wrong, the AUTH payload on
the initiator will be wrong. Sending the notify commits to using a PPK
because the initiator uses it as input to the AUTH payload.
So this table from the RFC is incomplete:
This table summarizes the above logic by the responder
Received PPK_SUPPORT Have PPK PPK Mandatory Action
------------------------------------------------------------------
No No * Standard IKE protocol
No Yes No Standard IKE protocol
No Yes Yes Abort negotiation
Yes No * Standard IKE protocol
Yes Yes * Include PPK_SUPPORT
Basically, we are in the case where "Have PPK" is not yet known.
One way of solving this could be to allow PPK_SUPPORT to have some
notify data, which could for instance be a hash of the connection/group
name used by the responder. Another option is to use the PPK as one
of the inputs to some hash algorithm as PPK_SUPPORT data, so the
responder can go through its list of PPKs to match it back to a
connection/group. But we would need to be sure that this does not
open up the PPK to attacks (classic and quantum)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
