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, (me)
       (2nd edition of "Firewalls" book)

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to