[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deprecation of AH header from the IPSEC tool kit
At 16:22 14/06/00 , Michael Richardson wrote:
> The point that Steve Bellovin keeps making, and which he has written about, is that AH does not provide much more in the way of
>authentication that ESP does not (at least for IPv4).
There are differences in semantics between AH and ESP:
- AH permits hop-by-hop IP-layer option authentication.
- AH also permits end-to-end IP-layer option authentication.
- ESP does not protect IP-layer options at all. Tunneling
the options is not relevant since the point of authenticating
an IP-layer option is to authenticate the outer header option
that will be examined during transit from source to destination.
>The outer headers
>are all either irrelevant, or can be derived from the SPD, so
>you don't have to trust them.
A counter-example is the Source Routing header, when can
be authenticated hop-by-hop with AH and cannot be authenticated
at all by ESP. Source routing attacks can be interesting and
subtle.
Another counter-example, which is supported in shipping
product by major workstation vendors (e.g. Sun, HP), though it
is not on the IETF standards-track at present are the various
IP Security Options.[1]
> I believe that there are other things that AH provides (like the
>guarantee that the contents are not encrypted and therefore can be audited),
>and things that will be defined in IPv6-extension land that will make AH
>a useful thing to keep in the spec, just not MUST it.
I mostly agree, but would tweak this slightly.
The real issue here is that VPN Product vendors currently dominate
the IPsec WG. VPN vendors don't want to support AH and aren't building
IPv6 products, yet they want to claim to be fully "IPsec Compliant"
(which is marketing speak; I have no clue what it really means).
In short, some of the impetus behind this proposal is to solve a
marketing problem -- most of the remainder is largely smoke-screen.
So the thing to do is to edit the must-implement text clauses such
that IPv4 VPN products (i.e. not implementing IPv6) do not need
to implement AH and can claim to be fully compliant for marketing
purposes.
Then, AH could be implemented when/where it is sensible (e.g. in all
IPv6 boxen ,so that IPv6 options can be protected hop-by-hop;
in routers where vendors continue to run into as-implemented
export controls that prevent easy licencing of authentication-only
ESP [2]). AH should continue to be mandatory in all IPv6
implementations, so that security-sensitive IPv6 options can be
protected end-to-end and hop-by-hop. The lack of ability to
authenticate IPv4 options constrained the IPv4 design --
this should be avoided in IPv6. Even if one doesn't think the
current IPv6 options are security relevant, one ought not constrain
the protocol such that such options are forbidden for all time.
It seems like a bug that the IPng WG isn't involved in this discussion.
I only caught this myself because sundry routing protocol WGs were
copied.
Thanks to Michael for writing one of the more clear and crisp
notes on this thread.
Ran
rja@inet.org
[1] Unfortunately, the as-deployed IP Security Option is also processed
by trusted devices that don't (and won't in their lifetime) support
AH, so one can't just cease transmitting the IP Security Option and
rely on sensitivity labels within the Security Association. AH can
and is used to provide "firewall-like" checking externally before
passing the IPSO/CIPSO label to the trusted device. I don't claim
this is a good design, but it is deployed today and won't be going
away for at least several years.
[2] I continue to hear about the US making highly inconsistent
decisions about authentication-only ESP. I have heard recent
reports of licence approval and also recent reports of licence
rejection. Router/switch vendors need to be able to use AH
for routing protocol authentication because there are NEVER any
export or import licencing issues with AH in ANY country.
Follow-Ups:
References: