[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in isakmp/oakley
Hilarie,
> Do the spec's allow the prf's to do key truncation? What do they do
> with keys longer than one block? My own opinion is that truncation
> is a severe bug in any case, and that it should be fixed. This makes
> their use for session key derivation moot.
The spec doesn't address the particulars of each prf but instead defines
two default prfs (which don't do key truncation) and allows for growth by
reserving some part of its magic number space for to-be-defined prfs.
It would seem to me that any key'd prf (or key'd _anything_) which does
key truncation is broken and shouldn't be used in ISAKMP/Oakley, but I
guess the point being made is that it's possible to define such a broken
function and negotiate it in ISAKMP/Oakley. Let me also note that its
possible to define a ROT-13 encryption algorithm and negotiate it too.
I don't think I'd accept either in an offer but, I guess, that's not the
point.
Is the (non)mixing of Ni and Nr in encryption mode authentication broken
or does it just reenforce the brokenness of certain (as yet unnamed) prfs?
Dan.
References: