[148076] in North American Network Operators' Group
Re: Does anybody out there use Authentication Header (AH)?
daemon@ATHENA.MIT.EDU (TR Shaw)
Mon Jan 2 07:25:12 2012
From: TR Shaw <tshaw@oitc.com>
In-Reply-To: <042E9E42-4D3B-4F0D-B1C6-DBBE9F3AD4FE@cs.columbia.edu>
Date: Mon, 2 Jan 2012 07:24:15 -0500
To: Steven Bellovin <smb@cs.columbia.edu>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
As far as real world examples, I know of none that use AH only. All the =
operational uses I have seen in use are tunnels.
I would guess that if there are any it would be because some minimally =
technical COI rep thought that by using it it would provide some =
minimalist support of their interpretation of FISMA.
Tom=20
On Jan 1, 2012, at 9:03 PM, Steven Bellovin wrote:
> Yes, I know; I'm on that list. John Smith decided to see if=20
> reality matched theory -- always a good thing to do -- and asked
> here.
>=20
> Btw, it's not just "this time there is some support for it"; AH
> was downgraded to "MAY" in RFC 4301 in 2005.
>=20
>=20
> On Jan 1, 2012, at 8:56 PM, Jack Kohn wrote:
>=20
>> The __exact__ same discussion happening on IPsecME WG right now.
>>=20
>> http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html
>>=20
>> It seems there is yet another effort being made to "retire" AH so =
that
>> we have less # of options to deal with. This time there is some
>> support for it ..
>>=20
>> Jack
>>=20
>> On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb@cs.columbia.edu> =
wrote:
>>>=20
>>> On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
>>>=20
>>>> John,
>>>>=20
>>>> Unlike AH, ESP in transport mode does not provide integrity and =
authentication for the entire IP packet. However, in Tunnel Mode, =
where the entire original IP packet is encapsulated with a new packet =
header added, ESP protection is afforded to the whole inner IP packet =
(including the inner header) while the outer header (including any outer =
IPv4 options or IPv6 extension headers) remains unprotected. Thus, you =
need AH to authenticate the integrity of the outer header packet =
information.
>>>=20
>>>=20
>>> Not quite. While the cryptographic integrity check does not cover =
the source and destination addresses -- the really interesting part of =
the outer header -- they're bound to the security association, and hence =
checked separately. Below is a note I sent to the IPsec mailing list in =
1999.
>>>=20
>>> That, however, is not the question that is being asked here. The =
IPsecme working group has been over those issues repeatedly; your =
(non)-issue and (slightly) more substantive issues about IPv6 have been =
rehashed ad nauseum. The questions on the table now are, first, are =
operators using AH, and if so is ESP with NULL encryption an option?
>>>=20
>>> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>>>=20
>>>=20
>>> One of the biggest reasons we have AH is because there _are_
>>> some things in the middle of the "IP header" that need to be
>>> authenticated for them to be simultaneously safe and useful.
>>> The biggest example of this is source routing.
>>>=20
>>> In my opinion -- and I've posted this before -- there's nothing in =
the
>>> IP header that's both interesting and protected. You can't protect =
the
>>> source routing option, since the next-hop pointer changes en route.
>>> Appendix A of the AH draft recognizes that, and lists it as 'mutable =
--
>>> zeroed'.
>>>=20
>>> When you look over the list of IP header fields and options that are
>>> either immutable or predictable, you find that the only things that =
are
>>> really of interest are the source and destination addresses and the
>>> security label. To the extent that we want to protect the addresses =
--
>>> a point that's very unclear to me -- they're bound to the security
>>> association. The security label certainly should be. If you're =
using
>>> security labels (almost no one does) and you don't have the =
facilities
>>> to bind it at key management time, use tunnel mode and be done with =
it.
>>>=20
>>> I'll admit that I've never been in the operations business, =
but
>>> I've been told that source routing is a very useful tool for
>>> diagnosing some classes of problems. AH allows source routing
>>> to be useful again w/o opening the holes it opens.
>>>=20
>>> Well, yes, but not for the reason you specify. The problem with =
source
>>> routing is that it makes address-spoofing trivial. With AH, people
>>> will either verify certificate names -- the right way to do things =
--
>>> or they'll bind a certificate to the source address, and use AH to
>>> verify the legitimacy of it. The route specified has nothing to do
>>> with it, and ESP with null encryption does the same thing.
>>>=20
>>> I don't like AH, either in concept or design (and in particular I =
don't
>>> like the way it commits layer violations). Its only real use, as I =
see
>>> it, is to answer Greg Minshall's objections -- it leaves the port
>>> numbers in the clear, and visible in a context-independent fashion.
>>> With null encryption, the monitoring station has to know that that =
was
>>> selected. But I'm very far from convinced that these issues are
>>> important enough to justify AH.
>>>=20
>>> All that notwithstanding, this is not a new issue. We've been over
>>> this ground before in the working group. Several of us, myself
>>> included, suggested deleting AH. We lost. Fine; so be it. Let's =
ship
>>> the documents and be done with it.
>>=20
>=20
>=20
> --Steve Bellovin, https://www.cs.columbia.edu/~smb
>=20
>=20
>=20
>=20
>=20
>=20
