[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The world according to MCR
On Tue, 16 Mar 1999 10:22:52 CST Michael Richardson wrote
> >>>>> "Dan" == Dan Harkins <email@example.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.
I never said that sending the vendor ID was dependant on receiving
anything, nor did I say that the mere sending of it implied acceptance
on the part of the recipient. The responder could choose not to send
his vendor ID payload regardless of what the initiator did and regardless
of whether he recognized the initiator's vendor ID. Also, the implication
in this ad hoc scheme was that the vendor ID payload was an offer to do
something different and non-RFC2409. Sending it would not mean acceptance
to do this, but both sending it and receiving it would.
This pseudo-negotiation use of the vendor ID payload may not be in keeping
with the spirit or the intention of it but that's an emotional argument
I'd rather not have. It is not prohibited by RFC2408 and it would work.
The responder could be configured to only do aggressive mode with a
client that it recognized and only do it in this manner to limit
exposure to DOS attacks. This scheme may not be as secure as straight
aggressive mode but it's a perfectly legal use of the 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.
There was no private numberspace involved in the scheme I described
so I don't know what this refers to.