Does anybody out there use Authentication Header (AH)?
Hi, I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL. Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them? Regards, John
On Jan 1, 2012, at 7:12 PM, John Smith wrote:
Hi,
I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL.
Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them?
Regards, John
AH provides for connectionless integrity and data origin authentication and provides protection against replay attacks. Many US Gov departments that have to follow NIST and do not understand what this means require it between internal point-to-point routers between one portion of their organization and another adding more expense for no increase in operational security. If you are following NIST or DCID-63, this is required to meet certain integrity requirements ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. EG AH portion provides for the integrity requirement and the ESP encryption provides for the confidentiality requirement of NIST. Think of AH that it is like just signing a PGPMail and ESP as signing and encrypting a PGPMail. There are reasons for both. Tom
Hi Tom, Thanks for the reply. Why cant we use ESP/NULL for meeting the NIST requirement? Is there something extra that AH offers here? Regards, John ________________________________ From: TR Shaw <tshaw@oitc.com> To: John Smith <jsmith4112003@yahoo.co.uk> Cc: "nanog@nanog.org" <nanog@nanog.org> Sent: Monday, 2 January 2012, 5:57 Subject: Re: Does anybody out there use Authentication Header (AH)? On Jan 1, 2012, at 7:12 PM, John Smith wrote:
Hi,
I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL.
Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them?
Regards, John
AH provides for connectionless integrity and data origin authentication and provides protection against replay attacks. Many US Gov departments that have to follow NIST and do not understand what this means require it between internal point-to-point routers between one portion of their organization and another adding more expense for no increase in operational security. If you are following NIST or DCID-63, this is required to meet certain integrity requirements ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. EG AH portion provides for the integrity requirement and the ESP encryption provides for the confidentiality requirement of NIST. Think of AH that it is like just signing a PGPMail and ESP as signing and encrypting a PGPMail. There are reasons for both. Tom
John, Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. Thus, you need AH to authenticate the integrity of the outer header packet information. Again, just like PGPMail as I explained before, Tom On Jan 1, 2012, at 7:32 PM, John Smith wrote:
Hi Tom,
Thanks for the reply.
Why cant we use ESP/NULL for meeting the NIST requirement? Is there something extra that AH offers here?
Regards, John
From: TR Shaw <tshaw@oitc.com> To: John Smith <jsmith4112003@yahoo.co.uk> Cc: "nanog@nanog.org" <nanog@nanog.org> Sent: Monday, 2 January 2012, 5:57 Subject: Re: Does anybody out there use Authentication Header (AH)?
On Jan 1, 2012, at 7:12 PM, John Smith wrote:
Hi,
I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL.
Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them?
Regards, John
AH provides for connectionless integrity and data origin authentication and provides protection against replay attacks. Many US Gov departments that have to follow NIST and do not understand what this means require it between internal point-to-point routers between one portion of their organization and another adding more expense for no increase in operational security.
If you are following NIST or DCID-63, this is required to meet certain integrity requirements
ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. EG AH portion provides for the integrity requirement and the ESP encryption provides for the confidentiality requirement of NIST.
Think of AH that it is like just signing a PGPMail and ESP as signing and encrypting a PGPMail.
There are reasons for both.
Tom
On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
John,
Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. Thus, you need AH to authenticate the integrity of the outer header packet information.
Not quite. While the cryptographic integrity check does not cover the source and destination addresses -- the really interesting part of the outer header -- they're bound to the security association, and hence checked separately. Below is a note I sent to the IPsec mailing list in 1999. That, however, is not the question that is being asked here. The IPsecme working group has been over those issues repeatedly; your (non)-issue and (slightly) more substantive issues about IPv6 have been rehashed ad nauseum. The questions on the table now are, first, are operators using AH, and if so is ESP with NULL encryption an option? --Steve Bellovin, https://www.cs.columbia.edu/~smb One of the biggest reasons we have AH is because there _are_ some things in the middle of the "IP header" that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing. In my opinion -- and I've posted this before -- there's nothing in the IP header that's both interesting and protected. You can't protect the source routing option, since the next-hop pointer changes en route. Appendix A of the AH draft recognizes that, and lists it as 'mutable -- zeroed'. When you look over the list of IP header fields and options that are either immutable or predictable, you find that the only things that are really of interest are the source and destination addresses and the security label. To the extent that we want to protect the addresses -- a point that's very unclear to me -- they're bound to the security association. The security label certainly should be. If you're using security labels (almost no one does) and you don't have the facilities to bind it at key management time, use tunnel mode and be done with it. I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens. Well, yes, but not for the reason you specify. The problem with source routing is that it makes address-spoofing trivial. With AH, people will either verify certificate names -- the right way to do things -- or they'll bind a certificate to the source address, and use AH to verify the legitimacy of it. The route specified has nothing to do with it, and ESP with null encryption does the same thing. I don't like AH, either in concept or design (and in particular I don't like the way it commits layer violations). Its only real use, as I see it, is to answer Greg Minshall's objections -- it leaves the port numbers in the clear, and visible in a context-independent fashion. With null encryption, the monitoring station has to know that that was selected. But I'm very far from convinced that these issues are important enough to justify AH. All that notwithstanding, this is not a new issue. We've been over this ground before in the working group. Several of us, myself included, suggested deleting AH. We lost. Fine; so be it. Let's ship the documents and be done with it.
The __exact__ same discussion happening on IPsecME WG right now. http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html It seems there is yet another effort being made to "retire" AH so that we have less # of options to deal with. This time there is some support for it .. Jack On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
John,
Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. Thus, you need AH to authenticate the integrity of the outer header packet information.
Not quite. While the cryptographic integrity check does not cover the source and destination addresses -- the really interesting part of the outer header -- they're bound to the security association, and hence checked separately. Below is a note I sent to the IPsec mailing list in 1999.
That, however, is not the question that is being asked here. The IPsecme working group has been over those issues repeatedly; your (non)-issue and (slightly) more substantive issues about IPv6 have been rehashed ad nauseum. The questions on the table now are, first, are operators using AH, and if so is ESP with NULL encryption an option?
--Steve Bellovin, https://www.cs.columbia.edu/~smb
One of the biggest reasons we have AH is because there _are_ some things in the middle of the "IP header" that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing.
In my opinion -- and I've posted this before -- there's nothing in the IP header that's both interesting and protected. You can't protect the source routing option, since the next-hop pointer changes en route. Appendix A of the AH draft recognizes that, and lists it as 'mutable -- zeroed'.
When you look over the list of IP header fields and options that are either immutable or predictable, you find that the only things that are really of interest are the source and destination addresses and the security label. To the extent that we want to protect the addresses -- a point that's very unclear to me -- they're bound to the security association. The security label certainly should be. If you're using security labels (almost no one does) and you don't have the facilities to bind it at key management time, use tunnel mode and be done with it.
I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens.
Well, yes, but not for the reason you specify. The problem with source routing is that it makes address-spoofing trivial. With AH, people will either verify certificate names -- the right way to do things -- or they'll bind a certificate to the source address, and use AH to verify the legitimacy of it. The route specified has nothing to do with it, and ESP with null encryption does the same thing.
I don't like AH, either in concept or design (and in particular I don't like the way it commits layer violations). Its only real use, as I see it, is to answer Greg Minshall's objections -- it leaves the port numbers in the clear, and visible in a context-independent fashion. With null encryption, the monitoring station has to know that that was selected. But I'm very far from convinced that these issues are important enough to justify AH.
All that notwithstanding, this is not a new issue. We've been over this ground before in the working group. Several of us, myself included, suggested deleting AH. We lost. Fine; so be it. Let's ship the documents and be done with it.
Yes, I know; I'm on that list. John Smith decided to see if reality matched theory -- always a good thing to do -- and asked here. Btw, it's not just "this time there is some support for it"; AH was downgraded to "MAY" in RFC 4301 in 2005. On Jan 1, 2012, at 8:56 PM, Jack Kohn wrote:
The __exact__ same discussion happening on IPsecME WG right now.
http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html
It seems there is yet another effort being made to "retire" AH so that we have less # of options to deal with. This time there is some support for it ..
Jack
On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
John,
Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. Thus, you need AH to authenticate the integrity of the outer header packet information.
Not quite. While the cryptographic integrity check does not cover the source and destination addresses -- the really interesting part of the outer header -- they're bound to the security association, and hence checked separately. Below is a note I sent to the IPsec mailing list in 1999.
That, however, is not the question that is being asked here. The IPsecme working group has been over those issues repeatedly; your (non)-issue and (slightly) more substantive issues about IPv6 have been rehashed ad nauseum. The questions on the table now are, first, are operators using AH, and if so is ESP with NULL encryption an option?
--Steve Bellovin, https://www.cs.columbia.edu/~smb
One of the biggest reasons we have AH is because there _are_ some things in the middle of the "IP header" that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing.
In my opinion -- and I've posted this before -- there's nothing in the IP header that's both interesting and protected. You can't protect the source routing option, since the next-hop pointer changes en route. Appendix A of the AH draft recognizes that, and lists it as 'mutable -- zeroed'.
When you look over the list of IP header fields and options that are either immutable or predictable, you find that the only things that are really of interest are the source and destination addresses and the security label. To the extent that we want to protect the addresses -- a point that's very unclear to me -- they're bound to the security association. The security label certainly should be. If you're using security labels (almost no one does) and you don't have the facilities to bind it at key management time, use tunnel mode and be done with it.
I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens.
Well, yes, but not for the reason you specify. The problem with source routing is that it makes address-spoofing trivial. With AH, people will either verify certificate names -- the right way to do things -- or they'll bind a certificate to the source address, and use AH to verify the legitimacy of it. The route specified has nothing to do with it, and ESP with null encryption does the same thing.
I don't like AH, either in concept or design (and in particular I don't like the way it commits layer violations). Its only real use, as I see it, is to answer Greg Minshall's objections -- it leaves the port numbers in the clear, and visible in a context-independent fashion. With null encryption, the monitoring station has to know that that was selected. But I'm very far from convinced that these issues are important enough to justify AH.
All that notwithstanding, this is not a new issue. We've been over this ground before in the working group. Several of us, myself included, suggested deleting AH. We lost. Fine; so be it. Let's ship the documents and be done with it.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
As far as real world examples, I know of none that use AH only. All the operational uses I have seen in use are tunnels. I would guess that if there are any it would be because some minimally technical COI rep thought that by using it it would provide some minimalist support of their interpretation of FISMA. Tom On Jan 1, 2012, at 9:03 PM, Steven Bellovin wrote:
Yes, I know; I'm on that list. John Smith decided to see if reality matched theory -- always a good thing to do -- and asked here.
Btw, it's not just "this time there is some support for it"; AH was downgraded to "MAY" in RFC 4301 in 2005.
On Jan 1, 2012, at 8:56 PM, Jack Kohn wrote:
The __exact__ same discussion happening on IPsecME WG right now.
http://www.ietf.org/mail-archive/web/ipsec/current/msg07346.html
It seems there is yet another effort being made to "retire" AH so that we have less # of options to deal with. This time there is some support for it ..
Jack
On Mon, Jan 2, 2012 at 7:20 AM, Steven Bellovin <smb@cs.columbia.edu> wrote:
On Jan 1, 2012, at 8:34 PM, TR Shaw wrote:
John,
Unlike AH, ESP in transport mode does not provide integrity and authentication for the entire IP packet. However, in Tunnel Mode, where the entire original IP packet is encapsulated with a new packet header added, ESP protection is afforded to the whole inner IP packet (including the inner header) while the outer header (including any outer IPv4 options or IPv6 extension headers) remains unprotected. Thus, you need AH to authenticate the integrity of the outer header packet information.
Not quite. While the cryptographic integrity check does not cover the source and destination addresses -- the really interesting part of the outer header -- they're bound to the security association, and hence checked separately. Below is a note I sent to the IPsec mailing list in 1999.
That, however, is not the question that is being asked here. The IPsecme working group has been over those issues repeatedly; your (non)-issue and (slightly) more substantive issues about IPv6 have been rehashed ad nauseum. The questions on the table now are, first, are operators using AH, and if so is ESP with NULL encryption an option?
--Steve Bellovin, https://www.cs.columbia.edu/~smb
One of the biggest reasons we have AH is because there _are_ some things in the middle of the "IP header" that need to be authenticated for them to be simultaneously safe and useful. The biggest example of this is source routing.
In my opinion -- and I've posted this before -- there's nothing in the IP header that's both interesting and protected. You can't protect the source routing option, since the next-hop pointer changes en route. Appendix A of the AH draft recognizes that, and lists it as 'mutable -- zeroed'.
When you look over the list of IP header fields and options that are either immutable or predictable, you find that the only things that are really of interest are the source and destination addresses and the security label. To the extent that we want to protect the addresses -- a point that's very unclear to me -- they're bound to the security association. The security label certainly should be. If you're using security labels (almost no one does) and you don't have the facilities to bind it at key management time, use tunnel mode and be done with it.
I'll admit that I've never been in the operations business, but I've been told that source routing is a very useful tool for diagnosing some classes of problems. AH allows source routing to be useful again w/o opening the holes it opens.
Well, yes, but not for the reason you specify. The problem with source routing is that it makes address-spoofing trivial. With AH, people will either verify certificate names -- the right way to do things -- or they'll bind a certificate to the source address, and use AH to verify the legitimacy of it. The route specified has nothing to do with it, and ESP with null encryption does the same thing.
I don't like AH, either in concept or design (and in particular I don't like the way it commits layer violations). Its only real use, as I see it, is to answer Greg Minshall's objections -- it leaves the port numbers in the clear, and visible in a context-independent fashion. With null encryption, the monitoring station has to know that that was selected. But I'm very far from convinced that these issues are important enough to justify AH.
All that notwithstanding, this is not a new issue. We've been over this ground before in the working group. Several of us, myself included, suggested deleting AH. We lost. Fine; so be it. Let's ship the documents and be done with it.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Tom, It seems NIST recommends ESP over AH. You can look at the following 2 emails from Manav and Sriram on the IPsecME WG: http://www.ietf.org/mail-archive/web/ipsec/current/msg07403.html http://www.ietf.org/mail-archive/web/ipsec/current/msg07407.html Jack On Mon, Jan 2, 2012 at 5:57 AM, TR Shaw <tshaw@oitc.com> wrote:
On Jan 1, 2012, at 7:12 PM, John Smith wrote:
Hi,
I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL.
Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them?
Regards, John
AH provides for connectionless integrity and data origin authentication and provides protection against replay attacks. Many US Gov departments that have to follow NIST and do not understand what this means require it between internal point-to-point routers between one portion of their organization and another adding more expense for no increase in operational security.
If you are following NIST or DCID-63, this is required to meet certain integrity requirements
ESP provides confidentiality, data origin authentication, connectionless integrity, an anti-replay service, and limited traffic flow confidentiality. EG AH portion provides for the integrity requirement and the ESP encryption provides for the confidentiality requirement of NIST.
Think of AH that it is like just signing a PGPMail and ESP as signing and encrypting a PGPMail.
There are reasons for both.
Tom
(Sigh) Here we go again. AH is a liability and a baggage that we're carrying over our weary shoulders. IMO we should have gotten rid of it long time back. There have been enough emails on multiple forums over this and google is probably your friend here. The only reason(s) we have AH is because (i) circa early 1990s, US had export restrictions on encryption keys > 40 bits and ESP thus had restrictions on how it could be used. AH otoh, only did authentication, for which the rules were much more relaxed AND (ii) people earlier naively believed that AH protected the IP header and ESP couldnt. AH is a mess if you have NATs deployed, as AH breaks NAT. IPv6 proponents thus saw AH as a tool to push IPv6, since they hated NATs (till someone discovered IPv6 NAT-PT, but thats a different story). Most people think ESP as "encryption" - they forget that it can be used for data integrity verification without encryption as well. Glen On Mon, Jan 2, 2012 at 5:42 AM, John Smith <jsmith4112003@yahoo.co.uk> wrote:
Hi,
I am trying to see if there are people who use AH specially since RFC 4301 has a MAY for AH and a MUST for ESP-NULL. While operators may not care about a MAY or a MUST in an RFC, but the IETF protocols and vendors do. So all protocols that require IPsec for authentication implicitly have a MAY for AH and a MUST for ESP-NULL.
Given that there is hardly a difference between the two, I am trying to understand the scenarios where people might want to use AH? OR is it that people dont care and just use what their vendors provide them?
Regards, John
participants (5)
-
Glen Kent -
Jack Kohn -
John Smith -
Steven Bellovin -
TR Shaw