Re: IPSec without AH
On Sun, 23 Jan 2005 13:47:35 +0100, Erik Norgaard [EMAIL PROTECTED] wrote: Hi, Due to the problems of IPSec with NAT I was thinking if it is posible to setup IPSec without Authenticated Headers? Does anyone know of a howto? My postulate is that since data is encrypted, this should provide the same security as SSL/TLS - or better as _all_ protocols are encapsulated - or did I miss something? Thanks, Erik The AH (Authenticated Header) protocol cannot be used with NAT, NAT modifies the header of packets, while AH is supposed to protect that header from being modified. Another IPSEC protocol ESP (Encrypted Security Payload), both authenticates and encrypts, and thus has no problem with NAT traversal. BTW I am not an IPSEC expert, just scratched its surface a little bit ;) =Adriaan= ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPSec without AH
J65nko BSD wrote: Due to the problems of IPSec with NAT I was thinking if it is posible to setup IPSec without Authenticated Headers? Does anyone know of a howto? The AH (Authenticated Header) protocol cannot be used with NAT, NAT modifies the header of packets, while AH is supposed to protect that header from being modified. Another IPSEC protocol ESP (Encrypted Security Payload), both authenticates and encrypts, and thus has no problem with NAT traversal. Thanks, AFAIK, ESP and AH are used in conjunction in IPSec, ESP for encrypting the packet payload, and AH for authentication. ESP in it self does not provide authentication, but only encrypts the payload - hence the names :-) Since ESP only encrypts the payload, as you say, ESP has no problem with NAT, whereas AH appends a signed checksum of the header. And since NAT alters the header, verifying the AH fails. Ofcourse, it requires access to the (public?) keys to create valid encrypted packets. Hence, if the public key is kept as a shared secret among the authorized users, one could assume that ESP packets are authenticated/trusted. This is my idea, discard AH, rely on ESP and assume that anyone capable of producing decryptable packets must have access to the pre-shared secret public key and hence authorized. AH would work, if both ends were NATaware, such that the rigth src/dst ip could be inserted in the header before checking. It just occured to me that maybe this could be done by adding yet another IP/IP tunnel? Cheers, Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPSec without AH
On Sun, 23 Jan 2005 14:54:46 +0100, Erik Norgaard [EMAIL PROTECTED] wrote: J65nko BSD wrote: Due to the problems of IPSec with NAT I was thinking if it is posible to setup IPSec without Authenticated Headers? Does anyone know of a howto? The AH (Authenticated Header) protocol cannot be used with NAT, NAT modifies the header of packets, while AH is supposed to protect that header from being modified. Another IPSEC protocol ESP (Encrypted Security Payload), both authenticates and encrypts, and thus has no problem with NAT traversal. Thanks, AFAIK, ESP and AH are used in conjunction in IPSec, ESP for encrypting the packet payload, and AH for authentication. ESP in it self does not provide authentication, but only encrypts the payload - hence the names :-) Since ESP only encrypts the payload, as you say, ESP has no problem with NAT, whereas AH appends a signed checksum of the header. And since NAT alters the header, verifying the AH fails. Ofcourse, it requires access to the (public?) keys to create valid encrypted packets. Hence, if the public key is kept as a shared secret among the authorized users, one could assume that ESP packets are authenticated/trusted. This is my idea, discard AH, rely on ESP and assume that anyone capable of producing decryptable packets must have access to the pre-shared secret public key and hence authorized. Your are not the first to have this idea. The authors of Secure Architectures with OpenBSD already published this ;) AH would work, if both ends were NATaware, such that the rigth src/dst ip could be inserted in the header before checking. It just occured to me that maybe this could be done by adding yet another IP/IP tunnel? Cheers, Erik OpenBSD 3.6 supports NAT traversal. From http://openbsd.org/36.html: isakmpd(8) now supports NAT-traversal and Dead Peer Detection (RFC 3706). Don't know how ling it would take to before this is supported by FreeBSD ;) =Adriaan= ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPSec without AH
J65nko BSD wrote: Ofcourse, it requires access to the (public?) keys to create valid encrypted packets. Hence, if the public key is kept as a shared secret among the authorized users, one could assume that ESP packets are authenticated/trusted. This is my idea, discard AH, rely on ESP and assume that anyone capable of producing decryptable packets must have access to the pre-shared secret public key and hence authorized. Your are not the first to have this idea. The authors of Secure Architectures with OpenBSD already published this ;) Dang! Why do someone always steal my ideas before I get them? AH would work, if both ends were NATaware, such that the rigth src/dst ip could be inserted in the header before checking. It just occured to me that maybe this could be done by adding yet another IP/IP tunnel? OpenBSD 3.6 supports NAT traversal. From http://openbsd.org/36.html: isakmpd(8) now supports NAT-traversal and Dead Peer Detection (RFC 3706). Don't know how ling it would take to before this is supported by FreeBSD ;) Interesting, I'll take a look at that - thanks. Erik -- Ph: +34.666334818 web: http://www.locolomo.org S/MIME Certificate: http://www.locolomo.org/crt/2004071206.crt Subject ID: A9:76:7A:ED:06:95:2B:8D:48:97:CE:F2:3F:42:C8:F2:22:DE:4C:B9 Fingerprint: 4A:E8:63:38:46:F6:9A:5D:B4:DC:29:41:3F:62:D3:0A:73:25:67:C2 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
