Re: Does anybody out there use Authentication Header (AH)?

[Steven Bellovin <smb () cs columbia edu>]

Yes, I know; I'm on that list.  John Smith decided to see if 
reality matched theory -- always a good thing to do -- and asked
here.

Btw, it's not just "this time there is some support for it"; AH
was downgraded to "MAY" in RFC 4301 in 2005.


On Jan 1, 2012, at 8:56 PM, Jack Kohn wrote:

> The __exact__ same discussion happening on IPsecME WG right now.
>
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html
>
> 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 ..
>
> Jack
>
> On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb () cs columbia edu> wrote:
> > On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
> >
> > > John,
> > >
> > > 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.
> >
> >
> > 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.
> >
> > 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?
> >
> >                --Steve Bellovin, https://www.cs.columbia.edu/~smb
> >
> >
> >        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.
> >
> > 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'.
> >
> > 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.
> >
> >        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.
> >
> > 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.
> >
> > 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.
> >
> > 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.


                --Steve Bellovin, https://www.cs.columbia.edu/~smb