Re: IKE V2 Open Issues

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

> 
> 1) Hugo's proposal to change legacy authentication to protect the
> initiator's identity against active attacks.  After looking at the
> discussion, Barbara and I have concluded that the impacts of moving
> around various protocol elements introduces numerous additional
> complexities which will be hard to address at this late date.  Russ
> with his AD hat on set as the bar, "if the changes are the least bit
> onerous, then this should not be done".  We believe these changes meet
> that test.

objection! the above presentation of the complexity incurred by
the changes needed to suport  user's identity privacy (against
active attackers)  is inaccurate and misleading. The required changes are
purely local to the EAP extension of ikev2 and do not touch global
elements in the protocol nor they impact performance or any
other aspect of an application/implementation not running the
EAP extension (for example, if all we do is to move IDi to 5th message).

Why misrepresents the facts when you have a much better reason to 
back your decision? As I wrote in a mesage yesterday, the right decision
is indeed NOT to make these changes since (unfortunately) there were not
enough supporters for them (in spite of these changes being non-onerous).

> 
> 3) Uri's AES PRF proposal.  The cryptographers are arguing amongst
> themselves; we don't want to get involved.  We suggest that the Crypto
> group in the IRTF review it, and if they give us their blessing we can
> standardize it in a separate standalone document.
> 

The only part of the spec that raises any issues with providing a
sufficiently long key to the prf is when using passwords as preshared
keys. I respect the intent of Charlie not to outlaw the use of 
passwords in the protocol (especially that as Paul pointed out an
implementation cannot verify the entropy of a key). Yet, let's not leave
the protocol unspecified (e.g. when using prf's based on block ciphers)
just because we cannot prevent this (bad) use by applications.
The solution is (as I wrote in a note to charlie a few days ago):

(1) require nonces to be long enough (at least half the length of the prf key)
(2) require the preshared key to be of the length of the prf key.

In particular, This is trivial to comply by the sharers (is there such a
word?) of a pre-shared key as this pre-sharing is done off-line. 
In case of a password, the people responsible for this wrong use, should
at least be able to convert the password (either if shorter or longer)  
into a string of the prf-key length (e.g., by hashing). 
Remember, that we are not talking here about legacy systems that have
automated interface constraints. Legacy authentication is given a
beautiful solution (up to user's id privacy of course :) in the EAP
extension of ikev2!

Hugo