Re: authentication and ESP
John S. Denker wrote: On 06/19/2003 01:49 PM, martin f krafft wrote: > As far as I can tell, IPsec's ESP has the functionality of > authentication and integrity built in: It depends on what you mean by "built in". 1) The RFC provides for ESP+authentication but does not require ESP to use authentication. 2) Although the RFC allows ESP without authentication, typical implementations are less flexible. In FreeS/WAN for instance, if you ask for ESP will get ESP+AH. ESP without authentication may be vulnerable to replay attacks and/or active attacks that tamper with the bits in transit. The degree of vulnerability depends on details (type of chaining, higher-level properties of payload, ...). There's some discussion and links in the FreeS/WAN docs: http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/ipsec.html#encnoauth - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: authentication and ESP
"John S. Denker" <[EMAIL PROTECTED]> writes: > On 06/19/2003 01:49 PM, martin f krafft wrote: > > As far as I can tell, IPsec's ESP has the functionality of > > authentication and integrity built in: > > It depends on what you mean by "built in". > 1) The RFC provides for ESP+authentication but > does not require ESP to use authentication. I don't know what you mean. Yes, ESP doesn't per se forbid the construction of a new algorithm/mode that doesn't do authentication, but all of the ESP algorithms/modes currently in use do authentication. Perry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: authentication and ESP
On 06/19/2003 01:49 PM, martin f krafft wrote: > As far as I can tell, IPsec's ESP has the functionality of > authentication and integrity built in: It depends on what you mean by "built in". 1) The RFC provides for ESP+authentication but does not require ESP to use authentication. 2) Although the RFC allows ESP without authentication, typical implementations are less flexible. In FreeS/WAN for instance, if you ask for ESP will get ESP+AH. ESP without authentication may be vulnerable to replay attacks and/or active attacks that tamper with the bits in transit. The degree of vulnerability depends on details (type of chaining, higher-level properties of payload, ...). Remember that encryption and authentication perform complimentary roles: Suppose Alice is sending to Bob. They are being attacked by Eve. Encryption limits the amount of information _Eve_ receives. Authentication prevents tampering, so _Bob_ can trust what he receives. It is possible to construct situations where you could omit the AH from ESP+AH without losing anything, but you would need to analyze the situation pretty carefully. If you have a good reason for using something other than ESP+AH, please clarify what you want to do and why. Otherwise just go with the normal ESP+AH. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: authentication and ESP
you really don't want to open this can of worms I suggest you go read the archives of the IPsec mailing list over the last 9 years. That should give you some clue into the depth of the can you plan to open... -derek martin f krafft <[EMAIL PROTECTED]> 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! > > -- > martin; (greetings from the heart of the sun.) > \ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED] > > invalid PGP subkeys? use subkeys.pgp.net as keyserver! > > XP is NT with eXtra Problems. -- Derek Atkins [EMAIL PROTECTED] www.ihtfp.com Computer and Internet Security Consultant - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
