[Not wearing any hats]
Scott Fluhrer (sfluhrer) writes:
> - Move the notifies to the prior messages (that is, in the clear).
> If we do this, then by the time we derive keys, we know whether
> we're using a PPK (even if the responder doesn't know which one it
> is until it hears the initiator's id). This would mean that anyone
> could tell whether the two sides are using a PPK
Currently PPK_NOTIFY is empty notification so moving that to the the
IKE_SA_INIT and changing its name to PPK_SUPPORTED is fine.
Sending the actual PPK identity is better done on the IKE_AUTH where
it is protected by the Diffie-Hellman, meaning attacker needs to do
active attack to learn it.
So I think protocol should be something like
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni,
N(PPK_SUPPORTED) -->
<-- HDR, SAr1, KEr, Nr,
N(PPK_SUPPORTED), [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
N(PPK_IDENTITY, <ppk_id>),
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr}
Where the N(PPK_SUPPORTED) just tells that both ends support PPK, and
they have at least one PPK installed. This means that incremental
installation needs to be done so that all possible PPKs are always
installed for each identity to the machine once, i.e., it either knows
PPKs for all IDs and sends N(PPK_SUPPORTED) or it does not send
N(PPK_SUPPORTED) at all.
I.e., you cannot install just PPKs for half of the users and enable
N(PPK_SUPPORTED). PPK will be enabled only and only if both ends send
N(PPK_SUPPORTED) during the IKE_SA_INIT.
Then during the IKE_AUTH the initiator picks PPK to use and sends the
<ppk_id> associated with the PPK in the N(PPK_IDENTITY, ...) notify
and uses the PPK to generate the AUTH. If it only has one PPK meaning
the <ppk_id> does not have any meaning it will send it as empty. If it
does not send PPK_IDENTITY at all, that means it is not using PPK even
when it was enabled (this can be used for example to test whether the
authentication problem is in the shared secret being wrong or in the
case where the PPK is wrong).
If N(PPK_IDENTITY, <ppk_id>) was sent by the initiator then responder
will find the matching for the user specified in the IDi and will use
that when calculating AUTH. The ppk_id is opaque binary string and
will be be interpreted at all by the IKE, but the PPK management
module might provide internal format for it.
For example if the PPKs are taken from the 1GB one-time-pad file
shared by the peers (one file per user), then the ppk_id could simply
be 32-bit offset to the file, and the external PPK management module
would keep track which of the offsets are used and which are not.
If the ppk_id is not known by the responder, then it will return
N(AUTHENTICATION_FAILED) error and log the error to the local log
file.
If EAP is used, then exchange is bit different:
Initiator Responder
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni,
N(PPK_SUPPORTED) -->
<-- HDR, SAr1, KEr, Nr,
N(PPK_SUPPORTED), [CERTREQ]
HDR, SK {IDi, [CERTREQ,]
[IDr,] SAi2,
N(PPK_IDENTITY, <ppk_id>),
TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH, EAP}
HDR, SK {EAP} -->
<-- HDR, SK {EAP (success)}
HDR, SK {AUTH} -->
<-- HDR, SK {AUTH, SAr2, TSi, TSr}
I.e., the PPK_IDENTITY is still sent inside the first IKE_AUTH, but of
course in this case the actual PPK is not used by the initiator yet.
The responder will then reply with AUTH payload using the PPK, and the
final exchange uses the PPK again in both ends.
With EAP only authentication (RFC5998) the exchange is about same,
except now we do not have "[CERT,] AUTH" in the responders first
IKE_AUTH message, and the PPK is only used in the final IKE_AUTH
exchange when calculating AUTH payloads.
The NULL authentication (RFC7619) is logically incompatible with this
(it being opportunistic and this requiring configuration), so I think
we can say this will not be used with it. Or we can just say that can
be used, and SK_pi are used as specified here and in the RFC7619...
> - For the initiator's AUTH payload, use SK_pi' always. However, I
> suspect this would partially mess up the reason we're strirring it
> into SK_pi in the first place.
That would be one option too. I.e., only modify SK_pr. I think it
actually would be enough, as we do trust the other end to do correct
things, and this would be enough to know whether peers share the same
PPK. On the other hand we will end up annoying case where the
initiator will know that PPK is wrong after the IKE_SA has already
been properly installed on the responder, thus initiator needs to
signal this with separate INFORMATIONAL exchange to the responder, and
thne delete IKE SA. I think the option I explained above is better.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
