AH is pretty useless and perhaps should be deprecated
Hi, Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG. http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html Post explaining that AH even though protecting the source and destination IP addresses is really not good enough. http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more .. Jack
I've never seen anyone use AH vs. ESP. I've always used ESP and so has every other IPSEC implementation I've seen anyone do. Owen On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
Jack
So who uses AH and why? Jack On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong <owen@delong.com> wrote:
I've never seen anyone use AH vs. ESP. I've always used ESP and so has every other IPSEC implementation I've seen anyone do.
Owen
On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
Jack
Junos VRRP with md5 authentication does..... On Sat, 2009-11-14 at 07:57 +0530, Jack Kohn wrote:
So who uses AH and why?
Jack
On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong <owen@delong.com> wrote:
I've never seen anyone use AH vs. ESP. I've always used ESP and so has every other IPSEC implementation I've seen anyone do.
Owen
On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
Jack
I prefer letting the market deprecate things. If no one uses AH, someday the IETF can mark it as "Historic," but long before that there will come a time when no one is interested in doing any more work on it. I was at the IETF IPsec WG meeting (in Los Angeles in the mid-90s) when AH would have died except once Microsoft strongly endorsed it, everyone else took the anti-MSFT viewpoint. Also, don't confuse "almost no one uses" for "no one uses" -- if AH is useful for someone, there is no harm in having a spec that tells them how to do it, and hopefully that spec is well written such that they can interoperate with other implementations. AH is less efficient than ESP because you have to buffer a whole packet prior to calculating the Integrity Check Value that goes in the AH [header], which goes at the front. The calculations you have to do involve parts of the packet that are both before and after the AH [header], including the packet's payload. Once you calculate the Integrity Check Value (ICV) you then stuff it in the appropriate part of the AH and send the packet. ESP's cryptographic goodness is appended at the end (and the packet is encrypted up until that point), and you can be doing a running cryptographic algorithm as the packet is streamed out (encrypted after the IP header and ESP header), then append the right amount of padding and the ESP "trailer" at the end. This site has some nice graphical depictions of AH and ESP (including the tunnel-mode vs. transport-mode that I didn't touch on: http://unixwiz.net/techtips/iguide-ipsec.html) Cheers, ~tom On Fri, Nov 13, 2009 at 18:27, Jack Kohn <kohn.jack@gmail.com> wrote:
So who uses AH and why?
Jack
On Sat, Nov 14, 2009 at 6:19 AM, Owen DeLong <owen@delong.com> wrote:
I've never seen anyone use AH vs. ESP. I've always used ESP and so has every other IPSEC implementation I've seen anyone do.
Owen
On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
Jack
Owen DeLong wrote:
I've never seen anyone use AH vs. ESP.
OSPFv3?
I've always used ESP and so has every other IPSEC implementation I've seen anyone do.
Owen
On Nov 13, 2009, at 4:22 PM, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
Jack
On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli <joelja@bogus.com> wrote:
Owen DeLong wrote:
I've never seen anyone use AH vs. ESP.
OSPFv3?
Maybe I'm asking a dumb question, but why would one prefer AH over ESP for OSPFv3? RFC4552: "In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH." -Bill
Bill Fehring wrote:
On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli <joelja@bogus.com> wrote:
Owen DeLong wrote:
I've never seen anyone use AH vs. ESP. OSPFv3?
Maybe I'm asking a dumb question, but why would one prefer AH over ESP for OSPFv3?
Header protection... still doesn't provide replay protection, your mileage may vary http://tools.ietf.org/html/draft-ietf-opsec-routing-protocols-crypto-issues-...
RFC4552: "In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH."
-Bill
I read the draft and its very interesting. There were some issues that i had never imagined could exist and it does a wonderful job of brining them forth. However, i still dont understand why AH would be preferred over ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying the OSPF packets. One could also do these things with AH. Am i missing something? Jack On Mon, Nov 16, 2009 at 11:47 AM, Joel Jaeggli <joelja@bogus.com> wrote:
Bill Fehring wrote:
On Sun, Nov 15, 2009 at 20:48, Joel Jaeggli <joelja@bogus.com> wrote:
Owen DeLong wrote:
I've never seen anyone use AH vs. ESP. OSPFv3?
Maybe I'm asking a dumb question, but why would one prefer AH over ESP for OSPFv3?
Header protection... still doesn't provide replay protection, your mileage may vary
http://tools.ietf.org/html/draft-ietf-opsec-routing-protocols-crypto-issues-...
RFC4552: "In order to provide authentication to OSPFv3, implementations MUST support ESP and MAY support AH."
-Bill
On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.jack@gmail.com> wrote:
However, i still dont understand why AH would be preferred over ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying the OSPF packets. One could also do these things with AH. Am i missing something?
Neither protects against replay without additional measures. However, AH is very close... consider using AH-authenticated packets with the timestamp option and clock synchronization between peers. Discard packets arriving that are more than 5 minutes old. In transport mode for security between LAN peers, ESP NULL verifies the integrity of only the data payload in the packet. AH secures the header, the IP header fields and options. Therefore changing the timestamp to replay would be detected. This evil act would not be detected if you are using ESP NULL, the attacker can potentially replay this packet, while the SPI is still good, and you'll never know. One of AH's most visible disadvantages (cannot be used with NAT) is a side-effect of the increased security coverage it provides. Many IPv4 networks require NAT, making AH impractical. However, matters could change for IPv6 networks with high security requirements, that need to validate authenticity of more than just packet contents... -- -J
On Nov 16, 2009, at 9:07 PM, James Hess wrote:
On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.jack@gmail.com> wrote:
However, i still dont understand why AH would be preferred over ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying the OSPF packets. One could also do these things with AH. Am i missing something?
Neither protects against replay without additional measures. However, AH is very close... consider using AH-authenticated packets with the timestamp option and clock synchronization between peers. Discard packets arriving that are more than 5 minutes old.
In transport mode for security between LAN peers, ESP NULL verifies the integrity of only the data payload in the packet. AH secures the header, the IP header fields and options.
Therefore changing the timestamp to replay would be detected. This evil act would not be detected if you are using ESP NULL, the attacker can potentially replay this packet, while the SPI is still good, and you'll never know.
One of AH's most visible disadvantages (cannot be used with NAT) is a side-effect of the increased security coverage it provides. Many IPv4 networks require NAT, making AH impractical.
However, matters could change for IPv6 networks with high security requirements, that need to validate authenticity of more than just packet contents...
Except for multicast packets -- the case of interest for OSPFv3, and even there the spec arguably got it wrong -- you can check the source IP address against the SPD. That is, you can't replay my ESP packets in a unicast connection with a different source address because packets from your source address on my SPI will be rejected. ESP does have antireplay protection; admittedly, that's disabled if manual keying is used, but generally speaking, manual keying shouldn't be used, per RFC 4107. The interesting case is multicast. 4552 seems to assume symmetric keys, but that's a bad idea; it lets other members of the authorized group impersonate each other. What you really want is digitally signed packets, where each source has a key. I don't think that the IETF's multicast key management protocols are quite up to the job, though; they focus on single source multicast, which isn't what OSPF needs. (That said, 5374 seems to point in the proper direction, but I haven't been following this work.) It may be that the proper answer for OSPFv3 is its own strong multicast security. --Steve Bellovin, http://www.cs.columbia.edu/~smb
+1. I know of a network whose owners are far more worried about a replay attack than about data being revealed to the outside world. They need to verify the provenance of data (i. e. Make sure that it hasn't bee Natted), and AH is a simple way to do these precise things. -David Barak James Hess wrote:
However, i still dont understand why AH would be preferred over ESP-NULL in case of OSPFv3. The draft speaks of issues with replaying the OSPF packets. One could also do these things with AH. Am i missing something? Neither protects against replay without additional measures. However, AH is very close... consider using AH-authenticated
On Mon, Nov 16, 2009 at 6:23 PM, Jack Kohn <kohn.jack@gmail.com> wrote: packets with the timestamp option and clock synchronization between peers. Discard packets arriving that are more than 5 minutes old. In transport mode for security between LAN peers, ESP NULL verifies the integrity of only the data payload in the packet. AH secures the header, the IP header fields and options. Therefore changing the timestamp to replay would be detected. This evil act would not be detected if you are using ESP NULL, the attacker can potentially replay this packet, while the SPI is still good, and you'll never know. One of AH's most visible disadvantages (cannot be used with NAT) is a side-effect of the increased security coverage it provides. Many IPv4 networks require NAT, making AH impractical. However, matters could change for IPv6 networks with high security requirements, that need to validate authenticity of more than just packet contents... -- -J
I have see AH used in network segmentation. I.e. systems is group A are configured with rules to require all communication be over AH. Systems in group B (which have no AH and no appropriate certificates configured) can't chat with group A. The benefit of using AH vs. ESP in this case is twofold. First, AH is less CPU intensive, and when one considers enabling it on all/many workstations and servers in a company, that can add up to a lot of CPU cycles. Second, since AH only signs, not encrypts, products like network analyzers, IDS/IPS, etc can still perform their functions. Outside of some manual deployments, the only commercial product I know that offers AH based network segmentation is Microsoft's NAP: http://www.microsoft.com/nap Regards, Adam Stasiniewicz -----Original Message----- From: Jack Kohn [mailto:kohn.jack@gmail.com] Sent: Friday, November 13, 2009 6:23 PM To: nanog@nanog.org Subject: AH is pretty useless and perhaps should be deprecated Hi, Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG. http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html Post explaining that AH even though protecting the source and destination IP addresses is really not good enough. http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more .. Jack
On Nov 14, 2009, at 2:46 PM, Adam Stasiniewicz wrote:
I have see AH used in network segmentation. I.e. systems is group A are configured with rules to require all communication be over AH. Systems in group B (which have no AH and no appropriate certificates configured) can't chat with group A. The benefit of using AH vs. ESP in this case is twofold. First, AH is less CPU intensive, and when one considers enabling it on all/many workstations and servers in a company, that can add up to a lot of CPU cycles. Second, since AH only signs, not encrypts, products like network analyzers, IDS/IPS, etc can still perform their functions.
ESP with NULL encryption only authenticates (not "signs") also. However, one can't tell in a context-free way that NULL is in use. If you're using it, though, I can't see how AH could be less expensive. AH has been controversial for years. I've been asking folks to delete it since 1995. I've never succeeded... At least RFC 4301 deprecated it to a MAY instead of a MUST for IPsec implementors.
Outside of some manual deployments, the only commercial product I know that offers AH based network segmentation is Microsoft's NAP: http://www.microsoft.com/nap
Regards, Adam Stasiniewicz
-----Original Message----- From: Jack Kohn [mailto:kohn.jack@gmail.com] Sent: Friday, November 13, 2009 6:23 PM To: nanog@nanog.org Subject: AH is pretty useless and perhaps should be deprecated
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
Jack
--Steve Bellovin, http://www.cs.columbia.edu/~smb
I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect. However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com
On Nov 14, 2009, at 8:28 PM, David Barak wrote:
I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect.
However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate?
There are two reasons. First, it's difficult to implement cleanly, since it violates layering: you have to know the contents of the surrounding IP header to calculate the AH field. Back when I was security AD, I had implementors, especially implementors of on-NIC IPsec, beg me to get rid of it. Second, it's redundant; if (as I believe), ESP with NULL encryption does everything useful that AH does, why have two mechanisms? --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Nov 14, 2009, at 9:58 PM, Steven Bellovin wrote:
On Nov 14, 2009, at 8:28 PM, David Barak wrote:
I've seen AH used as a "prove that this hasn't been through a NAT" mechanism. In this context, it's pretty much perfect.
However, what I don't understand is where the dislike for it originates: if you don't like it, don't run it. It is useful in certain cases, and it's already in all of the production IPSec implementations. Why the hate?
There are two reasons. First, it's difficult to implement cleanly, since it violates layering: you have to know the contents of the surrounding IP header to calculate the AH field. Back when I was security AD, I had implementors, especially implementors of on-NIC IPsec, beg me to get rid of it. Second, it's redundant; if (as I believe), ESP with NULL encryption does everything useful that AH does, why have two mechanisms?
Maybe someone should push through a "IPSEC-lite" in the same way we are pushing through IGMPv3-lite.
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Regards Marshall
On Sat, 14 Nov 2009, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
They are planning to make OSPFv3 IPSec authentication useless? Best Regards, Janos Mohacsi
No - if you read the below pointers carefully it does specify that ESP-Null is a MUST for OSPFv3 authentication protocol while AH is a MAY. AH is mostly superfluous and complicates implementations. Someone on the IPsec mailing list stated that at least two implementations he was aware of used ESP-Null for OSPFv3 where one did not even have any support for AH. And I know I'm probably violating some posting etiquette here but to answer an earlier comment on same thread where someone asked why the hate for AH and what's problem if it's already in all of the production IPsec implementations.......I can firsthand state that for many IPsec interoperability tests AH is hardly if ever tested. I have been a part of some of them as an interested 3rd party (i.e. non vendor) so have seen what gets tested. AH is always last from what I've seen and rarely does anyone ever get to it. [caveat - my experience comes from multivendor consortium type tests and not what vendors may do privately amongst themselves] And FWIW.....I've been doing skunskwork IPsec for past 10 years and right now there's yet another effort to come up with interoperable defaults which is being lead by the aviation industry and is looking at IETF defined profiles, NSA related recommendations, NIST recommendations and ICSA IPsec consortium recommendations. There was a meeting in Seattle last week and many vendors as well as NIST, DoD and other parties participated. If you are at all running IPsec in a major way and care about interoperable defaults and consistent terminology, contact me offline and I'll get you connected to the group. Vendors will only 'fix' their implementations if there's cohesion from customer base. - merike On Nov 14, 2009, at 10:58 PM, Mohacsi Janos wrote:
On Sat, 14 Nov 2009, Jack Kohn wrote:
Hi,
Interesting discussion on the utility of Authentication Header (AH) in IPSecME WG.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05026.html
Post explaining that AH even though protecting the source and destination IP addresses is really not good enough.
http://www.ietf.org/mail-archive/web/ipsec/current/msg05056.html
What do folks feel? Do they see themselves using AH in the future? IMO, ESP and WESP are good enough and we dont need to support AH any more ..
They are planning to make OSPFv3 IPSec authentication useless? Best Regards, Janos Mohacsi
participants (13)
-
Adam Stasiniewicz -
Bill Fehring -
David Barak -
Jack Kohn -
James Hess -
Joel Jaeggli -
Luca Tosolini -
Marshall Eubanks -
Merike Kaeo -
Mohacsi Janos -
Owen DeLong -
Steven Bellovin -
Thomas Maufer