In message <[EMAIL PROTECTED]>, martin f krafft writes : >As far as I can tell, IPsec's ESP has the functionality of >authentication and integrity built in: > >RFC 2406: > > 2.7 Authentication Data > > The Authentication Data is a variable-length field containing an > Integrity Check Value (ICV) computed over the ESP packet minus > the Authentication Data. The length of the field is specified by > the authentication function selected. The Authentication Data > field is optional, and is included only if the authentication > service has been selected for the SA in question. The > authentication algorithm specification MUST specify the length of > the ICV and the comparison rules and processing steps for > validation. > >To my knowledge, IPsec implementations use AH for "signing" though. >Why do we need AH, or why is it preferred? > >Thanks for your clarification!
The question has been asked quite often. The short answer is that AH protects parts of the preceeding IP header, which ESP doesn't do. I did an analysis many years ago which showed that everything in the AH header was either unprotectable, irrelevant, or protected in some other fashion. But the question has been re-opened, notably with regard to protecting Neighbor Discover in IPv6. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]