[strongSwan] IKEv2 rekey failure with IOS8

[Tobias Brunner]

> I don't understand why IKE and ESP can't be the same.

They generally can, if the peer agrees and sends an appropriate
proposal, which isn't the case here.  However, in your case you don't
need sha256 in the ESP proposal as you use AES-GCM (strongSwan removes
integrity algorithms automatically in AEAD proposals, though).  In the
IKE proposal that integrity algorithm is used to specify the PRF used to
generate key material, but more correctly you'd define that as prfsha256
in the IKE proposal instead.

You saw that the proposal by the iOS 8 client does not contain a DH
group.  This is actually not RFC 7296 (IKEv2) compliant.  Since the
rekeying is initiated by the server the client should decline the
proposal and return NO_PROPOSAL_CHOSEN if it wasn't configured for PFS
(i.e. if its own proposal does not include a DH group).  Instead it just
leaves out the DH group in the returned proposal and does not send a KE
payload.  This is only valid if the original proposal contained NONE(0)
in the DH transform substructure, which strongSwan doesn't include in
the proposals it sends.  So this looks like a bug in iOS 8 to me.

> I know the child uses the IKE key exchange until rekey, but does this mean IKE
> can have DH params on IOS8, but ESP can't use them, and therefore no
> PFS is available?

The iOS 8 IKEv2 client can handle a single proposal for ESP, which can
be changed with the ChildSecurityAssociationParameters in the profile.
You obviously already did specify that to use AES-GCM.  If the proposal
in your profile actually includes a DiffieHellmanGroup key with the
value set to 16 then this looks like another bug.

Does the same happen if the client initiates the rekeying?  Does the
behavior change if you don't use AES-GCM?

Regards,
Tobias