authentication and ESP

[Steven M. Bellovin]

In message <20030619174940.GA18220 at 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 at metzdowd.com