Hi Scott,
> I started editting the draft to incorporate this change, and I ran into a
> conflict with another
part of the
> protocol: incremental rollout. I'd like some quick advice about how to deal
> with the conflict.
>
> Here's the feature it's in conflict with: in order to support 'brown-field'
> deployments (that is,
an existing IKE
> infrastructure that people will be deploying this to), the current draft
> specifically allows an
IKE
> implementation to be in a state where it works both with peers that implement
> this, and peers that
do not;
> the idea being that the administrator would first upgrade all their nodes to
> work in this special
> intermediate mode; and once they've done they, they then upgrade their nodes
> to 'do QR-only' mode.
> This is twice as much work for the administrators; however at no point of
> time is any network
blockage (as
> two peers will always be able to negotiate).
>
> Currently, whether we're using a PPK is negotiated by the N(PPK_NOTIFY)
> notifies that is sent in
the first
> encrypted message; the responder learns whether or not the initiator supports
> this draft (and has
a PPK)
> by whether the notify is there. However, that same encrypted message
> includes the AUTH payload;
which
> is generated using the SK_pi. And, if the initiator isn't sure if we're
> using the PPK, it
wouldn't know
> whether to use SK_pi' or prf(PPK, SK_pi')
>
> Some obvious ways to address this:
>
> - 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
I prefer this way. In more detail:
IKE_SA_INIT:
Initiator:
SA, KE, Ni,
[N(PPK_SUPPORTED),]
[V+][N+] -->
PPK_SUPPORTED notification indicated that the Initiator supports PPK and is
willing to use it.
This notification contains no data.
Responder:
<-- SA, KE, Nr,
[CERTREQ+,]
[N(PPK_SUPPORTED),]
[V+][N+]
If the Responder supports PPK it will return PPK_SUPPORTED back in the
IKE_SA_INIT reply.
Otherwise the Responder ignores this notification and PPK is not used in the
following exchange.
Assuming both sides support PPK:
IKE_SA_AUTH:
Initiator:
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2,
TS, TSr, N(USE_PPK)} --->
USE_PPK notification helps the Responder to select the right PPK and to ensure
that
the Initiator really possess the correct PPK value. Its data is computed as
prf(SK_pi, Ni | Nr),
where SK_pi is as in Tero's proposal (SK_pi = prf(PPK, SK_pi')). Having this
notification included
will solve two issues:
- first, the Responder can verify that the Initiator does have the correct PPK
(i.e. PPK
misconfiguration
errors become clear and can be distinguished from certificates configuration
errors). Moreover,
the Responder can verify that PPK is correct before starting computational
expensive
signature verification.
- if PPK selection is ambiguous, this notification can help select the right
PPK.
This can happen in situation of PPK rollover, when old PPK is being changed
with a new one,
and since this cannot happen overnight, there may be some period of time when
peer's
account is associated with two PPKs (security officer first adds a new PPK
to the server,
then replaces an old PPK with the new one on the client and finally removes
an old PPK from the
server).
Responder:
<--- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr, N(USE_PPK)}
USE_PPK notification data is computed as prf(SK_pr, Ni | Nr), where SK_pr is as
in Tero's proposal
(SK_pr = prf(PPK, SK_pr')).
AUTH payload is computed as in Tero's proposal. If a host detects that it has
no PPK that matches
the peer's
USE_PPK data, it can return either AUTHENTICATION_FAILED (this will leak no
information to a passive
observer of which part of authentication failed) or a new error notification
WRONG_PPK (this would
allow
the peer to make some conscious actions to resolve the situation), or both.
> - Drop this intermediate mode; that is, make it determanistic to whether
> we're uisng the PPK
(based on the
> peer identity). This would make roll-out more challenging, but it would
> simplify the
implementations.
This will make incremental introducing of PPK next to impossible.
> - 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.
Agree that it would mess up the initial reason.
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
