[13684] in cryptography@c2.net mail archive
Re: authentication and ESP
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Fri Jun 20 22:30:38 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
To: crypto list <cryptography@metzdowd.com>
Date: Fri, 20 Jun 2003 14:28:40 -0400
From: "Steven M. Bellovin" <smb@research.att.com>
In message <20030619174940.GA18220@diamond.madduck.net>, 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 majordomo@metzdowd.com
