Hi Scott,
> > 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.
[...]
> > 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)
>
> That's what we did in our original proposal (actually, it was a function of
> the PPK itself). The problems with
> that were:
>
> - If we made it a nondeterministic function (that is, include a randomizer),
> then the server had to do a linear
> scan over all their known PPKs to find the matching one.
>
> - If we made it a deterministic function, then someone listening in can
> trivially determine when we're reusing
> the same PPK
>
> (There's also a minor issue of "which hash function to use"; we haven't
> negotiated any at this time).
>
> A linear scan over possibly 10,000 PPKs was considered unacceptable. One of
> our proposals even allowed the
> server to specify the trade-off between the above two; that was considered
> too complex.
>
> I'm not thrilled with Tero's answer of "lets be careful about the order we
> upgrade things in complex
> networks", but I don't know how to better solve it without adding lots of
> complexity to the protocol, potential
> anonymity leaks or requiring significant computation on the server side.
One (relatively) simple solution would be the following.
If initiator is configured with PPK, but at the same time its policy marks
using PPK as optional,
then the initiator can send two authenticators - one using SK_pi' and the other
using SK_pi
(where SK_pi = prf(PPK, SK_pi')). The one, computed using SK_pi (where PPK is
involved) is placed in
AUTH payload, and the other, computed using SK_pi' (without PPK) is placed in
a new optional status notification NO_PPK_AUTH.
Initiator Responder
------------------------------------------------------------------
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr,
N(PPK_IDENTITY)(PPK_id),
[N(NO_PPK_AUTH)(auth_data)] } --->
When responder receives this message and cannot find the corresponding PPK
based on PPK_id and is configured
to allow PPK-less SA, it can still authenticate initiator by using the content
of NO_PPK_AUTH.
In this case the Responder replies with the IKE_AUTH response lacking
PPK_IDENTITY to let the initiator
know that AUTH payload is computed as per RFC7296 (using SK_pr', i.e. without
using PPK).
<--- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr}
If the responder has the corresponding PPK, then it computes its AUTH payload
using
SK_pr and includes PPK_IDENTITY notification:
<--- HDR, SK {IDr, [CERT,]
AUTH, SAr2, TSi, TSr,
N(PPK_IDENTITY)(PPK_id)}
This solution allows peers to communicate in different settings and to enforce
their own policy.
For instance, if the initiator is configured to always use PPK, it won't
include
NO_PPK_AUTH at all. If responder is configured to always use PPK, it will just
ignore
NO_PPK_AUTH and return AUTHENTICATION_FAILED in case the proper PPK is not
found.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
