Going through this suggestion (and tweaking it a bit):
Pluses:
- It is more flexible; in addition to supporting the fixed PPK's, it would also
allow support for one-use PPKs (as you mention), as well as being easy to
extend to handle Phillip LaFrance's PFS ideas.
- Even for fixed PPK's, it makes it possible to update the PPKs in a bump-less
fashion.
- I believe it can be made a bit more flexible than you make it out; it don't
believe that you actually need to update every node with every PPK at the
start. With this protocol, the initiator decides which PPK to use (and whether
to use a PPK at all; the obvious idea would be 'if the initiator doesn't' send
a PPK_NOTIFY message, no PPK is in use'). With this, the upgrade procedure
becomes:
Step 1: configure the PPKs and the id's on each peer. This will allow
each side to use this protocol if it was the responder, but not insist on it if
it's the initiator
Step 2: for each peer, configure which PPK to use (probably based on
peer identity), and make its use optional. That is, when we're initiating,
we'll now use the PPK; however, if we're the responder, we'll use the PPK if
the initiator asks, but not reject the SA if he doesn't
Step 3: for each peer, make the use of PPK mandatory (and so if we're
the responder, when we get the initiator's identity, we see that the use of PPK
was required; if we didn't get PK_NOTIFY, we'll reject the request)
Again, we don't need to upgrade the entire network at once; we could
incrementally do this by peer-to-peer connection...
Minus:
- It makes roll out possible, but (as above) it's a 3 step affair, rather than
the previous 2 step.
- We also need to specify the format of the ppk_id. This isn't that hard,
however we did want an updated revision Real Soon Now, and this format doesn't
feel like something I want to just slap together....
Also, with the above tweak, I'm not certain what value the PPK_SUPPORTED notify
brings to the table; you had it for the responder to signal to the initiator
that it's been upgraded; the above protocol has the initiator expecting whether
specific responders are upgraded or not. It might make debugging a bit
easier...
Another thing to consider: what if we're the responder, and the initiator uses
a PPK (which we have), but not the PPK we would have used if we're the
initiator. I believe that we want to accept this (even if our PPK is marked as
mandatory); would that lead to any potential problems?
Thoughts???
> -----Original Message-----
> From: Tero Kivinen [mailto:[email protected]]
> Sent: Tuesday, April 04, 2017 8:55 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: [email protected]
> Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing
>
> [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
