A colleague pointed-out that including the old SK_d itself in the REAUTH_SA notification is a bad idea. A better approach would be to incorporate it into the new AUTH payload.
> RFC 4301 section 4.4.3.4 "How the PAD is Used" says: > Child SAs are created based on the exchange of traffic selector > payloads, either at the end of the initial IKE exchange or in > subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now > authenticated) IKE peer is used to constrain creation of child SAs; > specifically, the PAD entry specifies how the SPD is searched using a > traffic selector proposal from a peer. There are two choices: either > the IKE ID asserted by the peer is used to find an SPD entry via its > symbolic name, or peer IP addresses asserted in traffic selector > payloads are used for SPD lookups based on the remote IP address > field portion of an SPD entry. It is necessary to impose these > constraints on creation of child SAs to prevent an authenticated peer > from spoofing IDs associated with other, legitimate peers. > > Moving the child SAs for a reauthenticated IKE SA could circumvent > the checking that allows the PAD to constrain the creation of a > child SA to a particular IKE peer. So, I agree that the initiator > of a reauth must prove that he is the same entity with which the > original IKE SA was established. Having the reauth initiator supply > the old SK_d as Yoav suggested would accomplish that. The old SK_d > can be appended to the SPIs in the REAUTH_SA > notification.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
