[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay attacks
David,
I submitted a design note that described a range of security
facilities that we might offer at the IP layer, in the context of a
MIB for these protocols, before the split into AH and ESP was made.
It included a replay countermeasure facility. It might be appropriate
to revisit that feature and ask whether it has a place in either AH or
ESP.
In reviewing the documents that were eleveated to RFCs, I
observed that sometimes ESP was described as providing only
confidentialtiy, someitmes as confidentiality and integrity, and
sometimes confidentiality and opitonal integrity. ESP is really just
a shell as defined now, with all the "meat" coming in the
algorithm/mode- specific documents that are subordinate to the ESP
definition. One might argue for a defintion of an ESP sub-type that
did provide integrity (and authenticity) so that the definition of AH
could be cleaner, i.e., so that AH always covered the IP header and
ULPs vs. sometimes covering only the ULPs. This integrity sub-type
could provide just the sort of data origin authentication and
connectionless integrity that AH provides, and it could have an option
for anti-replay. In keeping with the overall IPSEC design philosophy,
the option choices would be negotiated during association establishment.
Unfortunately, if we follow this course, then we might have a
DES-CBC sub-type, a DES-CBC with integrity subtype, a triple-DES CBC
w/o integroty subtype, ... I'm afriad that is a natural outgrowth of
the current structuring of ESP and its subtypes. I would rather have
ESP become a non-trivial payload definition that included these
facilities as options, so that the sub-types of ESP really were only
algorithm/mode specific, not algorithm, mode, and other features.
Perhaps this latter approach can be considered as we gain experience
with the current versions of AH and ESP.
Steve
Follow-Ups:
References: