Re: Crypto algorithms for IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

> Come to think of it, I don't think we ever resolved the issue of what to
do
> when the initiator of a CREATE_CHILD_SA exchange doesn't propose PFS but
the
> responder requires it. This could be accomplished with a
> NOTIFY_PFS_REQUIRED_ALWAYS or NOTIFY_PFS_REQUIRED_NEXT_SA message.
>
My reading of the current specification is that if the initiator doesn't
propose PFS but the responder requires it, the proposal will be rejected
with a NO_PROPOSAL_CHOSEN notification, just as would any other time there
is no overlap between what the initiator proposes and what the responder is
prepared to accept.

If the initiator supports more than he proposed, he can try again with a
different proposal. After the initial exchange, doing so does not have a
"negotiate-down" vulnerability.

> Not that we could really change it now, but did anyone consider the idea
of
> acheiving PFS simply by applying a one-way hash to SKEYSEED_D, either
> periodically or after every CREATE_CHILD_SA exchange? Sure, there are
race
> conditions, but I think they are easily fixed.

I believe this would be a great enhancement to the protocol, albeit a
little late for this time around. I proposed it informally a while back,
but it was shot down by some of the crypto people. I still don't understand
why, but decided not to rock the boat. It is likely I miscommunicated the
proposal.

      --Charlie