[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Protocols that refer AH (was: Death to AH)
"Steven M. Bellovin" wrote:
>
> In message <012701c0b628$79c1b960$fc2645ab@cisco.com>, "Scott Fanning" writes:
> >VRRP also talks about AH (<draft-ietf-vrrp-spec-v2-05.txt>), although it is
> >not integral to the protocol.
> >5.3.6.3 IP Authentication Header.
> >
> >Seeing that AH does authenticate more then ESP (the outside IP Header), has
> >there been any discussion on making a header that combines ESP and AH? I
> >know that ESP NULL provides just authentication, but not the same coverage
> >as AH.
>
> To what end? AH's problems come because it tries to cover too much of
> the packet; changing ESP to do that would cause the same problems.
> Remember that you can often bind the source IP address to the certificate,
> and check that match at decryption time.
>
> --Steve Bellovin, http://www.research.att.com/~smb
The problems with AH are probably partly due to the way it has been fixed in standards
as to exactly what header fields / options are to be protected. This gives NO flexibility
in the actual usage of AH. Someone wants to protect, say, a dest. IP address, someone else doesn't,
but wants to protect something else.
Just for discussion we might imagine an Alternative-AH specification that
has more simple rules, for IPv6:
- Anything appearing after AAH header is authenticated, any option before it
is not.
- The reserved fields part of the AAH header contains one bit per each IPv6
header field. If the bit is one, the field is included in the hash, otherwise not.
I'm not claiming this would actually work, because I'm not familiar with the
IPv6 rules for ordering options, and AH, in relation to each other. It wouldn't
work for IPv4 either.
Ari
--
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F-Secure products: Integrated Solutions for Enterprise Security
References: