Subject: Re: Crypto algorithms for IKEv2

From: [email-masked]
Date: Thu, 1 May 2003 18:55:40 -0400

> 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

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Mon, 12 May 2003 13:41:10 -0400

>is no overlap between what the initiator proposes and what the responder is

I guess the danger I was thinking of is that some people have been talking 
about PFS as a run-time parameter rather than a configuration parameter. 
I.e. you have a PFS interval for the original phase 1 key. Once that 
interval has elapsed, you delete SKEYSEED_D and require PFS for every 
subsequent CREATE_CHILD_SA (possibly reusing the exponent).

The trouble is that when you receive a NO_PROPOSAL_CHOSEN message, this 
normally represents a configuration error (where the administrator has to 
check that both sides are using the same ciphersuites). Now we have a case 
where the NO_PROPOSAL_CHOSEN message could also occur for an already 
functioning SA.

As I pointed out earlier, the UI suites in 
draft-hoffman-ipsec-algorithms-00.txt make no mention of PFS. So my guess is 
that half the implementations will have it on by default and half will have 
it off by default. This means that we either need a PFS on/off checkbox in 
the GUI (which defeats the purpose of a single configuration knob via UI 
suites) or we have to implement a routine to retry with PFS any time you 
receive a NO_PROPOSAL_CHOSEN message.

I suspect that most people will choose the former. (God forbid that anyone 
actually attempts the strategy where you rekey without PFS for the first N 
minutes and then with PFS for the remainder of the SA lifetime.)

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 14 May 2003 16:42:23 -0700

Greetings again. Based on the feedback from the WG, I have revised my 
crypto algorithms for IKEv2 draft. The new version is available at 
<ftp://ftp.ietf.org/internet-drafts/draft-hoffman-ipsec-algorithms-01.txt>.

The changes are:

2.1: Removed ENCR_DES_IV32 and ENCR_RC4, which didn't have references,
and renumbered the ones below them. Also added draft names for AES
ciphers.

2.2: Added a reference for PRF_AES128_CBC, but am not sure this is
correct or sufficient.

2.3: Removed DES_MAC because there was no reference for it. Renumbered.
Added reference for AUTH_AES_XCBC_96.

3.1 and 3.2: Added requirements for perfect forward secrecy.

3.2: Updated the IDs because of the renumbering in sections 2.1 and 2.3.

Please review the document and post any comments to the WG mailing 
list. It would be good to get this part of the IKEv2 work finished 
soon.

--Paul Hoffman, Director
--VPN Consortium