[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: change in isakmp/oakley



Dan,

>   But I haven't really seen a groundswell of support or opposition and 
> that's a bit disheartening. Can somebody out there in ipsec-land who 
> gives a damn either way speak up?

Perhaps this thread should also visit the isakmp-oakley list?

>   I'm willing to change the draft if enough people say it's important. 
> I'm also willing to leave it alone and let people negotiate ROT-13 for 
> encryption and the futuristic-key-truncating MAC for authentication 
> (using private use attributes of course-- I wouldn't include them in 
> the draft) if they're that stupid.

For what it may be worth, I'd like to see the draft change, either
now or later (see below).

Does anyone have code that uses something other than HMAC as the prf?
If not, maybe a procedurally useful compromise would be to specify
HMAC as a SHOULD for the prf in this version of ISAKMP/Oakley, and
in some later v2 add in the machinery to mangle key material into the
right sizes for other possible prfs. Among other things, this assumes
that (a) keying HMAC with constructions like Ni|Nr is secure [which I
think is true] and (b) recommending a particular prf won't muck up
backwards compatibility for later versions, even if HMAC becomes broken
for this purpose. [I'm not at all sure the latter is a good 
assumption.] This wouldn't change any code for people already using 
HMAC exclusively as their prf, and punts on the key-resizing issue by
disallowing prfs with key size restrictions.

Comments?

-Lewis


References: