Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi Hui, Thank you for your comments. Regarding your second comment, please see http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-resumption-08#section-9.4 Regards, Yaron > -Original Message- > From: Hui Deng [mailto:denghu...@gmail.com] > Sent: Tuesday, September 22, 2009 17:40 > To: Tero Kivinen > Cc: Yaron Sheffer; IPsecme WG; i...@ietf.org; Peny Yang > Subject: Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption > (IKEv2 Session Resumption) to Proposed Standard > > Comments inline, thanks > > 2009/9/3 Tero Kivinen : > > Yaron Sheffer writes: > >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, > and in > >> fact an early version of our work did exactly that. But the working > group > >> gave us a clear direction to use a separate exchange, and this is where > we > >> disagree: I believe we did have a strong WG consensus that the > >> implementation benefits of having a separate exchange (i.e. not > overloading > >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits > of the > >> alternative. > > > > I agree on that (both to the WG having consensus and also that using > > separate exchange is better). > [Hui] I don't think so. IMO, in the list, the comparison of extended > IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus > yet. > It was a ballot in the mailing list in the begining, and it is quite > clear more people opposing > sepaparate exchange, we could do one more round ballot if needed. > > > > >> > I know that how a client detects the need for resumption is out of > the > >> > scope of this draft. But, there is the possibility that IPsec client > >> > may be continuously deceived and believe the fail of IPsec gateway. > It > >> > may continuously present the ticket and update the ticket. In this > >> > sense, IMHO, this draft should take care of this case. > >> > > >> [YS] If I understand the scenario correctly, it is similar to an > attacker > >> repeatedly sending notifications to an IKE client, making it believe > that > >> the IKE exchange has failed and needs to be reinitiated. This attack > against > >> plain-vanilla IKE would be much more CPU-intensive to the client and to > the > >> (real) gateway, compared to repeated session resumption. Even when you > >> factor in the cost of generating a new ticket. Moreover, the regular > IKEv2 > >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > > > Regardless what notifications or ICMP messages you send to any of the > > IKE end points that MUST NOT cause them to consider IKE SA failed. It > > "MUST conclude that the other endpoind has failed only when repeated > > attemtps to contact it have gone unanswered for timeout period or when > > a cryptographically protected INITIAL_CONTACT notification is received > > on a different IKE SA to the same authenticated identity." (RFC 4306 > > section 2.4) > > > > Notifications and ICMP messages may trigger other end to send empty > > INFORMATIONAL message to check whether the other end is alive or not > > and only if that times out then the other end is considered dead. > > > > This means this kind of attack is not possible with notifications and > > ICMP. > > > > On the other hand I do agree with Peny that, as resumption draft makes > > it out of scope for this draft, how a client detects the need of > > resumption, we might need more text explaining this attack. I.e. we > > might need to add text to security considerations which says that the > > client implementations should not trust any untrusted source when they > > are trying to detect whether the resumption is needed. > > [Hui] I also agree with Peny and Tero. Although way of detecting > failure of gateways is out of the scope of current charter, WG draft > should at least handle the issues incurred by mis-judgement of client. > > thanks > > -Hui > > Scanned by Check Point Total Security Gateway. Email secured by Check Point Email secured by Check Point ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Comments inline, thanks 2009/9/3 Tero Kivinen : > Yaron Sheffer writes: >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in >> fact an early version of our work did exactly that. But the working group >> gave us a clear direction to use a separate exchange, and this is where we >> disagree: I believe we did have a strong WG consensus that the >> implementation benefits of having a separate exchange (i.e. not overloading >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the >> alternative. > > I agree on that (both to the WG having consensus and also that using > separate exchange is better). [Hui] I don't think so. IMO, in the list, the comparison of extended IKE_SA_INIT exchange and IKE_SESSION_RESUME still did not have a consensus yet. It was a ballot in the mailing list in the begining, and it is quite clear more people opposing sepaparate exchange, we could do one more round ballot if needed. > >> > I know that how a client detects the need for resumption is out of the >> > scope of this draft. But, there is the possibility that IPsec client >> > may be continuously deceived and believe the fail of IPsec gateway. It >> > may continuously present the ticket and update the ticket. In this >> > sense, IMHO, this draft should take care of this case. >> > >> [YS] If I understand the scenario correctly, it is similar to an attacker >> repeatedly sending notifications to an IKE client, making it believe that >> the IKE exchange has failed and needs to be reinitiated. This attack against >> plain-vanilla IKE would be much more CPU-intensive to the client and to the >> (real) gateway, compared to repeated session resumption. Even when you >> factor in the cost of generating a new ticket. Moreover, the regular IKEv2 >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > Regardless what notifications or ICMP messages you send to any of the > IKE end points that MUST NOT cause them to consider IKE SA failed. It > "MUST conclude that the other endpoind has failed only when repeated > attemtps to contact it have gone unanswered for timeout period or when > a cryptographically protected INITIAL_CONTACT notification is received > on a different IKE SA to the same authenticated identity." (RFC 4306 > section 2.4) > > Notifications and ICMP messages may trigger other end to send empty > INFORMATIONAL message to check whether the other end is alive or not > and only if that times out then the other end is considered dead. > > This means this kind of attack is not possible with notifications and > ICMP. > > On the other hand I do agree with Peny that, as resumption draft makes > it out of scope for this draft, how a client detects the need of > resumption, we might need more text explaining this attack. I.e. we > might need to add text to security considerations which says that the > client implementations should not trust any untrusted source when they > are trying to detect whether the resumption is needed. [Hui] I also agree with Peny and Tero. Although way of detecting failure of gateways is out of the scope of current charter, WG draft should at least handle the issues incurred by mis-judgement of client. thanks -Hui ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
On Thu, Sep 3, 2009 at 5:11 PM, Tero Kivinen wrote: > Yaron Sheffer writes: >> [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in >> fact an early version of our work did exactly that. But the working group >> gave us a clear direction to use a separate exchange, and this is where we >> disagree: I believe we did have a strong WG consensus that the >> implementation benefits of having a separate exchange (i.e. not overloading >> even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the >> alternative. > > I agree on that (both to the WG having consensus and also that using > separate exchange is better). >> > I know that how a client detects the need for resumption is out of the >> > scope of this draft. But, there is the possibility that IPsec client >> > may be continuously deceived and believe the fail of IPsec gateway. It >> > may continuously present the ticket and update the ticket. In this >> > sense, IMHO, this draft should take care of this case. >> > >> [YS] If I understand the scenario correctly, it is similar to an attacker >> repeatedly sending notifications to an IKE client, making it believe that >> the IKE exchange has failed and needs to be reinitiated. This attack against >> plain-vanilla IKE would be much more CPU-intensive to the client and to the >> (real) gateway, compared to repeated session resumption. Even when you >> factor in the cost of generating a new ticket. Moreover, the regular IKEv2 >> anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > > Regardless what notifications or ICMP messages you send to any of the > IKE end points that MUST NOT cause them to consider IKE SA failed. It > "MUST conclude that the other endpoind has failed only when repeated > attemtps to contact it have gone unanswered for timeout period or when > a cryptographically protected INITIAL_CONTACT notification is received > on a different IKE SA to the same authenticated identity." (RFC 4306 > section 2.4) > > Notifications and ICMP messages may trigger other end to send empty > INFORMATIONAL message to check whether the other end is alive or not > and only if that times out then the other end is considered dead. > > This means this kind of attack is not possible with notifications and > ICMP. [Peny] Agree. I did not mean this kind of attacking originally. > > On the other hand I do agree with Peny that, as resumption draft makes > it out of scope for this draft, how a client detects the need of > resumption, we might need more text explaining this attack. I.e. we > might need to add text to security considerations which says that the > client implementations should not trust any untrusted source when they > are trying to detect whether the resumption is needed. [Peny] Agree. I also think we need more text to clarify this issue. In this meanwhile, I think the way in section 4.3.4 is not appropriate. Gateway should not silently delete the related SAs in this case. One possible solution is to use the anti-DOS cookie mechanism of IKEv2 to handle this issue. > -- > kivi...@iki.fi > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi, Yaron: Please check my response inlines: BRG Peny 2009/9/3 Yaron Sheffer : > Hi Peny, > > Thank you for reviewing this draft. Please see my comments below. > > Regards, > Yaron > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of >> Peny Yang >> Sent: Wednesday, September 02, 2009 17:18 >> To: i...@ietf.org >> Cc: IPsecme WG >> Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption >> (IKEv2 Session Resumption) to Proposed Standard >> >> Sorry, I should cc IPsec mail list. Comments are sent again. >> >> Hi, floks: >> >> I have two comments on the draft of IKEv2 Session Resumption: >> >> 1) Sorry, I have to talk about my concern on the new >> IKE_SESSION_RESUME. In WG last call, actually I made this comment. >> However, no feedback was given, maybe because my comment was a little >> late for WG last call. So, I just copy it here again as a comment for >> IESG last call. >> >> Well, we've discussed pros and cons of IKE_SA_INIT and >> IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus >> is still not fully achieved on this item. So far, I still prefer to >> choosing extended IKE_SA_INIT for ticket presenting. This solution is >> specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 >> >> As a summary, the virtues are as follows: >> - RFC5077 (TLS session resumption) also uses the similar scheme, which >> extends the message of clienthello with session ticket extension. The >> extended IKE_SA_INIT solution has the similar way. It's easy to extend >> the base IKEv2 protocol stack to support session resumption. >> - Considering the case of failing session resumption, the extended >> IKE_SA_INIT solution can save one round trip. >> - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated >> after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way >> need less code to be supported compared with IKE_SESSION_RESUME. >> >> The down side: >> - some people thought the way of extended IKE_SA_INIT will make the >> base IKEv2 protocol stack more complex. IMHO, it's an issue of >> implementation. >> Again, I still support to use extended IKE_SA_INIT for ticket >> presenting instead of IKE_SESSION_RESUME. > [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in > fact an early version of our work did exactly that. But the working group > gave us a clear direction to use a separate exchange >, and this is where we > disagree: I believe we did have a strong WG consensus that the > implementation benefits of having a separate exchange (i.e.) outweigh the > benefits of the > alternative. [Peny] I know WG chair have the right to judge "rough consensus". However, I can't agree that IPsecme WG has achieved the so called "strong consensus" on this issue. Maybe IESG can further judge it. I also can't agree "benefits of having a separate exchange outweigh the benefits of the alternative". Actually, we didn't achieve consensus on it yet. > not overloading even more the non-trivial IKE_SA_INIT exchange [Peny] I am sorry. I just can't see any evidence that the solution of extending IKE_SA_INIT extension will *OVERLOAD* current IKE_SA_INIT exchange? Or I missed something? > >> 2) Maybe I missed some discussions. >> There is the case: responder may receives a ticket for an IKE SA that >> is still active and if the responder accepts it. In one of previous >> versions of this draft, there once was some description on this case. > > [YS] I believe you are referring to the text now in Sec. 4.3.4. [Peny] OK. This is the part I referred to. But, it can't deal with the issue when IPsec client *continuously* believes failure of gateway. > >> I know that how a client detects the need for resumption is out of the >> scope of this draft. But, there is the possibility that IPsec client >> may be continuously deceived and believe the fail of IPsec gateway. It >> may continuously present the ticket and update the ticket. In this >> sense, IMHO, this draft should take care of this case. >> > [YS] If I understand the scenario correctly, it is similar to an attacker > repeatedly sending notifications to an IKE client, making it believe that > the IKE exchange has failed and needs to be reinitiated. [Peny] Well, this case may not cause this problem. If attacker has IPsec connection with the client, the client will only believe the attacker fails, not Gateway. Here is one of the cases. Sometimes, temporary unavailability of network ac
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Yaron Sheffer writes: > [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in > fact an early version of our work did exactly that. But the working group > gave us a clear direction to use a separate exchange, and this is where we > disagree: I believe we did have a strong WG consensus that the > implementation benefits of having a separate exchange (i.e. not overloading > even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the > alternative. I agree on that (both to the WG having consensus and also that using separate exchange is better). > > I know that how a client detects the need for resumption is out of the > > scope of this draft. But, there is the possibility that IPsec client > > may be continuously deceived and believe the fail of IPsec gateway. It > > may continuously present the ticket and update the ticket. In this > > sense, IMHO, this draft should take care of this case. > > > [YS] If I understand the scenario correctly, it is similar to an attacker > repeatedly sending notifications to an IKE client, making it believe that > the IKE exchange has failed and needs to be reinitiated. This attack against > plain-vanilla IKE would be much more CPU-intensive to the client and to the > (real) gateway, compared to repeated session resumption. Even when you > factor in the cost of generating a new ticket. Moreover, the regular IKEv2 > anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. Regardless what notifications or ICMP messages you send to any of the IKE end points that MUST NOT cause them to consider IKE SA failed. It "MUST conclude that the other endpoind has failed only when repeated attemtps to contact it have gone unanswered for timeout period or when a cryptographically protected INITIAL_CONTACT notification is received on a different IKE SA to the same authenticated identity." (RFC 4306 section 2.4) Notifications and ICMP messages may trigger other end to send empty INFORMATIONAL message to check whether the other end is alive or not and only if that times out then the other end is considered dead. This means this kind of attack is not possible with notifications and ICMP. On the other hand I do agree with Peny that, as resumption draft makes it out of scope for this draft, how a client detects the need of resumption, we might need more text explaining this attack. I.e. we might need to add text to security considerations which says that the client implementations should not trust any untrusted source when they are trying to detect whether the resumption is needed. -- kivi...@iki.fi ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi Peny, Thank you for reviewing this draft. Please see my comments below. Regards, Yaron > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Peny Yang > Sent: Wednesday, September 02, 2009 17:18 > To: i...@ietf.org > Cc: IPsecme WG > Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption > (IKEv2 Session Resumption) to Proposed Standard > > Sorry, I should cc IPsec mail list. Comments are sent again. > > Hi, floks: > > I have two comments on the draft of IKEv2 Session Resumption: > > 1) Sorry, I have to talk about my concern on the new > IKE_SESSION_RESUME. In WG last call, actually I made this comment. > However, no feedback was given, maybe because my comment was a little > late for WG last call. So, I just copy it here again as a comment for > IESG last call. > > Well, we've discussed pros and cons of IKE_SA_INIT and > IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus > is still not fully achieved on this item. So far, I still prefer to > choosing extended IKE_SA_INIT for ticket presenting. This solution is > specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 > > As a summary, the virtues are as follows: > - RFC5077 (TLS session resumption) also uses the similar scheme, which > extends the message of clienthello with session ticket extension. The > extended IKE_SA_INIT solution has the similar way. It's easy to extend > the base IKEv2 protocol stack to support session resumption. > - Considering the case of failing session resumption, the extended > IKE_SA_INIT solution can save one round trip. > - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated > after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way > need less code to be supported compared with IKE_SESSION_RESUME. > > The down side: > - some people thought the way of extended IKE_SA_INIT will make the > base IKEv2 protocol stack more complex. IMHO, it's an issue of > implementation. > Again, I still support to use extended IKE_SA_INIT for ticket > presenting instead of IKE_SESSION_RESUME. > [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange, and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e. not overloading even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the alternative. > 2) Maybe I missed some discussions. > There is the case: responder may receives a ticket for an IKE SA that > is still active and if the responder accepts it. In one of previous > versions of this draft, there once was some description on this case. [YS] I believe you are referring to the text now in Sec. 4.3.4. > I know that how a client detects the need for resumption is out of the > scope of this draft. But, there is the possibility that IPsec client > may be continuously deceived and believe the fail of IPsec gateway. It > may continuously present the ticket and update the ticket. In this > sense, IMHO, this draft should take care of this case. > [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. This attack against plain-vanilla IKE would be much more CPU-intensive to the client and to the (real) gateway, compared to repeated session resumption. Even when you factor in the cost of generating a new ticket. Moreover, the regular IKEv2 anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. > BRG > Peny > > On Mon, Aug 31, 2009 at 10:09 PM, The IESG wrote: > > The IESG has received a request from the IP Security Maintenance and > > Extensions WG (ipsecme) to consider the following document: > > > > - 'IKEv2 Session Resumption ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and solicits > > final comments on this action. Please send substantive comments to the > > i...@ietf.org mailing lists by 2009-09-14. Exceptionally, > > comments may be sent to i...@ietf.org instead. In either case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption- > 07.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17 > 990
[IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Sorry, I should cc IPsec mail list. Comments are sent again. Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. BRG Peny On Mon, Aug 31, 2009 at 10:09 PM, The IESG wrote: > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > > - 'IKEv2 Session Resumption ' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > i...@ietf.org mailing lists by 2009-09-14. Exceptionally, > comments may be sent to i...@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-07.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17990&rfc_flag=0 > > ___ > 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
