[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE drfat - draft-ietf-ipsec-isakmp-oakley-08.txt
Pyda,
> > One approach I could think of to fix this problem was to
> > disassociate authentication mechanism from key derivation
> > (SKEYID). I am not a cryptographer and I do not understand
> > why SKEYID is evaluated differently based on authentication
> > schemes used. I would suggest making derivation of SKEYID
> > uniform for all authentications, like
> > SKEYID = prf (hash(Ni_b | Nr_b), g^xy)
As Dan outlined, there are STRONG cryptographic reasons to run the
protocol and key derivation as it is. There are too much potholes a
"hobby cryptographer" can fall in by changing only the smallest
detail here for whatever reason. I believe there was an extensive
review on IKE by *really good* cryptographers and one should trust in
their knowledge to do IKE the way it is
(one of the reasons to separate auth. from key derivation is to keep
the long-living authentication key "away" from the short-living
encrytion keys, i.e. to let *no* information about the auth. key
"leak" into the enc. keys. For SIG-Mode this is not possible, so it
might be a bit weaker.)
The only way to apply your need would be to change the MANDATORY IKE
features, but I really can't see a reason for this, especially not
for the "compatibility mode (PSK)". Finally the market will decide
what's mandatory - I trust in the market: this will be
certificate-based mechanisms ;-)
Kai
# Kai Martius #
# Dpt. of Medical CS and Biometrics / Dresden University of Technology #
# PGP Fingerprint: to be compared after download of my key #
# Key and more info see my Homepage #
# http://www.imib.med.tu-dresden.de/imib/personal/kai.html #
References: