[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: comments on Oakley test items
> I could also argue that this is not a discrepancy with the base ISAKMP
>spec. The M-ID and SPI would still identify the correct state as dictated
>by section 2.4. It's just that the M-ID and SPI would be in the body of
>the notify message as the ISAKMP header and SA payload to which the notify
>refers. The ISAKMP header of the Informational Exchange would be unique
>to the Informational Exchange.
Hi Dan,
I can't find where it says to include the M-ID/SPI in the body of the
notify message, nor where it says to include the ISAKMP header. ISAKMP
states the data portion of a notify message is DOI specific, DOIv3
doesn't specify any thing special, so I would assume nothing.
I agree that ISAKMP-Cookies, Protocol-ID, and SPI (so the data available
during notify parse) is enough to find a bad Quick Mode BUT if and only
if each side gets past the SA parse since you need to send back the
other sides SPIs.
There are a few cases where I will reject before I get to a deep parse
of the SA payload, bad hash, invalid payload, no SA payload, who knows,
etc...
Can we have the DOI define the notification data to include the M-ID.
Its in the clear (so it wont get screwed by IV/crypto mix ups) and
relates to the whole Quick Mode (where as SPIs - multiple SAs per quick
mode, AND and ORing).
Sorry, don't want to harp on this, but specifying the M-ID leaves
nothing to be desired and covers 100% of the error conditions, where as
the current solution relies on a successful parse of the SA payload
which seems rather optimistic.
Bye.
----
Greg Carter, Entrust Technologies
greg.carter@entrust.com
Get FREE FIPS-140-1 Validated Crypto for the desktop
http://www.entrust.com/solo.htm
>