[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The world according to MCR
>>>>> "Dan" == Dan Harkins <dharkins@network-alchemy.com> writes:
Dan> Why not? The authenticating hash payloads and SKEYID
Dan> generation could be changed to fix this "problem". The
Dan> Initiator sends the vendor ID payload in the first
Dan> message. If the Responder recognizes this (and assuming
Dan> implicit acceptance of this capability) he'll respond with
Dan> his vendor ID payload with the rest of his message, the
First, sending of a vendor ID payload is not dependant upon
receiving anything, and does not imply acceptance of the other's
vendor ID payload.
Second, the intention was that the vendor ID payload had to be
*received* before one could *send* using the private number space.
Kivinen had a different idea, and I'd like to get three or four
brains together and has out some better text.
] At IETF44 in Minneapolis, MN | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Follow-Ups:
References: