Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Hi Dan I have no opinion about the level of review needed for changes to IKEv1, and I share your unhappiness with the way PAKE turned out. If I had to guess the reasons for the slow adoption of IKEv2, I would guess that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and poor PSK support for mobile peers) just works. The big vendors have at least server-side support, and Microsoft has a client in Win7. I think EAP is a hindrance, because XAuth works better with older backend servers. Your proposal will be more secure than XAuth and require less round trips, but won't integrate with AAA servers. I think anyone who is going to go to the effort of implementing this (replace or update all IKEv1 endpoints) might as well move them to IKEv2. The big hurdle to implementing what you suggest for remote access is that XAuth works. What doesn't work is a gateway with a dynamic external IP address that doesn't have a certificate. But I don't see how upgrading the gateways to support your extension is easier than upgrading them to support IKEv2. Yoav On Mar 28, 2012, at 9:49 AM, Dan Harkins wrote: Hi, Let me answer David here in a response to Yaron To be equally blunt, it is because this PAKE work became extremely political and I was, and still am, very unhappy with the way it turned out. Repeating it, this time with an obsoleted protocol, would cause (more) people to question my sanity-- i.e. doing the same thing and expecting a different result. I'd like to just get a stable reference for this minor change that has the potential to do good. I don't want to fight over it anymore. regards, Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Yoav == Yoav Nir y...@checkpoint.com writes: Yoav If I had to guess the reasons for the slow adoption of IKEv2, Yoav I would guess that it's because IKEv1 (with XAuth/hybrid, Yoav Config, odd-numbered messages, and poor PSK support for mobile Yoav peers) just works. The big vendors have at least server-side Yoav support, and Microsoft has a client in Win7. I think EAP is a Yoav hindrance, because XAuth works better with older backend Yoav servers. Let me suggest that enhancements to IKEv1 are point releases, for which you get with your maintenance. But, IKEv2 is a major release, for which the customer pays again. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. pgpkqNgeB9Jzz.pgp Description: PGP signature ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote: Yoav == Yoav Nir y...@checkpoint.com writes: Yoav If I had to guess the reasons for the slow adoption of IKEv2, Yoav I would guess that it's because IKEv1 (with XAuth/hybrid, Yoav Config, odd-numbered messages, and poor PSK support for mobile Yoav peers) just works. The big vendors have at least server-side Yoav support, and Microsoft has a client in Win7. I think EAP is a Yoav hindrance, because XAuth works better with older backend Yoav servers. Let me suggest that enhancements to IKEv1 are point releases, for which you get with your maintenance. But, IKEv2 is a major release, for which the customer pays again. I don't know about other vendors, but for us IKEv2 was introduced in a version called R71. Customers eventually do upgrade, whether it's to get IKEv2 or get one of the other features. Similarly in Windows, customers buy Windows 7 for the 64-bit support, or the aero interface, or for IPv6 support, and they also get the IKEv2. I don't think anyone is going to add new enhancements to old releases now, unless those enhancements begin with the words prevent an attack where… ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Dan Harkins writes: We can't always get what we want and we should be reasonable in understanding that. If we could wave a magic wand and grant your wish that would be good; we can't. And given the limits to our power we have to accept that what will happen is people will continue to use IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK though, so it is likely that by adding SPSK to IKEv1 we could get people off of XAUTH and that too would be a good thing. So if we weigh the improbable stretch goal of forcing people to stop using IKEv1 with the probable, more easily attainable, goal of getting people to stop using XAUTH by giving them an alternative that can pretty easily be implemented, I still come down on settling for an achievable goal of goodness and not making that be a victim for an unachievable goal of betterness. The reason they cannot move to use IKEv1 + SPSK any faster than they can move to use IKEv2 + SPSK is same. Both of them do require new version of both client and server. The client customers always tell that the reason they cannot use IKEv2 as the SGW's they use do not support IKEv2 (or it is not turned on by default). The SGW customers say that the reason they cannot use IKEv2 as they clients do not support it (or it is not turned on by default)... Regardless whether it is Specification Required or not, I am still objecting if someone tries to add new features to IKEv1. Of course my objecting might not have any effect, but I still think it is BAD idea. OK, so we're in agreement: Specification Required. I originally suggested Specification Required, so yes we are in agreement in that, but we are not only people in the WG, and there has been people saying otherwise. If we do not reach some kind of concensus, then the default action will most likely be do nothing, which will mean the registry stays what it is now, and I do not want that. I think IETF Review would be good compromise for this as it would make it easier than Standard Track RFC, but would satisfy those who do not want to have it as lower as Specification Required is... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Dan Harkins writes: That's a really good point. Had it been Specification Required all along XAUTH might've gotten an official code point. And who knows maybe one of the j-random proposals might be just that. But IKEv1 really is pretty done. At this point I'm pretty sure that j would be zero. Most likely not, as all IPsec work had to be stopped so we could ship the IPsec out... IPSRA was supposed to do things like XAUTH and Configuration mode etc, but it failed... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
I think IETF Review would be good compromise for this as it would make it easier than Standard Track RFC, but would satisfy those who do not want to have it as lower as Specification Required is... Summarizing my views: - Specification Required is an unacceptably low bar for this sort of security protocol due to the possibility of security flaws. - I prefer IETF Review to Expert Review for this sort of security protocol as IETF Review should yield higher-quality results. Thanks, --David -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Tero Kivinen Sent: Wednesday, March 28, 2012 9:04 AM To: Dan Harkins Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Dan Harkins writes: We can't always get what we want and we should be reasonable in understanding that. If we could wave a magic wand and grant your wish that would be good; we can't. And given the limits to our power we have to accept that what will happen is people will continue to use IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK though, so it is likely that by adding SPSK to IKEv1 we could get people off of XAUTH and that too would be a good thing. So if we weigh the improbable stretch goal of forcing people to stop using IKEv1 with the probable, more easily attainable, goal of getting people to stop using XAUTH by giving them an alternative that can pretty easily be implemented, I still come down on settling for an achievable goal of goodness and not making that be a victim for an unachievable goal of betterness. The reason they cannot move to use IKEv1 + SPSK any faster than they can move to use IKEv2 + SPSK is same. Both of them do require new version of both client and server. The client customers always tell that the reason they cannot use IKEv2 as the SGW's they use do not support IKEv2 (or it is not turned on by default). The SGW customers say that the reason they cannot use IKEv2 as they clients do not support it (or it is not turned on by default)... Regardless whether it is Specification Required or not, I am still objecting if someone tries to add new features to IKEv1. Of course my objecting might not have any effect, but I still think it is BAD idea. OK, so we're in agreement: Specification Required. I originally suggested Specification Required, so yes we are in agreement in that, but we are not only people in the WG, and there has been people saying otherwise. If we do not reach some kind of concensus, then the default action will most likely be do nothing, which will mean the registry stays what it is now, and I do not want that. I think IETF Review would be good compromise for this as it would make it easier than Standard Track RFC, but would satisfy those who do not want to have it as lower as Specification Required is... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Dan Harkins writes: I guess I'd like to register an objection. I wrote a draft a few months ago to address this: http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt That suggested making it Specification Required. You mentioned that someone was opposed to it being Specification Required but didn't say who or what the rationale was behind that opposition. So I'd like to discuss this a bit. I prefer Specification Required and would like to know what the problem someone has with it is. See the orignal thread in the ipsec-list: http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html What is your objection to the IETF Review? IETF Review - (Formerly called IETF Consensus in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG) documents with an IETF Last Call. Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Hello Extensions [RFC4366]. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Dan Harkins writes: That said, the problem I want to fix-- IKEv1's susceptibility to dictionary attack, it's binding of a PSK to an IP address, and the prevalence of XAUTH because there's no other option-- should be fixed. All others than the dictionary attack IS ALREADY FIXED. The fixes are in the IKEv2. Also the dictionary attack problem will be fixed by your IKEv2 SPSK draft. We can say, stop using IKEv1 but giving someone the option of implementing PAKE + IKEv2 versus just implementing PAKE, or more likely just continuing on with a broken XAUTH deployment, we all know what they'll do and it's not doing PAKE + IKEv2. Yes, we can and should say Stop using IKEv1. That is the part I agree with you. I do not want to add any new features to IKEv1, as that just makes people to continue use it, and not to update to the IKEv2. If PAKE is the stick that causes people to move from IKEv1 to IKEv2, that is very good. It would be a service to the Internet to provide a fix for this. The IETF has not been successful in forcing people to do things against their will (viz, the history of IPv6) and if we tried here we'd likely fail again. So let me turn it around, what's wrong with Specification Required? Read the whole original thread and find out there. I do not really have any objections for Specification Required, that was what I originally proposed. The original thread (I just gave the link to first email in the full thread) has emails which explains why people felt it was not enough. Regardless whether it is Specification Required or not, I am still objecting if someone tries to add new features to IKEv1. Of course my objecting might not have any effect, but I still think it is BAD idea. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Hi Dan, One process note: It appears that all the PAKE drafts got one yes from the sponsoring AD and the remaining votes were no objection so it doesn't seem like the IESG is really interested in this topic and, frankly, I think the majority think that stuff is out of my field of expertise. So my only option is to cajole an AD into sponsoring my draft and hoping that no one else on the IESG objects by saying, didn't we just do this? Speaking from long experience as a chair of many WGs, that sort of IESG vote tally is typical, even for WG docs (although usually both of the responsible Area ADs vote yes, as they're both sponsoring). IMHO, you're being overly pessimistic. So let me turn it around, what's wrong with Specification Required? While I know that you're competent to design a solid protocol, who does the security review of the next 5 j-random authentication mechanisms to make sure that they don't have security flaws? I'd prefer something like IESG approval that puts the Security Area in the loop to the notion of deferring to some form of Expert Review (this is not a slam against Tero as the expert - wider review usually produces better results). Thanks, --David -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Dan Harkins Sent: Tuesday, March 27, 2012 10:14 AM To: Tero Kivinen Cc: ipsec@ietf.org; Dan Harkins Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote: Dan Harkins writes: I guess I'd like to register an objection. I wrote a draft a few months ago to address this: http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt That suggested making it Specification Required. You mentioned that someone was opposed to it being Specification Required but didn't say who or what the rationale was behind that opposition. So I'd like to discuss this a bit. I prefer Specification Required and would like to know what the problem someone has with it is. See the orignal thread in the ipsec-list: http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html OK, but that says 'Specification Required' or 'IETF Review', it's not opposition to Specification Required. What is your objection to the IETF Review? Well, I feel it is setting the bar too high for what I want to do. I had to remove a chunk of text from my PAKE draft fixed a significant, know, serious, and continuing problem with IKEv1. I was told that I should write another I-D that includes that text and try to see what happens. The issue is that requiring IESG review and AD sponsorship will likely result in me not getting over that bar and getting a code point assigned. It appears that all the PAKE drafts got one yes from the sponsoring AD and the remaining votes were no objection so it doesn't seem like the IESG is really interested in this topic and, frankly, I think the majority think that stuff is out of my field of expertise. So my only option is to cajole an AD into sponsoring my draft and hoping that no one else on the IESG objects by saying, didn't we just do this? I don't want to burn up what remaining goodwill I might have with our ADs by continuing to push this topic. That said, the problem I want to fix-- IKEv1's susceptibility to dictionary attack, it's binding of a PSK to an IP address, and the prevalence of XAUTH because there's no other option-- should be fixed. We can say, stop using IKEv1 but giving someone the option of implementing PAKE + IKEv2 versus just implementing PAKE, or more likely just continuing on with a broken XAUTH deployment, we all know what they'll do and it's not doing PAKE + IKEv2. It would be a service to the Internet to provide a fix for this. The IETF has not been successful in forcing people to do things against their will (viz, the history of IPv6) and if we tried here we'd likely fail again. So let me turn it around, what's wrong with Specification Required? thanks, Dan. IETF Review - (Formerly called IETF Consensus in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD- Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner. To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
david.bl...@emc.com writes: While I know that you're competent to design a solid protocol, who does the security review of the next 5 j-random authentication mechanisms to make sure that they don't have security flaws? I'd prefer something like IESG approval that puts the Security Area in the loop to the notion of deferring to some form of Expert Review (this is not a slam against Tero as the expert - wider review usually produces better results). None of the IKEv1 iana registries are expert review, so I do not have anything to do with them, except as I am expert for the IKEv2 registries, IANA seems to assume I can help them to solve old issues in the IKEv1 registries too, but I am doing that just as an individual helping them... -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote: Dan Harkins writes: That said, the problem I want to fix-- IKEv1's susceptibility to dictionary attack, it's binding of a PSK to an IP address, and the prevalence of XAUTH because there's no other option-- should be fixed. All others than the dictionary attack IS ALREADY FIXED. The fixes are in the IKEv2. Also the dictionary attack problem will be fixed by your IKEv2 SPSK draft. Yet there is still this massive deployment of XAUTH + IKEv1. We can say, stop using IKEv1 but giving someone the option of implementing PAKE + IKEv2 versus just implementing PAKE, or more likely just continuing on with a broken XAUTH deployment, we all know what they'll do and it's not doing PAKE + IKEv2. Yes, we can and should say Stop using IKEv1. Yes we should. But we should not suffer any delusions that we can force anyone to do anything. That is the part I agree with you. I do not want to add any new features to IKEv1, as that just makes people to continue use it, and not to update to the IKEv2. If PAKE is the stick that causes people to move from IKEv1 to IKEv2, that is very good. We can't always get what we want and we should be reasonable in understanding that. If we could wave a magic wand and grant your wish that would be good; we can't. And given the limits to our power we have to accept that what will happen is people will continue to use IKEv1 + XAUTH because the work to go to IKEv2 is, to them (!), too much. The work to do SPSK in IKEv1 would be less than doing IKEv2 + SPSK though, so it is likely that by adding SPSK to IKEv1 we could get people off of XAUTH and that too would be a good thing. So if we weigh the improbable stretch goal of forcing people to stop using IKEv1 with the probable, more easily attainable, goal of getting people to stop using XAUTH by giving them an alternative that can pretty easily be implemented, I still come down on settling for an achievable goal of goodness and not making that be a victim for an unachievable goal of betterness. It would be a service to the Internet to provide a fix for this. The IETF has not been successful in forcing people to do things against their will (viz, the history of IPv6) and if we tried here we'd likely fail again. So let me turn it around, what's wrong with Specification Required? Read the whole original thread and find out there. I do not really have any objections for Specification Required, that was what I originally proposed. The original thread (I just gave the link to first email in the full thread) has emails which explains why people felt it was not enough. Regardless whether it is Specification Required or not, I am still objecting if someone tries to add new features to IKEv1. Of course my objecting might not have any effect, but I still think it is BAD idea. OK, so we're in agreement: Specification Required. Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy
Hi Dan, I haven't made up my mind yet whether I support the addition of SPSK to IKEv1 or not, because both you and Tero have made some good points. But this very discussion is a strong proof to me that we need to have IETF Review (in the RFC 5226 sense) for this kind of major change to IKEv1. Because this is exactly the community that needs to discuss new authentication methods, and to weigh their security and other properties against the disadvantages of adding yet more stuff to IKEv1. This needs to be an open discussion, and I am sure the ADs will use our input when they decide whether to sponsor any such proposal. Thanks, Yaron On 03/27/2012 06:41 PM, david.bl...@emc.com wrote: I think we can make things better with a simple addition and I just want to be able to do that. To ask bluntly - what is the problem with soliciting AD sponsorship for the simple addition? IMHO, Specification Required by itself is entirely too weak for security protocols. Thanks, --David -Original Message- From: Dan Harkins [mailto:dhark...@lounge.org] Sent: Tuesday, March 27, 2012 12:23 PM To: Black, David Cc: dhark...@lounge.org; kivi...@iki.fi; ipsec@ietf.org Subject: Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy Hi David, On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote: Hi Dan, One process note: It appears that all the PAKE drafts got one yes from the sponsoring AD and the remaining votes were no objection so it doesn't seem like the IESG is really interested in this topic and, frankly, I think the majority think that stuff is out of my field of expertise. So my only option is to cajole an AD into sponsoring my draft and hoping that no one else on the IESG objects by saying, didn't we just do this? Speaking from long experience as a chair of many WGs, that sort of IESG vote tally is typical, even for WG docs (although usually both of the responsible Area ADs vote yes, as they're both sponsoring). IMHO, you're being overly pessimistic. So let me turn it around, what's wrong with Specification Required? While I know that you're competent to design a solid protocol, who does the security review of the next 5 j-random authentication mechanisms to make sure that they don't have security flaws? I'd prefer something like IESG approval that puts the Security Area in the loop to the notion of deferring to some form of Expert Review (this is not a slam against Tero as the expert - wider review usually produces better results). That's a really good point. Had it been Specification Required all along XAUTH might've gotten an official code point. And who knows maybe one of the j-random proposals might be just that. But IKEv1 really is pretty done. At this point I'm pretty sure that j would be zero. I know IKE's being used wrong and I know the people who are using it wrong don't want to go to IKEv2. They understand what they're doing is broken (a shared PSK for everyone followed by PAP in XAUTH) but they don't want to go to IKEv2 and use EAP to fix it, and it doesn't sound like going to IKEv2 with SPSK is much more attractive. I think we can make things better with a simple addition and I just want to be able to do that. regards, Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
